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