[WEB SECURITY] WASC Threat Classification vs. OWASP ASVS]
vishal.garg at firstbase.co.uk
Mon Jul 20 11:10:16 EDT 2009
Thanks for sharing this info. This is been the most useful info. in
clarifying the structure or current TC and the way it has evolved.
At 14:29 16/07/2009 -0400, robert at webappsec.org wrote:
> > It is good to see that we have brought all three major documents into
> > discussion (WASC-TCv2, ASVS and OWASP-TGv3). This is no criticism to
> > WASC-TCv2, but I can really understand the real purpose of ASVS and
> > TGv3 and know exactly how to use them. But I fail to understand the
> > real purpose of TCv2, while TCv1 made much more sense by classifying
> > threats in different categories
>I was waiting for someone to bring this up/ask a question about it but was
>expecting it around the time the tcv2 was completed (it is still in a working
>state). Prepare for a lengthy answer :)
>The TCv1 had a few problems as outlined below.
>Problem #1: Parent to child mappings
>Parent to child mappings where not clearly defined resulting in further
>confusion/ambiguity when we tried adding addition items (additional comments
>- SQL Injection parent is 'command execution'. This implies sql
>injection is a form of command execution
>- XSS is under client-side. This implies XSS affects/impacts the
>client/is a client side threat/attack.
>- Session Fixation is under Authorization. This implies the child
>(session fixation) impacts the authorization
> of the application.
>As you can see this isn't very consistent or clearly defined. Our
>options where changing it prior to tcv2
>going live, or continue to build on a confusing structure that would
>eventually need to change. We decided
>to take the 'hit' in changing it in 2.0 rather than continue with
>our sins :) (more info below on structure),
>Problem #2: The single tree structure
>Assuming #1 was addressed we still would have situations where a
>child could fall under multiple parents, or
>under sub parents (we experimented with this too). Would CSRF be
>listed under 'client side' since it impacts
>the user/client side, or somewhere else since it is a server side
>vuln? Suddenly we started to have a flurry
>of questions such as
>- Should the TC outline who/what was affected or where the problem lies?
>- Should we have a tree structure where an item shows up multiple times?
>- Should we have a dominant parent for an item and ignore the other
>possible locations/cross references?
>In order to make sense of these questions we found ourselves testing
>multiple classic tree structure concepts
>and things started to blur very quickly due to an individual item
>ONLY being under 1 parent.
>Problem #3: Who was our audience and should we expand this scope?
>After taking over the tc project I started asking people how they
>used it, and we pretty much had 4 use cases.
>A. As a checklist of issues to test for (30%+)
>B. As a reference for developers/folks to read more info on a given
>C. In academia to teach web security concepts (10%)
>D. In bug tracking systems to gather metrics on vulnerability types. (5%)
>We found that speaking with people that A,B,D users didn't really
>care about a single tree structure and cared
>more about the individual items/content within them. C on the
>otherhand found the structure to be extremely
>important (understandably) in order to teach relationships. By
>addressing #1 and #2 and selecting a single
>structure we'd be locked into one concept limiting ways this
>information could be used.
>After extensive discussions (for 3-4 months in a hundred+ emails,
>and several phone calls) we found ourselves
>at a crossroad where we had to change it in a way that would create
>a firm, non changeable foundation we could
>extend and not reduce the scope. We decided that we'd instead create
>a base view of indexes (attacks and weaknesses
>in tcv2), and that we'd create 'views' or ways to represent that
>data in future releases. This allowed us
>to solve the challenges of #1 and #2, as well as expand the scope
>beyond the 4 use cases in #3.
> > TCv2 appears to to have lost its purpose by listing
> > different attacks and weaknesses without actually classifying them as
> > such
>We are classifying the threats (http://projects.webappsec.org/TC-Glossary)
>that face a into attacks and weaknesses indexes, and within each item
>cross referencing when applicable. My above rants address the rest of this.
>- Robert Auger
Join us on IRC: irc.freenode.net #webappsec
Have a question? Search The Web Security Mailing List Archives:
Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
Join WASC on LinkedIn
More information about the websecurity