18 comments:

kingthorin
said...

It kind of scares me that such a document needs to be created for the industry. Anyone dealing with these things should be able to come up with the same thing within about 5 sec of staring at the two lists (maybe A4 is the exception...but still).

@kingthorin, the web security industry is growing dramatically. As such, there is a steep learning curve for the new comers. We should do as much as we can to make the assimilation and utilization of knowledge as easy as possible.

This isn't reflected in your graphic mapping but there is also a link between Insufficient Anti-Automation in the TCv2 and A7 - Failure to Restrict URL Access. Specifically, Brute Force and Denial of Service attacks would also be subcategories of A7. Most people think of only the insufficient auth category where people use security-through-obscurity and post sensitive data on a website and fail to properly restrict access by implementing some form of ACL.

The current OWASP Top 10 view for A7 is narrow in scope and solely focused on a binary decision of whether or not a client should be allowed to access a resource or not. What was discussed on the topten mail-list was that the scope should be expanded to include not just if a client should have access but also at what velocity. This leads to anti-automation defenses to combat brute forcing, DoS and Scraping types of attacks.

How about WASC-13 to A6? While this has fallen off the current OWASP Top 10 (and legitimately not everything can be in the top 10) I still get a lot of intelligence value from inappropriately verbose error messages. IMO, dumping db errors, stack traces, etc back to the user should at least be considered a misconfiguration (i.e. no custom error page configured).

-Specifically, if you are running a tomcat server and you do not change your web.xml to specify an error-page then you will expose stack traces in the default error page (which are useful for WASC-45(fingerprinting)).

-Similarly, if you are running apache and you do not turn-off directory indexing, this is a security misconfiguration that enables WASC 16.

I think my larger issue is that WASC and OWASP are (IMO) kind of inconsistent. For example, the WASC threat classification includes attacks, weakness categories and individual instances of weaknesses. OWASP has similar issues.

There are perhaps other things in this mapping that might be worth discussing, i.e. why no SSI Injection linked to A1? Add WASC-1,2,14,15,42 to A9? Add WASC-14,15 to A10? etc...

@DanAnderson Thanks for clarifying. I see where you are going now. With respect to WASC 13 (information leakage), I think including this in A6 might lead us to a bit too broad of a definition. However, do you think it be safe to assume that a large portion of information leakage issues are a direct result of misconfigured settings like you described? If so, then I'd be inclined to add it. Just don't want to add an relative edge case.

Either way, I'll be adding WASC-16 to the mapping.

Others also asked why I didn't map SSI Injection to A!. A1 says,"Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusteddata is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data."

Which to me is not at all how SSI injection works, despite the word "injection" in the title.

yes, lets not perfect get in the way of good, but we can fine tune over time. :)

They might have been better off with a generic "Injection Attack" (attack) or "Injection Flaw" (weakness).

So... If you had to categorize SSI Injection (or code injection for that matter) into one of the 10 boxes that OWASP gives us, or "None of the above", would you categorize it as "Injection" or "None of the above"?

@DanAnderson, probably none of the above since none of the definitions match appropriately. Since, the top ten is not meant to be all inclusive, per its very nature, not everything in it needs to have a WASC association.

I agree with Dan about WASC-13 Information Leakage being a sub-category covered under the OWASP A6 - Security Misconfiguration section. I brought up this same rationale on the OWASP top ten project list and everyone agreed.

The best example I can give is with ASP.NET's detailed stack dump error pages. If you look at the html source - it even warns the user that they should reconfigure the customerrors mode setting in their web.config file in order to not send this sensitive/technical data to the client.

Jeremiah--I appreciate and agree with your comments about the learning curve for newcomers. I'm an MSIA student with very little non-academic InfoSec experience.

I feel I pretty much have to spend every minute of my spare time reading, and scouring the web for documents like this to feel like I have will be relevant in the industry by the time I graduate. Thank you for making this information more readily available! (I may not have found it if I hadn't subscribed to your RSS....)

Hy, I would like to know if there is a mapping between wasc TC-v2 attacks and weaknesses. The classification dont tell anything about relations between attacks and weaknesses. They are outlined separately. Is there a reason for not mapping weakness and attacks.

About Me

Jeremiah Grossman's career spans nearly 20 years and has lived a literal lifetime in computer security to become one of the industry's biggest names. He has received a number of industry awards, been publicly thanked by Microsoft, Mozilla, Google, Facebook, and many others for his security research. Jeremiah has written hundreds of articles and white papers. As an industry veteran, he has been featured in hundreds of media outlets around the world. Jeremiah has been a guest speaker on six continents at hundreds of events including many top universities. All of this was after Jeremiah served as an information security officer at Yahoo!