With most of the work done by Bil Corry (@bilcorry), here is a solid first pass at creating a mapping between the newly released WASC's Threat Classification v2 and OWASP's Top Ten 2010 RC1. This should help those actively using one or both of use documents.
18 comments:
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.
Nice graphic to help people connect the dots ;)
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.
@Ryan, I suspect your probably right, but I'm having trouble thinking of examples. Can you give me a for instance linking Brute Force and/or Denial of Service to A7?
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.
@Ryan, with those examples, now it makes good sense. Image updated.
@Mr. Grossman, it's such a useful document. Thank you. We really needed one. :)
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).
@DanAnderson hmm, on the face of it, that could only be a very loose connection. Could you describe an example so I can better understand what you're looking at?
You'll have to excuse me, I'm having an ontological crisis. :)
For the subject at hand:
-A6 addresses configurations of the various components in a web application that may present security risks when improperly/inconsistently configured
-WASC 14 and 15 address these improper configurations within servers and applications
-WASC 13 (information leakage) and WASC 16 (directory indexing) are often specific instances of WASC 14 (server) and/or 15 (application).
-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...
On the other hand, maybe at some point it is "good enough".
@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. :)
I suppose SSI Injection is a bit different. Although, I generally consider "Injection Attacks" to be more generic.
I prefer the way Mitre does it (http://capec.mitre.org/data/definitions/152.html.) Which includes SSI Injection as a child of injection (http://capec.mitre.org/data/definitions/253.html.)
I'm not sure about WASC's approach. They seem to specify an incomplete list of specific types of injection attacks (i.e. no code injection (asp, jsp, php, etc), html/link/image injection, etc).
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....)
@Dusty glad you found the content useful. Gotta keep making this stuff visible and easier to digest.
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.
Thanks,
Post a Comment