I’ve been busy over the weekend.
I met with Blake Turrentine at a diner near where I live. We had a good long discussion over breakfast on the future of the Guide 3.0.
The Guide 3.0 will be about how to design apps and code securely. That’s it. Only positive controls will be discussed unless the negative controls rule right now. For example, the Services “Databases” section will contain only the following sub-sections: Best practices (use an extremely low privilege account unique to your app, use an encrypted connection, store the connection credential securely, etc), Active Record / ORM, prepared statements, stored procedures.
The pattern in each sub-section will most likely be:
- What to do right
- Risk level of this control (All, Low, Medium or High risk apps)
- Why this works (using ESAPI if it’s got something to say about this control)
- Code snippets doing it right
- What this prevents (links to the testing or code review guide and any publicly known attacks using this mechanism)
There will be a “Worst Practices” sub-section containing Dynamic queries, and Stored Procedures Gotchas (discussing string concatenation, calling out to native features, and the use of exec, etc). The idea is that if there’s zero noise on bad controls, you’re more likely to do the right things, particularly if there’s supporting code.
It should be nice and short, especially in comparison with the 2.0 version as there will be only links to testing or code review material. There’s no point in repeating that material.
Although pen testing is considered sexy and a little bit naughty by the meejya (and thus “newsworthy” when plainly it is not), coupled those folks who consider themselves hard core l33t haxors get to go to all the nice parties with ladies of negotiable value, I think pen testing is not the best way to deal with crappy paradigms. If you’re still using dynamic queries, you have soooo much work to prove that you’re “safe”, and every few years when a new technique that exploits the root cause comes along, you’re hosed.
However, if you had spent far less time and money to use one of the three “safe” methods above, you’ll be “safe” for most values of “safe”. We have seen zero mechanisms to attack prepared statements in the last eight years. That’s a very successful control. Therefore, testing for SQL injection is sort of pointless and we can move onto the real golden apples, like direct object references and business logic flaws.
The Coding Top 10 will be a distilled version of the same material, but by necessity, it will concentrate only on ten items, instead of may be 200-300 items. Neil Smithline has agreed to take a shot at it, so I need to touch base with him this week.
In both cases, I’m looking for a healthy dose of contributors as there’s no way I could do the amount of out of hours work I put into the OWASP Guide 2.0 again. Tanya would kill me for a start! If you think you can help out, please join the OWASP Guide and Top 10 mail lists, and shout out!
Please don’t do it because you want to be invited to all the sexy parties and have ze ladies fall at your feet, or to get wealthy on the residuals. I will make this prediction right now: neither document will be feted by the press, and neither document will get much traction at the trendy conferences. Even though they will be the best things to help developers and businesses code properly ever written. Let’s make a start and see how things go.