Open Web Application Security Project issues new secure coding bible
theregister.co.uk
theregister.co.uk
I was new there, but not new to software development. I ignored the other developers in the company "ordering" me to use their existing codebase. I had not been very impressed with their home-rolled auth system, including plain-text passwords. I got around it by hacking together a mockup that looked like it was using their site template, so they just assumed the rest of the project was built on it.
I kept myself a scorecard on how I was doing against OWASP's Top Ten. Six months later, we got a surprise early audit, everyone freaked out, but I chilled because I knew we were good. We passed with flying colors. The software also just so happened to be the best-performing project in the company (which isn't really saying much) and everyone was scrambling to scrap their codebases and build on mine (which itself is another problem). It became the only project in the company to have more than two developers working on it at any one time (I had three people under me! Wow!). The documentation I wrote for it--which was mostly just explaining OWASP and what it meant in regards to our technology stack--became the gold standard in the company.
Now, this is not at all to say this was a great feat. But if you're working in the sort of consultoware shop that can't seem to keep anyone with more than 5 years of experience under their belt (which is a lot of people), you can do far, far worse than following OWASP religiously.
I eventually left when it became clear I was the "mule that works", i.e. "you don't beat the mule that doesn't work." It was rationalized that, because we were doing so well, instead of putting more resources into my team to double-down on our track record, it would be better to scatter the team around to the poorer projects, apparently under some plan that success is catching or something. Also, management still expected me to maintain the project on my own at the same productivity level as four people.
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.
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.
https://www.owasp.org/index.php?title=How_to_protect_sensiti...
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.)
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.
Highlight:
Kerckhoff's principle applies to cryptography, not
application security.
- AbiusX, OWASP project leader for PHP Security
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.
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.
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):
https://www.schneier.com/blog/archives/2014/04/the_security_...
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...
Barracuda lightweight approach https://realtimelogic.com/products/lua-server-pages/
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. ;)
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.
The only crypto advice I see in this guide is on page 37.
https://www.owasp.org/images/6/67/OWASPApplicationSecurityVe...
That entire section is incorrect?
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.
This is so vague it's not actionable.
This is like Malcolm Gladwell's Igon Values thing, except it's in a prescriptive technical document.
Nope nope nope. If you're going to make security recommendations, you have to know what you're talking about .
It actually came out last fall. Only 70 pages, not a bad read really.