[WEB SECURITY] Severity Rating of Cross Site Scripting

Wed Sep 27 01:26:54 EDT 2006

Therein lies the problem with the subjective "risk" or "Severity"
ranking used by automated testing tools. BTW Jeremy, you were exactly
right in calling them 'vulnerability assessment' and not 'risk
assessment' tools. 

I'm not opposed to automated tools - we, and many other consultancies
use them as a component of performing a risk assessment. However...
Automated tools don't measure 'risk,' they identify potential
vulnerabilities. Automated tools perform vulnerability assessments. It
takes a human to perform a risk assessment. To produce quantitative, as
opposed to qualitative risk metrics, you have to use some kind of formal
threat model. I like the Microsoft DREAD model, there are others out
there that serve a similar purpose. 

I don't intend to belabor semantics here, but I think it's an important
distinction. When people have a conversation that we commonly define
words. My point, if I have one :), is that I wouldn't worry so much
about what the "severity" or vulnerability" ranking of other vendors is
in terms of coarsely granular ratings like "High" "Medium" and "Low"
when you don't all share a common definition of what those words mean. I
could think of more than a few examples where risks identified by the
automated tools as 'Low' end up as a "High" when measured according to
it's DREAD threat model composite score.

Just my $0.02 fwiw.

     Adam Muntner, CISSP | c: 602-793-5969 
                 Partner | f: 866-272-8194
         QuietMove, Inc. | w: http://www.quietmove.com
Securing the Nexus Between People, Technology, and Information.
                       ((Q))

On Tue, 2006-09-26 at 15:09 -0700, Jeremiah Grossman wrote:

> I think that's been one of the gating items in getting people to take  
> the issue seriously. XSS is attack on the user rather than the  
> website. *most of the time*. Which also plays havoc when you have to  
> figure in importance to "who" in calculating severity.
> 
> 
> On Sep 26, 2006, at 2:52 PM, Bill McGee ((bam)) wrote:
> 
> > I don't know how you can separate the two. One of the factors  
> > customers use to rate risk is to determine the value of the item in  
> > harm's way.
> >
> >
> >
> > I would buy very different insurance for a Lexus (full coverage)  
> > than I would for a Pinto (Basic Liability.) The chance of being in  
> > an accident is relatively the same for both vehicles. The items at  
> > risk, however, are quite different and require a different response.
> >
> >
> >
> >
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Bill McGee, Senior Manager
> >
> > Application Networking and Security Services
> >
> > Central Marketing Organization
> >
> > Cisco Systems, Inc.(R)
> >
> > www.cisco.com/go/security
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Jeremiah Grossman [mailto:jeremiah at whitehatsec.com]
> > Sent: Tuesday, September 26, 2006 3:38 PM
> > To: Web Security
> > Subject: Re: [WEB SECURITY] Severity Rating of Cross Site Scripting
> >
> >
> >
> > Sticking on that vein, web banks, would you rate all XSS issues as
> >
> > high on the site? If so,  then are we saying we should assign XSS
> >
> > severity based on the subjective importance of the website?
> >
> >
> >
> >
> >
> > On Sep 26, 2006, at 2:25 PM, Ryan Barnett wrote:
> >
> >
> >
> > > Severity is tricky because it depends on who you are reporting the
> >
> > > severity to.  Many organizations don't really care about XSS
> >
> > > because they are targeting end users and not the web application
> >
> > > itself.  If an XSS flaw allows someone to send an attack to steal
> >
> > > someone's session/credential data on a user-board, what is the
> >
> > > severity?  Probably would be LOW from the website's perspective but
> >
> > > maybe HIGH from the user's point of view.  Now, if the webapp is a
> >
> > > banking app instead of a user forum, then we have a whole new
> >
> > > ballgame.  Once money is involved (e-commerce/banking, etc...) I
> >
> > > think that they should all be HIGH.
> >
> > >
> >
> > > So, I guess that it is difficult rate the severity in general but
> >
> > > should be based on the functionality of the webapp itself.
> >
> > >
> >
> > > --
> >
> > > Ryan C. Barnett
> >
> > > Web Application Security Consortium (WASC) Member
> >
> > > CIS Apache Benchmark Project Lead
> >
> > > SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
> >
> > > Author: Preventing Web Attacks with Apache
> >
> > >
> >
> > >
> >
> > > On 9/26/06, Jeremiah Grossman <jeremiah at whitehatsec.com > wrote:
> >
> > > Cross Site Scripting (XSS) has really come into its own during the
> >
> > > past 6 months. XSS now tops Mitre's CVE [1] and the WHID [2], not to
> >
> > > mention all the media coverage during the last week. We've come to
> >
> > > understand how incredibly severe XSS attacks can be considering
> >
> > > Intranet Hacking [3] and Web Worms [4]. Typical cookie theft seems
> >
> > > harmless by comparison. As a result, one of the questions that has
> >
> > > resurfaced is severity rating.
> >
> > >
> >
> > > In previous years, most vulnerability assessment reports I've read
> >
> > > understandably assign XSS vulnerabilities as "Medium". The same is
> >
> > > true at WhiteHat Security. We rate non-persistent as "Medium",
> >
> > > persistent as "High", with the vast majority being non-persistent.
> >
> > > Today what's happening is the potential business impact of XSS has
> >
> > > grown much greater and the threat differential between non- 
> > persistent
> >
> > > and persistent is diminishing. For vulnerability reporting purposes
> >
> > > we're compelled to increase the severity rating of almost all XSS
> >
> > > issues to "High". This would seem to make more sense based on  
> > what we
> >
> > > now know.
> >
> > >
> >
> > > What I'm interested to know how others in the industry view XSS in
> >
> > > terms of severity rating. Are there plans to increased reported
> >
> > > severity?
> >
> > >
> >
> > >
> >
> > > Regards,
> >
> > >
> >
> > > Jeremiah Grossman
> >
> > > Chief Technology Officer
> >
> > > WhiteHat Security, Inc.
> >
> > > http://www.whitehatsec.com/
> >
> > >
> >
> > >
> >
> > > [1] Vulnerability Type Distribution in CVE
> >
> > > http://www.attrition.org/pipermail/vim/2006-September/001032.html
> >
> > >
> >
> > > [2] Web Hacking Incidents Database
> >
> > > http://www.webappsec.org/projects/whid/
> >
> > >
> >
> > > [3] Hacking Intranet Websites from the Outside
> >
> > > "JavaScript malware just got a lot more dangerous"
> >
> > > http://jeremiahgrossman.blogspot.com/2006/08/home-from-blackhat-and-
> >
> > > defcon.html
> >
> > >
> >
> > > [4] Teen uses worm to boost ratings on MySpace.com
> >
> > > http://www.computerworld.com/securitytopics/security/holes/story/
> >
> > > 0,10801,105484,00.html
> >
> > >
> >
> > >
> >
> > >  
> > ----------------------------------------------------------------------
> >
> > > ------
> >
> > > The Web Security Mailing List:
> >
> > > http://www.webappsec.org/lists/websecurity/
> >
> > >
> >
> > > The Web Security Mailing List Archives:
> >
> > > http://www.webappsec.org/lists/websecurity/archive/
> >
> > > http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> >
> > >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------- 
> > ------
> >
> > The Web Security Mailing List:
> >
> > http://www.webappsec.org/lists/websecurity/
> >
> >
> >
> > The Web Security Mailing List Archives:
> >
> > http://www.webappsec.org/lists/websecurity/archive/
> >
> > http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> >
> >
> 
> 
> ----------------------------------------------------------------------------
> The Web Security Mailing List: 
> http://www.webappsec.org/lists/websecurity/
> 
> The Web Security Mailing List Archives: 
> http://www.webappsec.org/lists/websecurity/archive/
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20060926/266bae4e/attachment.html>