jamessocol

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 amount of time for a change to sit in "ready for merge" or merged but not deployed?

Check out OpenHatch http://openhatch.org/. Connecting people with time to projects with need is a big part of what they do.

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.

(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 place. But of the 100k or so Python/Ruby/NPM projects I know about, only a small handful do, or could even manage it.

And if they did, would you want to be on every one of their mailing lists?

Bleach, for example, has more users than I have twitter followers, so I doubt most of them heard about v1.2.1. (Out today! Go get it!)

> but it kinda sucks that you'd make people pay to hear about security issues

Well, like you said, there are other ways to hear about updates, at least from the big projects. This is the convenience of not needing to join dozens of mailing lists and/or check dozens of websites periodically.

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.)

Thanks!

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 details of the history of why it was there and configured (if you read further, you'd see that it was part of our puppet manifests, and for a reason). But you reduce the surface area of attack by reducing the number of things that can execute arbitrary code. And if you aren't using PHP at all, "yum remove php" saves you disk space and surface area, even if you have another colossal screw up (like we did).

> The most it could affect a user by itself is due to some temp file race someone might be able to take advantage of.

Well, the most it could do is, if you've screwed up someplace else, execute arbitrary code as the webserver user on the machine, thanks to the backtick operator.

>> 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 scripts.

I am not sure that's so obvious. Most web servers will serve a .ini or .yml file as plain text, if it's in the wrong spot. On the other hand, a PHP file like https://gist.github.com/3177788, even if it's in the web directory, can't leak the data without some other compromise--and the type of compromise required would generally give you access to any of the values in the .ini file, anyway.

But, see also #5: "Are your firewall rules restrictive enough?" If I can even connect, let alone authenticate, to your database from the web, you have bigger problems.

GCC is an excellent point, though.

Honestly, "easy to overlook" is why I wrote a checklist for basics. CYA, then get to the advanced stuff.

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.

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.

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 your session cookies in particular should always be HttpOnly and preferably secure.

I updated the post to point this out.

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.

Ugh, I really need to create a lighter-weight theme. Sorry about that.

> 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 practice anyway, for how all actors involved understand HTTP verbs, and reduces the surface area of attack.

You can create a POST with an iframe, but you can create a GET with an image tag: `<img src="http://mybank.com/transfer?...>`

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 problems. The key is staying up-to-date.

Not that you shouldn't understand the potential vectors against your site, or shouldn't read how to use these tools correctly, but a widely tested and used tool or framework, just like a widely researched crytpo algorithm, is better than one with no other eyes on it.

> 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 seems to be at the farthest possible end of the spectrum from what I'm talking about.

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.

And now I put up the outline, at least, of what's coming over the next few days.

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.

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 the basics and reduce the surface area of attack.

Maybe it's worth adding that the basics are just the basics, not a substitute for real threat modeling and analysis. But there's always a real-world cost/benefit factor.

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.

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 less of a burden.

Anything that makes engaging harder (2-factor auth, captchas, which I'll get to sometime next week) will cost conversions and engagement. You have to weigh those things realistically. Security doesn't exist in a vacuum where User Experience doesn't matter.