Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
    
What kind of cookie is that? –  Gumbo May 19 '13 at 6:16

6 Answers 6

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.

share|improve this answer

Once upon a time flash was vulnerable to CRLF injection, 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).

share|improve this answer

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).

share|improve this answer
    
HTTPS connections are readable as well. crypto.stanford.edu/ssl-mitm –  AbsoluteƵERØ May 19 '13 at 17:07
    
@AbsoluteERØ: Yes, but that involves a certain degree of stupidity on the victim's behalf. At one point security boild sown to the user, it's hard to make any efforts beyond that. –  Manishearth May 20 '13 at 3:23

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.

share|improve this answer
1  
If it were possible to upload a PHP or HTML file, the attacker could print out the JavaScript directly without the need to exploit the XSS vulnerability via cookie. And in case of PHP, he could certainly prepare any file on the site to deliver his exploit. –  Gumbo May 19 '13 at 6:07

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.)

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.