Excellent checklist. Several things I never even thought of.
3. Avoid a set of "features that always doom dev teams", including encryption, password storage, browser plugins that inject into the DOM, templating, installers, network listeners, and file upload/download.
We're doomed. All but two of these are present in every one of our projects. (I kid about being doomed. Mostly. We do have 11+ years of being a prime target for attacks to give us some confidence that we're doing OK. But we do unavoidably have to handle most of those features that always doom dev teams.)
5. Screw with amateur web pests --- use your own magic version of base64 with some of the characters swapped, use 3DES for something with swapped-around s-boxes, etc.
Isn't fiddling with the encryption, without understanding, what got Debian into trouble a while back with OpenSSL? Perhaps I don't even know enough to know what you're suggesting when you say "3DES with swapped-around s-boxes".
Buy a copy of Burp Suite and run the "Intruder" on every page.
I'd never heard of Burp Suite before. I had no idea there was an automated tool for this stuff (and at a reasonable price). Awesome.
You're always going to be doomed. A talk we did recently for a friend of ours in Chicago was entirely this: instead of the OWASP "Top 10", which is rapidly getting outdated, a list of top scary features. It sounds at first like we're saying "you're not allowed to build these!", which is the effect we're going for, but really the value of knowing what these features are is:
* You can intercept them in the requirements phase and either refactor your design so you aren't as exposed to them (maybe you don't really need file upload, maybe you can use S3, etc).
* You can make sure junior devs don't get assigned the scary features (a big chunk of the stupid flaws we find are accompanied with the "oh that was the new developer who did that" excuse).
* You can triage those features in code review and QA.
There is a big but apparently subtle difference between "encryption you rely on" and "rubber chicken encryption" (you can see now why I'm not in love with our Indie SDLC yet). Yes, you never want to dick around with encryption for your single-signon tokens --- use GPGME or Keyczar or something. But once you've secured your app, you can add obfuscation to reduce the likelihood that people will jump on your mistakes.
And yes. If you sell a web app commercially, you should own a copy of Burp. For what it does, it's amazingly cheap (like $150). It is the industry standard web pest tool.
3. Avoid a set of "features that always doom dev teams", including encryption, password storage, browser plugins that inject into the DOM, templating, installers, network listeners, and file upload/download.
We're doomed. All but two of these are present in every one of our projects. (I kid about being doomed. Mostly. We do have 11+ years of being a prime target for attacks to give us some confidence that we're doing OK. But we do unavoidably have to handle most of those features that always doom dev teams.)
5. Screw with amateur web pests --- use your own magic version of base64 with some of the characters swapped, use 3DES for something with swapped-around s-boxes, etc.
Isn't fiddling with the encryption, without understanding, what got Debian into trouble a while back with OpenSSL? Perhaps I don't even know enough to know what you're suggesting when you say "3DES with swapped-around s-boxes".
Buy a copy of Burp Suite and run the "Intruder" on every page.
I'd never heard of Burp Suite before. I had no idea there was an automated tool for this stuff (and at a reasonable price). Awesome.