Hackers Think Cookies Are Tasty, Too(blog.tinfoilsecurity.com)
blog.tinfoilsecurity.com
Hackers Think Cookies Are Tasty, Too
http://blog.tinfoilsecurity.com/hackers-think-cookies-are-tasty-too
13 comments
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.
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
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.
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?
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.
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.
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.
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.
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.