1

Recently I worked with a PHP framework and saw that it was putting html in a cookie to read it from javascript (don't ask me why).

I tried to alter the html in the cookie by putting an alert('bingo') instruction and it worked. Can this behaviour be used as main channel for XSS assuming no other server side vulnerabilities are present?

In other words: how can an attacker use this behaviour given this is the only known vector?

|improve this question
  • "... given this is the only known vector?" - am I right that you mean with that that if the attacker could change the cookie there would be XSS (i.e. the only known attack vector) but that the attacker unfortunately cannot change the cookie (not a known attack vector)? Or can one assume that the attacker can change the cookie - in which case you just have XSS with all its possibilities. Or don't you know if the attacker can change the cookie and expect us to figure this out without providing any useful information about the application? – Steffen Ullrich Sep 8 '17 at 14:20
  • if he can change cookies, why can't he change the rest of the packet or just run the code directly? – dandavis Sep 8 '17 at 14:31
  • @SteffenUllrich what I'm asking is if there is some fancy way that I don't know to alter cookies in a way that allows to exploit this strange behaviour. Obviously if an attacker has server side access having an xss is the latest of problems. – Mir Sep 11 '17 at 8:21
  • @Mir: there might be some fancy way to alter the cookie you don't know yet. But, it is unknown to us what you know and there are not enough details about the web application to find out if there is some way to alter the cookies. – Steffen Ullrich Sep 11 '17 at 9:55
5

Assuming there are no other vulnerabilities in the website I don't believe this is exploitable, as in order to exploit this the attacker would first need to be able to control the contents of that particular cookie. (Which would almost certainly require the use of some other vulnerability.)

However, if there are other vulnerabilities (whether they be client or server-side) in the site this unusual feature could be used to make the impact of those vulnerabilities significantly worse.

For example, if any page on the site is ever loaded over HTTP, a MITM attacker would be able to create a semi-persistent XSS attack by setting the value of this cookie, possibly using the attack to steal data that would normally only be accessible from a more secure HTTPS page (such as cookies with the secure flag set).

Or if the site is vulnerable to a Cookie Tossing attack, that same attack (which would normally only be useful for session fixation and the like) would also open you up to a full-blown XSS attack against affected users.

All-in-all, while this practice may not be terrible I still wouldn't advise it, especially since there are much better ways of getting HTML content from the server onto a page that don't expose you to any new threats.

|improve this answer
2

I'm not defending the practice, but it's unlikely to be an XSS vector. In order for it to be, an attacker would have to be able to control the contents of the victim's cookie. In reflected XSS, this is usually done by putting malicious code in a URL parameter and having the victim click on it. There isn't a similar way to set the victim's cookies without already running code in the target context. Similarly, for this to be a vector for persisted XSS, the attacker would need to be able to set some state in the server that would end up in the victim's cookie. This is not impossible but it would be an unusual use of a cookie.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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