[WEB SECURITY] WASC Threat Classification vs. OWASP ASVS]
bugtraq at cgisecurity.net
bugtraq at cgisecurity.net
Wed Jul 22 20:26:47 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.
Sure, and thanks for bringing it up as it allowed me to better document this
prior to the final release.
I have updated (and renamed) the challenges page to 'tc evolution' to better
communicate this at http://projects.webappsec.org/TC-Evolution.
- Robert Auger
> 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
> >at http://projects.webappsec.org/Challenges).
> >- 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
> >issue (55%+)
> >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
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