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.
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.
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?
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.
Isn't it a widely adopted practice to encrypt the content of the cookie before setting it? Of course it could still be tampered with, but not as trivially.
Frameworks like Rails or Django offer options to encrypt or sign session cookies, but any other cookies are often left up to the developer to take care of. The HttpOnly and Secure flags are important to remember as well because otherwise a man-in-the-middle or rogue JS can modify them.
Isn't XSS only a client side danger? For URLs, this is relevant since you can post a malicious link and people can click on it. It's much harder to get someone else's browser to accept a cookie you made for a specific website.
Of course, cookies are still client-side data and should not be trusted. But XSS is not a problem here. Correct me if I'm wrong.
Not if your server environment is running Node.js! If you start reading cookies and potentially evaluating their content, this could have a major impact on a Node process. That said, I doubt that you could hack a running Node process with this without the system using eval() on the cookie contents. I've been wrong before....
I think cookie values are more of a risk for SQL injection or RCE than XSS. If the code that builds the session lookup query or cookie parsing code isn't safe, you're gonna have a problem.
[+] [-] cheald|13 years ago|reply
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|13 years ago|reply
[+] [-] ainsleyb|13 years ago|reply
[+] [-] benburleson|13 years ago|reply
[+] [-] Mandatum|13 years ago|reply
[deleted]
[+] [-] ultimoo|13 years ago|reply
[+] [-] bensedat|13 years ago|reply
[+] [-] Oduig|13 years ago|reply
Of course, cookies are still client-side data and should not be trusted. But XSS is not a problem here. Correct me if I'm wrong.
[+] [-] trebor|13 years ago|reply
[+] [-] jtokoph|13 years ago|reply