Reflected XSS through cookie value?

Question

I have always looked at reflected XSS as an attack that would take place through a URL. So, for example, you would have a URL like below:

http://someSite.com?message=welcome!<script>alert(1);</script>

and the message would be written to the page. In order to execute the attack you would need to trick someone into clicking on that link.

I was recently looking at a website using BurpSuite and it flagged a reflected cross site script vulnerability and the attack vector was a cookie value. While I could indeed change the cookie value to have it render javascript on the page, I don't understand how this could be used to attack another user.

In my first example, a user would need to click a link to execute the attack. How would you execute an attack with the second vulnerability?

Answer 1

Due to the same-origin policy for cookies, a kind of "chicken or the egg" situation is created. In order for the attacker to make this XSS vector viable, they would need another flaw to set the cookie value .

One possible exploit path is using a XSS vulnerability on a subdomain to leverage the following property of cookies:

 www.foo.bar.example.com may set a cookie to be sent to *.bar.example.com or *.example.com, but not to *.something.else.example.com or *.com

Another exploit path would be to use HTTP response splitting on a page that is performing a redirect. In this situation HTTP response splitting cannot be used to control the HTTP body, which is required for XSS, instead the attacker can inject a set-cookie HTTP header to exploit a cookie-based XSS vulnerability on another page.

In many cases this cookie-based XSS is not exploitable. Burp should have marked this issue as yellow, which reflects a medium/low likelihood of exploitation.

Answer 2

Cookies set over HTTP are presented over HTTPS.

If an attacker has full control of a victim's network traffic, they can set a cookie over HTTP, and this will cause an XSS attack against the HTTPS site. I believe that HSTS would stop this, although I haven't confirmed myself.

Answer 3

Once the injection is present, one does not need to 'click on the link.' In the example provided, should the HTML + JavaScript be rendered, then the alert() code will run automatically - without user interaction.

This works in both examples - regardless of where the XSS is located in the HTTP session. All that is necessary is that the XSS is redirected to a suitable place within the target document.

Once that hole is exploited, many things can happen. Also remember that XSS may be persistent in the DB of the remote system. The browser is always the victim in an XSS attack, but a compromised database (containing persistent XSS), is also a victim from the perspective of the system Administrator.