[WEB SECURITY] WASC Threat Classification vs. OWASP ASVS

Arian J. Evans arian.evans at anachronic.com
Wed Jul 15 11:30:12 EDT 2009


What you are discussing was not addressed in the TC/1. I will let the
primary folks involved in TC/2 speak more to what they are doing
there.

Attacks usually have a many-to-one mapping to weaknesses.

Some things are easier to describe and report as "weaknesses", like in
the case of "insufficient authorization". The "attack" is most often
some form of parameter tampering, and as a subset some form of integer
fuzzing/rotation attack.

Session Fixation and HTTP Response Splitting are two more slippery
one. Both terms contain *multiple* attack types under their
definitions, but at least in the case of HTTP/RS describing the
weakness usually does nothing to explain the attack and implications.

Describing both attack and weakness, and mapping the together, is
definitely a great idea.

-- 
Arian Evans





On Wed, Jul 15, 2009 at 2:07 AM, Vishal Garg<vishal.garg at firstbase.co.uk> wrote:
> Hi All,
>
> My question here is bit off the topic under discussion. As I was reading
> this thread, I browsed to the web page for this project. The table on the
> web page has two columns, one for Attacks and one for Weaknesses. Also at
> the top of the page, the description goes like this:
>
> "The Threat Classification is an effort to classify the weaknesses, and
> attacks that can lead to the compromise of a website, its data, or its
> users."
>
> The web page does not have any definition for a weakness and an attack. I
> might be wrong here, but my understanding is that the authors have possibly
> considered both 'weaknesses' and 'attacks' as separate terms, while I would
> think that these two terms are related to each other, where a weakness in
> the web application would lead to an attack. If what I am saying is correct,
> then we should have one column for weaknesses and another column for attacks
> and there should be a mapping which lists which weakness would result in
> which attacks e.g. a server misconfiguration may lead to Path traversal or
> DoS attacks, insufficient data validation may lead to injection attacks and
> insufficient authorization may lead to privilege escalation attacks. This
> mapping would tell web developers that securing an application against a
> weakness would protect the web site against all those attacks that may occur
> as a result of that weakness.
>
> I might have missed something here, but any comments are welcome.
>
> Vishal
>
>
>
> At 17:23 13/07/2009 -0700, Arian J. Evans wrote:
>
> The guy asked "which do you use for a blackbox test?" I said WASC/TC because
> WASC/TC is blackbox.
>
> "XSS" and "SQLi" are blackbox tests. You review code for errors of
> commission, largely. If you look in source you are typically looking for
> document.write and/or no escaping or lack of output encoding.  Verifying an
> exploitable runtime condition is a blackbox test by definition.
>
> OWASP ASVS is largely oriented around verification process and leverages
> whitebox concepts and terms quite heavily.
>
> Not a a bad thing at all.
>
> So it is obvious that WASC/TC is the blackbox answer, and you could wrap up
> in an an ASVS process and simply replace their verification terms with ones
> more appropriate for blackbox, thus removing the OWASP whitebox and ESAPI
> bias in ASVS.
>
> Just trying to stay On Topic.
>
>
> --
> Arian Evans
>
>
>
>
> On Mon, Jul 13, 2009 at 12:16 PM, Jim Manico <jim at manico.net> wrote:
> I'm a huge fan of OWASP ASVS because it leads us out of the neverending rat
> race of finding and fixing flaws. It focuses only on critical software
> controls needed to build a "secure" application. I tried adding in a few
> best practices that were rejected because they only wish to include
> •necessary• controls, a good thing, I think.
>
> I approach AppSec from a defensive coder perspecive; I just want to know
> what features to add to my software. ASVS helps me measure my software in
> that regard very well.
>
> To put it a other way, if I focus on vulnerablity assessment, I know what
> vulns I have and can fix those. Reminds me of blacklisting.
>
> If I focus on controls (ASVS + ESAPI) I tend to be able to build an app that
> can stand the test of time.
>
> Now, the WASC folks are super smart, and the threat classification is a
> solid body of work. Control based AppSec is not something I hear about often
> on these lists.
>
> Jim Manico
>
>
> On Jul 13, 2009, at 1:01 PM, robert at webappsec.org wrote:
>
> Hello Roger,
>
> I lead the WASC TCv2 project and will be able to answer your questions,
> albeit with a bias towards the TC.
> For starters I am not the best person to speak on behalf of the OWASP ASVS
> project (maybe they will respond?)
> so I simply won't speak on it other than to say it appears to focus more on
> process and maturity levels.
>
> Second please take a peek at
> http://projects.webappsec.org/Using-the-Threat-Classification as it outlines
> ways people use the TC (myself included). Speaking on my own personal
> experience (and others that I know)
> I use the TC as
>
> A checklist:
> I use the TC as a checklist of potential security issues (the TC breaks this
> up into attacks and weaknesses)
> that my application/site is likely to be affected by. I evaluate which
> functionality my application offers from
> a business and technical perspective and map that functionality to possible
> weaknesses and attacks that will need
> to be evaluated during a security review. For example if my application uses
> XML and XQUERY I'd add XML Injection
> ( http://projects.webappsec.org/XML-Injection) and XQuery Injection (
> http://projects.webappsec.org/XQuery-Injection)
> to a list of security concerns, effectively creating a minimum security test
> plan/threat model. I then ensure my
> security evaluations/testing is checking (at the least) for the attacks and
> weaknesses against this list. I've
> personally had a situation where I've used the TC on a pen test with a 3rd
> party and asked if they performed 'x'
> testing which they responded no. Shortly after they performed the testing
> and found an 'x' issue. In this situation
> I used the TC as a checklist and it resulted in a finding that may or may
> not have been discovered had I not asked.
>
> Reference Material
> When I file a security defect I provide a URl to the appropriate TC section
> for additional reading by development
> and/or QA. This saves me time rewriting/explaining the issue and being to
> brief. The TCv2 sub sections are all group
> peer reviewed in multiple phases and once they are completed are locked
> (random website visitors cannot modify them
> as with a traditional wiki).
>
> Security Metrics
> In particular the ability to flag defects with a certain attack or weakness
> flag allowing me to gain better insight into
> the more prevalent issues. This has been useful in developing better
> security training, enhancing security testing/finding
> gaps, and evaluating priority for security component development.
>
> Chances are you'd probably utilize both for different aspects in your
> security program.
> Based on your email I will likely write an in depth article on using the TC
> beyond the light wiki page above
> as we near publication.
>
> Regards,
> - Robert Auger
> WASC Co Founder and Threat Classification v2 Project Leader
> http://www.webappsec.org/
>
>
> I'm putting together a requirements list for black box web pen testing
> and want to include a standards requirement. I've looked intothe WASC
> Threat Classification and OWASP's ASVS. The former seems to focus on
> high level threats, while the latter on testing controls present in
> the app. With the release of version two of the threat classification,
> which standard is more appropriate to use for web app pen testing and
> why?
>
> Thanks,
>  Roger
>
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS: http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



More information about the websecurity mailing list