Hackers Think Cookies Are Tasty, Too • Hacker News Board

Re: Hackers Think Cookies Are Tasty, Too

#11

Post by brodney » Tue, Apr 02, 2013, 8:34 PM UTC

cheald wrote: post #9

ultimoo wrote: post #7

Earlier quoted context omitted.

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.

Re: Hackers Think Cookies Are Tasty, Too

#12

Post by jtokoph » Tue, Apr 02, 2013, 9:06 PM UTC

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.

Re: Hackers Think Cookies Are Tasty, Too

#13

Post by ainsleyb » Tue, Apr 02, 2013, 10:18 PM UTC

cheald wrote: post #2

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 attacke…

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?

Re: Hackers Think Cookies Are Tasty, Too

#14

Post by cheald » Tue, Apr 02, 2013, 10:49 PM UTC

ainsleyb wrote: post #13

cheald wrote: post #2

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 attacke…

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…

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.