Hackers Think Cookies Are Tasty, Too

But...in order to properly execute an XSS attack, you have to get your code onto <i>someone else's</i> computer. You can edit your own cookies all day long and accomplish nothing of value. What piece am I missing here?<p>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.

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.

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

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.