Changes coming to the OWASP Top 10 in 2010

In the spirit of improving Web application security worldwide the folks at OWASP have released the OWASP Top 10 2010 “release candidate”. It’s currently open for comments and scheduled for final release the first quarter of next year. The biggest change you’ll see in this latest incarnation of the Top 10 is they’re now taking a risk-based approach to the highlight the business issues at hand. Perfect. Just what we’ve needed. Or is it?

The one thing that really jumped out to me is how the OWASP team has incorporated the attack path graphics and example attack scenarios for each of the Top 10 items. They show how application threats exploit application vulnerabilities which create business risks. There are many people in our field who still haven’t wrapped their heads around this basic concept. But it’s the basis of everything we’re doing – and why we exist – and therefore critical for us to know. If we’re ever going to be get management on board with application security we have to talk in terms of business payoffs and what’s in it for them. Using graphics to break down how the bad things happen is a great way to paint the picture and educate others.

I still think there’s a disconnect. On one hand the new OWASP Top 10 presents higher-level risk concepts but on the other it delves directly into technical details with little explanation of what things mean. This will turn some people (especially managers) off. Maybe I should submit a comment. Don’t get me wrong – I still think this is a great start and will help move application security along to where it needs to be. It’s just not ideal in its current state.

You’ll notice a couple of the items have been dropped from the new Top 10 list (Malicious File Execution and Information Leakage and Improper Error Handling), several have been renamed for clarification, and there’s also a new one: Unvalidated Redirects and Forwards. Those are the big changes thus far.

Even with the updates, how does the OWASP Top 10 compare to the real-world? Are the 10 items pervasive across the Web? Hardly not. Do you need to check for every single item? It wouldn’t hurt. There are so many variables and every situation is different. I’ll cover this more in-depth in a future post. I can say that of the 10 items there are only three biggies that come up in every Web security assessment I do: 1) Cross Site Scripting, 2) Broken Authentication and Session Management, and 3) Security Misconfiguration. All the others are either non-existent or don’t matter all that much in the grand scheme of things. 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.

It’s funny how everyone has been saying that we need to take a risk-based approach to information security yet we haven’t been following our own advice. Now that we’ve experienced the “compliance ≠ security” fallout, it’s time to get down to business, literally. It’s not going to be easy though. I truly believe that until the OWASP Top 10 project becomes more widely-recognized among developers and testers the vendors, consultants, and IT pros will continue preaching to the choir ranting to each other about the insecurities of the Web. Not much value in that but at least we’re heading in the right direction.

Share this post
  • I think the comment about being accessible to managers is fair and OWASP should look at that harder.

    “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.

  • Thanks for the comments Jeff. I do think if OWASP can improve its visibility that’ll really help everyone. I hope to think I’m doing my part. ;-)

    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.

  • I’m working with many of the most advanced appsec programs in the world to secure some of the world’s most most critical applications. They *all* consider the items that you’re calling “rarely exploitable” to be extremely critical risks – specifically because they are easy to discover and exploit and have significant business impact if they are. Virtually everyone agrees that SQL injection is the most significant appsec risk to enterprises.

    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.

  • Jeff – I appreciate your perspective. I didn’t say that SQL injection is not important. I’m working on a project right now where I found SQL injection and, in fact, this very minute I’m siphoning data out of the database to show my client that this is a REAL BIG issue. However, this is only my second truly exploitable SQL injection in hundreds and hundreds of scans over many years where sensitive information may be at risk. I consider that pretty rare/non-existent.

    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.

  • Thanks Kevin – I’m not attacking, just trying to understand your perspective.

  • Leave a Reply

    Your email address will not be published.


    *