Thursday, November 5, 2009

XSS via Cookie - How Severe?

Take a web application that sets a cookie. Now let's say the application takes the cookie value included in subsequent requests and outputs it into the HTML of the responses. Also assume this occurs with no authentication required and with no output encoding being done. Yes, this application is susceptible to reflected cross-site scripting.

I recently tested such an application. Interestingly, both HP WebInspect and Burp's active scanner reported the XSS vulnerability, but they were at opposite ends of the spectrum in terms of rating its severity. WebInspect rated it "critical" (the most severe rating), while Burp rated it as "information", which implies you don't even need to concern yourself about it.

So why the big disparity in these tools? Is it critically severe, or is it really no big deal? In my view, the answer is somewhere in between. This type of vulnerability is clearly very difficult to exploit. An attacker would somehow have to cause a victim's browser to send a script-injected cookie as part of a request to the vulnerable site. But regardless of the difficulty level, the application should properly encode the cookie value when it is written into the HTML page. Please let me know your opinion on how serious you think this type of vulnerability is.

4 comments:

Anonymous,  11/12/2009 2:08 PM  

Shouldn't it be considered high soley due to the ease of remedy?

I have always felt that solution time should be factored into the rating of a vulnerability.

Is this one difficult to exploit? Maybe, but not if you use a shared machine (yeah,I know there's a lot of other issues that can happen besides this but people still use them for things they shouldn't.

Dave Ferguson 11/12/2009 4:44 PM  

Absolutely. Better to fix and not worry about the severity. The shared machine situation is a valid attack vector.

Security Retentive 11/13/2009 3:59 PM  

The whole point here is that you have to rank things against exploitability, not ease of fix. This doesn't mean you only fix P1 bugs, but it does mean you fix them before you fix P2 bugs, mostly anyway.

The severity of this vulnerability depends on the application too. Is it an internet-facing app with users who often connect on wireless networks, or is it an application that is internal to a company where the likelihood of a MITM to exploit this one vulnerability might not be quite as high.

A lot of factors to consider. Me, I wouldn't rate it a super high severity, but probably would advocate for it getting fixed fairly quickly.

Alex 11/17/2009 2:30 PM  

As an attacker, if you can obtain the user's cookie (e.g. with local access or session fixation), you don't need XSS in the first place.

If you can inject script, you wouldn't want to inject a script to set a cookie to steal the cookie, you would just steal the cookie in the first place.

The only way I see this as an issue is if the attacker can forge HTTP request headers to the target domain, which is unlikely.

It's definitely still worth noting as part of defense in depth, and it's impossible to think of every possible scenario/attack.

  © Blogger templates The Professional Template by Ourblogtemplates.com 2008

Back to TOP