The OWASP Top 10 is a somewhat useful benchmark and an easy way of communicating the general concept of web application security to people; it's especially useful when an assessment might involve both web security and other stuff, and you want to be clear that you're just poking at the web stuff.
Apart from that: OWASP is not a very reliable resource. The project has given some genuinely bad advice over the years. In particular: don't rely on any advice they give about cryptography.
> Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable oracle padding.
You should be using ECDH, EdDSA, and (authenticated) stream ciphers. Padding shouldn't even be a thing.
> Verify that cryptographic algorithms used by the application have been validated against FIPS 140-2 or an equivalent standard.
FIPS 140-2 is bullshit. Try being FIPS 140-2 compliant on a Debian Squeeze server running Apache 2.2 (i.e. TLS 1.0 is the highest you can go) while also being PCI compliant. Spoiler: The only way to be both PCI and FIPS 140-2 compliant is to use TLS 1.2 with AES-GCM and SHA2.
Standards rarely make good cryptographic choices. Winners of cryptography competitions, on the other hand, do.
> Verify that cryptographic modules operate in their approved mode according to their published security policies.
Yes: The Web App Hacker's Handbook is a better resource for building a checklist of app security concerns for your application, and remains the best resource on generic appsec.
EDIT: This is absolutely the book I was looking for the other day and didn't know existed, most of this stuff I'm familiar with but this looks like an excellent refresher.
I don't really work on application side of web: handed that part off to others while I did client-server plumbing and endpoints. Web is simply too much risk for high-assurance security.
Plus, a brain injury in an accident cost me most of my memory. I operate on fragments now while trying to reconnect stuff. I probably knew about the guide and forgot. Or I didn't but used something else. Usually remember a lot of INFOSEC stuff but this one is total blank. So, such resources are good for getting stuff back in my head.
Here's last list I put up when my memory was working better than ATM that detailed what kinds approaches I recommended or used (often in combination):
I know I used a SPECTRE clone in the past for at least one legacy app. Did high-assurance HTTP to prevent defacing. Did an application server on microkernel similar to Barracuda's nice architecture to keep TCB minimal. Outside SPECTRE, it's what we all did in high-assurance though: certain things everyone seems to build. The rest and all details are a blank. Sorry...
Sorry to hear about your brain injury. If it's any consolation, I had no idea because your comments are consistently insightful and worth the time to stop and read.
I appreciate the feedback and thank you. They said people are usually zombie-like in such a situation. I've seen it. It's quite the battle to maintain or deliver day-to-day functions much less top normal minds in insight.
Nonetheless, I've been fighting for civil liberties and privacy a long time. Plus trying to do bulletproof systems. Even with gaps & lacking specialist skill, I'm closer now than ever mapping & semi-synthesizing systems from high-level specs all the way to transistors with reliability, security, & recovery via dozens of techniques. Dedicated endpoint mostly solved, client server too, Web is if you cheat (I did proxies), P2P still open-ended, and much more to do in decentralized. Plus my activity here and elsewhere of evangelizing strong methods & making sure old wisdom doesn't get lost. Got motivation & keep active so remaining synapses get reinforcement.
So, a little brain injury and Memento-style moments ain't enough to totally knock me out of the game. Just gotta get it back piece by piece & be more mentally efficient than before. Wirth-style ultra-simplification & Dijkstra abstraction pays off there. Anyway, NSA gonna shit their pants when I go commercial again. Short-term rather than long-term goal hopefully. ;)
_WAHH_ and _Tangled_ were the two books we gave every candidate who applied to Matasano. We hired lots of people who had never heard of those books before. There seemed to be no correlation between previous conversance with the book and technical ability.
I wasn't saying there was. Or at least, that wasn't what I was trying to say.
I hadn't read that book until the middle of last year, and I didn't learn anything new from it because I taught myself all those concepts over the years. It was, nonetheless, a good read. So, I wouldn't make that claim to begin with.
I just thought nickpsecurity had seen your reading list before is all. I see you two commenting on the same threads all the time.
It was a good guess. I still have one or two of his bookmarked. I haven't been on HN or following his posts long, though. Then there's the memory angle. So, not this time.
Whose fault is that, then? If you know so much about crypto, and you know OWASP's info on crypto is bad, then why haven't you contributed?
This is the problem with crypto experts. You're all "find a crypto expert". But you just sit there on your thumbs and don't contribute in any way other than building libraries with such bad UX that lead to more "find a crypto expert" advice.
That's a self-evidently dumb comment, but in fact I've had experience trying to talk to OWASP about crypto, and found it an enervating waste of time.
Things may have gotten better in the last 2 years since I stopped paying attention (though: I doubt it), but my experience of it is that it's governed mostly by the kinds of consultants who parachute into projects to configure Fortify. Despite not having much software development experience, those kinds of consultants have very strong opinions about things like crypto.
The problem is very much not limited to crypto.
I think OWASP is mostly unsalvageable, and that the most productive thing to be done is to warn developers to take their advice with a grain of salt. There's useful stuff in there, but there's bad stuff too. That's fine if all you're purporting to build is a wiki, but it's less fine when your goal is to be the bible of appsec. They are simply not that.
> This is the problem with crypto experts. You're all "find a crypto expert". But you just sit there on your thumbs and don't contribute in any way other than building libraries with such bad UX that lead to more "find a crypto expert" advice.
Well, I for one have been contributing, so there's that.
I can clean up the OWASP wiki, but not the people or the paperwork they produce.
I can clean up Stack Overflow, but not Google's search results.
I try where I can, and hope that makes an impact. (Aside: the people at the local OWASP chapter here in Orlando are competent and want to fix things. Not sure about everywhere else.)
Maybe because people have other things to do with their day?
There are lots of things I could contribute to or fix. I pick the things I care about. The same is true for anyone that actually wants to improve things.
Lack of focus is the surest way to frustration and ineffectiveness.
The OWASP Top 10 is a somewhat useful benchmark and an easy way of communicating the general concept of web application security to people; it's especially useful when an assessment might involve both web security and other stuff, and you want to be clear that you're just poking at the web stuff.
Apart from that: OWASP is not a very reliable resource. The project has given some genuinely bad advice over the years. In particular: don't rely on any advice they give about cryptography.