This post was mentioned on Twitter by brennantom: RT @acunetix: Changes coming to the OWASP Top 10 in 2010; http://bit.ly/66tZfx...

I’m sorry you’ve misunderstood the point I’m trying to make. I wasn’t clear as I should’ve been. The reality is that I find the three issues above in practically every assessment…Again, the others are either non-existent *OR* they don’t matter all that much looking at the big picture. I probably should have said “the others are *typically* non-existent or they don’t…”

I’m not your enemy. I’ve always been a fan and an advocate of the OWASP Top 10 and I strongly believe it has relevance. I’m just telling you what I’m seeing in my work. I’m also speaking about the reality of spending good time and money on the many issues that may be exploitable sometime down the road. I’m guessing high-end clients have a little more money to throw at these world’s most critical applications…that may be 4-5% of all businesses and applications but there are a lot of others out there who aren’t even aware of the basics, much less are focused on fixing the problems.

I think it makes better business sense to spend time/money/effort on the low-hanging fruit that every app has now and when/if time and money permit make it “perfect” eliminating everything if that’s what you think is best for your business.

Thanks for your comments. I hope you’ll keep an eye out on my future posts.

I’m frankly stunned that anyone would argue that the only important problems in appsec are the ones you listed: XSS, authentication, and misconfiguration. The T10 aren’t “nook and cranny” issues. Now, we’ve shown our work in the T10 with a risk rating scheme that explains how the risks are ranked — if you think the factors we use are rated incorrectly, please let us know where.

With regard to application logic flaws, I’m confused about what you mean. Your list is entirely covered by the T10 already. The OWASP T10 has nothing to do with whether problems can be found automatically (scanned) or not. There are plenty of instances in every one of the T10 that cannot be found without human insight.

My point was that we shouldn’t make a new T10 item for things that are already covered by the existing T10. When you look at the examples of application logic flaws that people talk about, they almost always are a problem with a missing, broken, or misused security control — most of which are already in the T10.

I appreciate your feedback on my security assessment work. I use commercial scanners to find vulnerabilities because in my experience they find much more than the freebies do. Classic case of “you get what you pay for”. I guess the applications I look at are a little more secure than the ones you all are finding all this other stuff in. I still stand by what I said – taking context, false positives, exploitability, and overall business urgency into account I’m just not seeing much of the other stuff. Sure I’ve seen CSRF, URL access issues, unvalidated redirects, etc. but rarely are they exploitable to the extent that they create high priority risks for a business.

We can pick knits all day and find “flaws” in every nook and cranny of any given application but that’s not how the real world works. You’ve got to find the low-hanging fruit that’s both “urgent” and “important” and based on what I’m seeing most organizations aren’t anywhere near getting even these basics under control. Unless and until the essentials have been covered hardly anyone can justify fixing every single “issue” that comes up. It may look good to the auditors, it’ll definitely help developers and admins feel better, and it may help management rest better a night but, man, we’ve got a long way to go with Web security before we reach such a proactive state. Regarding OWASP ASVS levels it’d be nice for everything we do to include your standards but Web security doesn’t fully revolved around OWASP. Maybe one of these days…

Regarding application logic flaws being just “problems with typical security controls”…maybe, hence my qualification of them being hard to quantify. However, easily 40-50% of any given Web security assessment involves manual analysis to uncover flaws in login mechanisms, privilege escalations, application interactions with users and third-party systems, browser behavior, password changes, hidden fields, etc. If you’re not checking for these things *manually* then you’re doing the application owner, developers, customer, and ultimately the people whom the sensitive data such as credit card numbers and healthcare records belong to a BIG disservice. Not even a mention of application logic flaws in the OWASP Top 10 leaves a big hole and helps generate a false sense of security that all’s well if the scanners say so. Web security is much more complicated.

“All the others are either non-existent or don’t matter all that much in the grand scheme of things.”

If you’re not finding Injection, Insecure Direct Object References, CSRF, Failure to Restrict URL Access, Unvalidated Redirects and Forwards, and Insecure Transport Layer Protection in every web security assessment you do… you’re just not looking. And the risk from these is easily comparable to the ones you list. Could you let us know what OWASP ASVS level your assessments target?

“Furthermore, there’s one big thing missing from the OWASP Top 10 altogether: application logic flaws. It’s hard to quantify but broken application logic is arguably the biggest security hole in any given application”

Can you identify any “application logic flaws” that are not really just problems (missing, broken, misused) with the typical security controls – most often access control. There are a very few problems that it really requires a knowledge of the business in order to identify as a problem. Making it a Top 10 item doesn’t make sense to me.