Is cookie-based XSS exploitable?

Question

Today I've found interesting site that output your cookie value directly to the page, so if I modify the cookie value I can XSS myself.

e.g <span id=statistics>Last visit: Cookie_Value_Of_Something</span>

So my question is, do you think this is vulnerable or can I exploit this?

It looks like useless to me so far.

Answer 1

To exploit this flaw, the attacker would need to manipulate the user’s cookie. And this is only possible if he is able to exploit another vulnerability that allows him to set the cookie with the XSS payload as one can only set cookies within the domain the Set-Cookie originated from:

The user agent will reject cookies unless the Domain attribute specifies a scope for the cookie that would include the origin server. For example, the user agent will accept a cookie with a Domain attribute of "example.com" or of "foo.example.com" from foo.example.com, but the user agent will not accept a cookie with a Domain attribute of "bar.example.com" or of "baz.foo.example.com".

And besides compromising the server, there are two possible attack vectors for manipulating the cookie value: Either the attacker manages to inject the exploit into the value that gets set as the cookie value by the site author’s script, e.g., some user provided values are used for the cookie value. Or the attacker has access to a sub-domain and he is able to set a cookie for the super-domain in which vulnerable script that prints the cookie value resides. Both vectors can be executed by using Cross-Site Request Forgery.

Answer 2

It's not exploitable in itself, but it's a potential escalation path for an attacker to go from cookie fixation to full XSS.

Notably:

1. If the site is running on a hostname that has neighbour domains, any XSS attack on those neighbours means a cookie can be written to the shared parent domain, escalating to an XSS attack on the site. eg. from untrusted-uploads.example.com they can write a cookie with domain example.com, which will be read by trusted-www.example.com.

2. If the site is running on https://www.example.com/, an attacker can still spoof a site at http://www.example.com/. Any cookie set from there will be readable from https - script at https would not detect that the cookie was not created with secure. So cookie-XSS makes HTTPS ineffective (except where foiled by Strict Transport Security, but that's not a complete defence).

It's not really possible(*) for a script (either server or client side) to detect that the domain, path, secure or httponly flags on the cookie match the values expected, which means you can't reliably detect injection of cookies from outside your site.

(*: there are potential hacks where you attempt to override a cookie by setting a new one with the flags you want, but ultimately it's not completely reliable as the attacker script could be running at the same time.)

Answer 3

Once upon a time flash was vulnerable to CRLF injection (IE was also vulnerable), and this could have been used to set the Cookie: HTTP request header to exploit cookie-based XSS. But this is no longer the case. It is not possible to set a Cookie on another domain. If you could set cookies for other domains it would make session fixation very difficult to prevent (if not impossible).

Answer 4

It's useless. Due to the same-origin policy, text on a page cannot be read by other sites, just like cookies.

It is readable by an attacker running an MITM attack, but so are the cookies (unless the connection is HTTPS).

Answer 5

The only real attack vector would exist in a situation where there is another vulnerability. For example if you could upload an executable script such as some PHP code you could manipulate the cookie using that script to inject some JavaScript into the users session. You would also need to perform the usual social engineering to get the user to visit your uploaded script.

Answer 6

It depends on which cookie is been output.

Some sites write 3rd party data into cookie values (have a look at Facebook's reg_ext_ref cookie for anonymous user, it's full referrer). Can believe some sites do store last search query that user typed in or something like that (and sometimes you can forge that last query with GET-params). So, if at least one of that-like cookies is being output, you should try to exploit this.

I'm not saying your case is a good attack vector, it's just worth some investigation.

Answer 7

Nota bene: I'm commenting on this ticket after all this time as this is still one of the top answers on google for is cookie xss exploitable.

The answer is that depending on context, then cookie XSS can often be exploited. Some routes to achieve this are (doesn't pretend to be fully comprehensive):

• injecting the payload into whatever sets the cookie in the first place;
• injecting the payload directly into the vulnerable endpoint via request header injection;
• injecting the payload directly into the vulnerable endpoint and poisoning the response (shared cache poisoning or cache deception);
• injecting the payload indirectly into the vulnerable endpoint via response header injection (this can be via any peer domain which can set a TLD cookie);