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?
(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.
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.
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.
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.
> 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.
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.
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.