jamessocol

8 ms·

1.
Your authentication sucks(blog.mattbasta.com)
1 points by jamessocol 12y ago|0 comments
2.
by jamessocol 13y ago
I'd love to hear—maybe I missed another blog post—why they went with the single release manager, where only one person can merge and deploy. What happens if Doug is sick or on vacation? Or even just in a meeting? What is a typical amou
3.
by jamessocol 13y ago
Check out OpenHatch http://openhatch.org/ . Connecting people with time to projects with need is a big part of what they do.
4.
by jamessocol 14y ago
Consider it? Definitely. But semver doesn't make a distinction, either, so it's a hard problem. If you don't mind, we'd love to get your thoughts more via email--don't want to hijack this thread too much.
5.
by jamessocol 14y ago
(Disclaimer: I'm the other guy behind BundleScout.) The Django project does a fantastic job with announcements. (So does Rails.) And if every open source project had the infrastructure to make that much noise, the world would be a better pl
6.
by jamessocol 14y ago
Thanks for the feedback! We'll definitely look at the right way to surface more info before signing up. (For the record, it's $5/month.)
7.
by jamessocol 14y ago
Thanks!
8.
Show HN: BundleScout monitors and notifies you about package updates(bundlescout.com)
28 points by jamessocol 14y ago|5 comments
9.
Stay Up to Date - Basic Web App Security Pt 9(coffeeonthekeyboard.com)
4 points by jamessocol 14y ago|0 comments
10.
by jamessocol 14y ago
I agree with all of your advice about hardening most servers, but a couple of things... > In the case of PHP, there is no security concern by it just sitting on your hard drive. It's a surface area question. I could go into more detai
11.
by jamessocol 14y ago
>> Are directories only writeable by the web server user? NB: The next point is "Do all of them even need to be? Are you sure?" > A blisteringly common one not mentioned is database authentication details inside .pl, .py or .php
12.
Server Configuration - Basic Security Part 7(coffeeonthekeyboard.com)
23 points by jamessocol 14y ago|11 comments
13.
Session Fixation and Hijacking - Basic Security Part 6(coffeeonthekeyboard.com)
6 points by jamessocol 14y ago|0 comments
14.
Access Control - Basic Security Part 5(coffeeonthekeyboard.com)
2 points by jamessocol 14y ago|0 comments
15.
by jamessocol 14y ago
Honestly, "easy to overlook" is why I wrote a checklist for basics. CYA, then get to the advanced stuff.
16.
by jamessocol 14y ago
We keep making more junior devs. It's important to drown out the w3schools and bad practices with good practices, so when they look up how to do it, they learn the right way.
17.
by jamessocol 14y ago
Like I said elsewhere, that's a major cost/benefit calculation in terms of both real cost and user experience/conversion rate cost. If it makes sense for your app, do it, but it's not part of the basics, at least not yet.
18.
by jamessocol 14y ago
For click-jacking, the easiest thing to do is to set the X-Frame-Options header, but I'll get to that. And it doesn't help IE <= 7, so you need to weigh cost/benefit and your user base there. And we'll get to session hijacking and why y
19.
by jamessocol 14y ago
I updated the post to point this out.
20.
by jamessocol 14y ago
Hopefully you're taking steps to prevent both. But yes, closing the CSRF window and leaving the XSS door open would largely defeat the purpose of CSRF protections.
21.
by jamessocol 14y ago
Ugh, I really need to create a lighter-weight theme. Sorry about that.
22.
by jamessocol 14y ago
> In order to issue a POST request to siteA from the evil page, the attacker only has to submit a crafted POST form using an iframe. Yes, but requiring POST for anything that changes anything (especially bank transfers) is a best practi
23.
by jamessocol 14y ago
Maybe we come from different backgrounds. Using open source code that's been subject to lots of eyes and lots of use, e.g. a framework like Django, reduces the surface area, to me, because of the shared best-interest of fixing security prob
24.
by jamessocol 14y ago
> Relying on tools or, in fact, any code you've not written yourself makes your system vulnerable. Writing everything yourself, as opposed to widely, community tested open-source alternatives, makes your system vulnerable. Your example
25.
by jamessocol 14y ago
It's the weird combination of gettext, HTML, and user-supplied data that causes problems. But yeah, kind of surprising there isn't already something. That's why we moved the |fe filter up to jingo, as high and shared as we could.
26.
by jamessocol 14y ago
And now I put up the outline, at least, of what's coming over the next few days.
27.
by jamessocol 14y ago
The CSRF section posts tomorrow morning. I wrote up the entire "Basics" section as a single post and it was of biblical proportions, so I broke it down to post over the next several days.
28.
by jamessocol 14y ago
I would love if every web app went through proper threat modeling periodically. But we're in a fast-moving industry, and that takes time. Sometimes people need to ship and do it now, or yesterday. I'm aiming to help by helping people cover
29.
by jamessocol 14y ago
As long as you're using the tools provided, you're doing your due diligence. The framework provides a lot, and the ecosystem usually provides the rest. The "last mile" is just making sure your code is using all those tools correctly.
30.
by jamessocol 14y ago
I don't completely dismiss it, but it's a huge burden for users, especially those who aren't very tech savvy. I'd love non-optional 2-factor auth for my bank account, maybe that would really introduce it to non-geeks and start making it les

More ›