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:


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?

3 Answers 3


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.

  • Very interesting, thanks! Burp marked it as Medium severity and they mention that it is "not trivial" to exploit. Seems to be inline with your answer. Commented Oct 16, 2014 at 20:19

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.

  • If the attacker has full control over the victim's traffic, and the requested HTTPS site is not so "popular" to exists in the HSTS preloaded lists hardcoded in the browsers... well, the attacker can strip the HSTS header before it return the reply from the server to the victim, and there is no way for the victim to know that this site is actually using HTTPS (if the first request from the victim's browser is done over plain HTTP and in that moment the attacker is man-in-the-middle)... Commented Oct 16, 2014 at 20:25

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.

  • I'm not saying that they need to click the link to execute the javascript, I'm saying they need to click the link that has the javascript in the URL in order to be taken to a page where that javascript will be rendered on the page and then executed. Commented Oct 16, 2014 at 20:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .