[cheald]

But...in order to properly execute an XSS attack, you have to get your code onto someone else's computer. You can edit your own cookies all day long and accomplish nothing of value. What piece am I missing here?

That said, as far as the server trusting cookie values to do database lookups or whatever, sure, there's a hole there. Most folks will use something like HMAC-signed cookies in those cases, so that an attacker would have to be in possession of a secret key in order to successfully have altered cookie data accepted by the user. But in any case, the data should be treated like any other user-supplied data - untrusted and to be sanitized.

[ultimoo]

Yes, I think what the original article is saying is that the cookie could have been altered by a rogue browser extension/virus on a user's computer, which could be then potentially used to import a script from a different origin into the user's page.

[cheald]

If I have my malware on your computer, I'm just going to use it to steal your cookie (any other sensitive information) directly rather than perform some convoluted roundabout XSS. :P

[brodney]

If you wanted to access a company's server, this actually sounds like a reasonable attack vector. Get malware on someone's computer and use it to perform SQL injections. It depends on what information the attacker is after.

[ainsleyb]

There are a number of ways: malware, browser extensions, man in the middling, etc. SQLi would have been a better example than XSS, but there are definitely ways in which XSS can still be harmful if thrown in a cookie. If you wanted a persistent XSS for example, you could use a reflected XSS to create a longer lasting XSS attack in someone's login cookie, causing that to be executed every time they hit the page rather than just the one time they click on a malicious link you sent them. Does this make more sense?

[cheald]

Malware, browser extensions, and MitM could all just inject the XSS payload into the page directly without having to go to the fuss. Why go through a cookie?

Reflecting the attack through the cookie makes sense if you can find an XSS-vulnerable page that you could use to deliver a payload that can be used to write a cookie to leapfrog the XSS attack to non-vulnerable pages, but that requires a pre-existing XSS attack and a vulnerable usage of cookie data; the simple ability to modify cookies isn't inherently a vulnerability.

If you can actually force malicious content into someone else's cookie, then absolutely, all bets are off. But the vector as described in the article seems to be entirely benign - just because someone can alter their cookies doesn't mean they can XSS other people.

[benburleson]

Yeah, it's not a great use-case because it requires other flaws where the cookie value is used. This is just a specific example of the general problem that any variable in the browser can be changed by the user before being sent to the server.