Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

#1 CSRF Is A Vulnerability In All Browsers

homakov.blogspot.com

Post reply on HN
Print view View original

221–230 of 256 posts

Re: #1 CSRF Is A Vulnerability In All Browsers

#221

Post by akaBruce »

nbpoole wrote: post #219
ynniv wrote: post #216

Earlier quoted context omitted.

Firefox already blocks off-domain POST requests, unless the 3rd party domain responds to an OPTIONS preflight request. So, I'm talking only about forms sending and GET is ok sure. Google's logout CSRF works because the logout link is a GET request. So, no, there is no quick fix.

No it does not. --- https://developer.mozilla.org/en/http_access_control#Simple_... A simple cross-site request is one that: - Only uses GET or POST. If POST is used to send data to the server, the Content-Type of the data sent to the server with the HTTP POST request is one of application/x-www-form-urlencoded, multipart/form-data, or text/plain. - Does not set custom headers with the HTTP Request (such as X-Modifie…

Am I missing something here?

Let's say you're logged into Gmail and Gmail had no CSRF protection anywhere.

You're logged in while visiting my site. In my site, I include a little bit of JavaScript to make a POST request to Gmail telling it to forward copies of all your incoming email to my email address.

This will not work even without CSRF protection. It would only work if Google sends back the header Access-Control-Allow-Origin: mysite or Access-Control-Allow-Origin: * as noted in the section you linked to.

Of course, I could also try to trick you into filling out a form whose method actually is pointed at Gmail's and include all the hidden input tags to set you up for forwarding emails to me, but you would know something fishy is going on because it would redirect you to Gmail.

Re: #1 CSRF Is A Vulnerability In All Browsers

#222

Post by nbpoole »

akaBruce wrote: post #221
nbpoole wrote: post #219

Earlier quoted context omitted.

No it does not. --- https://developer.mozilla.org/en/http_access_control#Simple_... A simple cross-site request is one that: - Only uses GET or POST. If POST is used to send data to the server, the Content-Type of the data sent to the server with the HTTP POST request is one of application/x-www-form-urlencoded, multipart/form-data, or text/plain. - Does not set custom headers with the HTTP Request (such as X-Modifie…

Am I missing something here? Let's say you're logged into Gmail and Gmail had no CSRF protection anywhere. You're logged in while visiting my site. In my site, I include a little bit of JavaScript to make a POST request to Gmail telling it to forward copies of all your incoming email to my email address. This will not work even without CSRF protection. It would only work if Google sends back the header Access-Control…

"This will not work even without CSRF protection."

It actually will work.

What you're describing is what's known as a "simple" request in XMLHttpRequest terms. That means there is no pre-flight necessary. Your browser will simply make the POST as requested and receive the response. It won't make the response available to you since the Access-Control-Allow-Origin header isn't set, but you're a malicious attacker in this example and you don't care what the response is: you just care that you were able to make the request. ;-)

You could even do this by creating an HTML form that POSTs to the right URL and using JavaScript to submit it automatically when the page loads. Same exact thing: no CORS checks.

If a pre-flight were necessary you would be right. The browser would send an OPTIONS request to the server, the server would respond without the appropriate headers, and the POST request would never be sent.

Let me know if any of this needs further explanation!

Re: #1 CSRF Is A Vulnerability In All Browsers

#223

Post by akaBruce »

nbpoole wrote: post #222
akaBruce wrote: post #221

Earlier quoted context omitted.

Am I missing something here? Let's say you're logged into Gmail and Gmail had no CSRF protection anywhere. You're logged in while visiting my site. In my site, I include a little bit of JavaScript to make a POST request to Gmail telling it to forward copies of all your incoming email to my email address. This will not work even without CSRF protection. It would only work if Google sends back the header Access-Control…

" This will not work even without CSRF protection. " It actually will work. What you're describing is what's known as a "simple" request in XMLHttpRequest terms. That means there is no pre-flight necessary. Your browser will simply make the POST as requested and receive the response. It won't make the response available to you since the Access-Control-Allow-Origin header isn't set, but you're a malicious attacker in…

Oh, I see now. I had assumed that because I couldn't get the response, that the request itself was blocked.

Thanks!

Re: #1 CSRF Is A Vulnerability In All Browsers

#224

Post by jrockway »

nitrogen wrote: post #122
tomjen3 wrote: post #114

Earlier quoted context omitted.

Well no, it is illegally accessing a computer system, which i do believe is a felony.

But he didn't access Google's systems, your browser did. You requested the page, and your browser dutifully loaded the cross-site request image.

The law is not a computer program; intent is more important than the mechanism.

Imagine a real-world example. Alice wants to murder you. You have a kid. Alice calls you, exactly imitating the voice of your kid, telling you she's trapped under a girder at the abandoned bridge across town. You frantically race across town to free your trapped kid. You get to the bridge and notice it's on the verge of collapsing, and that there's a "no trespassing" sign posted. You ignore that and try to save your kid. You trip over something and that upsets the unstable structure of the bridge. It collapses, crushing you while you fall 3000 feet to your ultimate demise.

Guess what, you were just murdered.

Even though Alice did not physically drive a knife into your heart, she still killed you. She intended to kill you (that's the first part), and then set into a motion a chain of events that resulted in you dying. That's murder.

Going back to our computer example... even though the author of this blog post didn't break into your house and log you out of Google, the result is the same. He intended for you to be logged out of Google without your permission or Google's permission, and you were logged out of Google. Therefore, your computer account was maliciously accessed.

The reality of the situation is that he's in Russia and I doubt Russia gives a damn about this.

Re: #1 CSRF Is A Vulnerability In All Browsers

#225

Post by peteretep »

I am hesitant to post this, because from experience, smart people frequently misread or misunderstand it, but:

The easiest first-step solution is just to check the HTTP Referer field, and check it matches your domain.

Yes, this is easily faked by someone crafting their own HTTP requests. This is /not/ easily faked by someone causing your browser to make requests, though. And it provides very good coverage against the attack here.

Re: #1 CSRF Is A Vulnerability In All Browsers

#226

Post by mhansen »

simonw wrote: post #128
brian_peiris wrote: post #58

Here's Google's reply to this particular "vulnerability": http://www.google.com/about/company/rewardprogram.html#logou...

I don't understand why Google say that this is an issue that can't be solved - why can't they use a CSRF token on their logout feature, either by switching to using a POST form or by appending a CSRF token to the query string?

That won't work without javascript, and then you need another URL to fallback to that'll respond to GET requests for non-javascript browsers. And then you could just XSRF the non-javascript URL.

[Disclaimer: I work at Google, but not on any area related to this]

Re: #1 CSRF Is A Vulnerability In All Browsers

#227

Post by nbpoole »

peteretep wrote: post #225

I am hesitant to post this, because from experience, smart people frequently misread or misunderstand it, but: The easiest first-step solution is just to check the HTTP Referer field, and check it matches your domain. Yes, this is easily faked by someone crafting their own HTTP requests. This is /not/ easily faked by someone causing your browser to make requests, though. And it provides very good coverage against the…

Standard caveat with checking the Referer header: there is software out there which strips out the header in the name of privacy. If you use the Referer as a source of validation, you have to be prepared to deal with users of Norton Internet Security and other such products who will be unable to use your site. And you can't "fail open" by accepting any request without a referer, since there are plenty of techniques an attacker can use to remove the referer as well.

Re: #1 CSRF Is A Vulnerability In All Browsers

#228

Post by simonw »

mhansen wrote: post #226
simonw wrote: post #128

Earlier quoted context omitted.

I don't understand why Google say that this is an issue that can't be solved - why can't they use a CSRF token on their logout feature, either by switching to using a POST form or by appending a CSRF token to the query string?

That won't work without javascript, and then you need another URL to fallback to that'll respond to GET requests for non-javascript browsers. And then you could just XSRF the non-javascript URL. [Disclaimer: I work at Google, but not on any area related to this]

I don't understand why this would need JavaScript - regular CSRF protection for POST requests works fine without JavaScript - why can't that be applied to the logout button?

Re: #1 CSRF Is A Vulnerability In All Browsers

#229

Post by simonw »

wglb wrote: post #183
simonw wrote: post #128

Earlier quoted context omitted.

I don't understand why Google say that this is an issue that can't be solved - why can't they use a CSRF token on their logout feature, either by switching to using a POST form or by appending a CSRF token to the query string?

If you think of the damage that can be done by a logout CSRF, it is not going to harm very much. Really a low-level issue.

I get that - but the Google security FAQ suggests that fixing the issue is essentially impossible, whereas I'm pretty sure fixing it is the same as fixing any other CSRF hole.

Re: #1 CSRF Is A Vulnerability In All Browsers

#230

Post by nikcub »

peteretep wrote: post #225

I am hesitant to post this, because from experience, smart people frequently misread or misunderstand it, but: The easiest first-step solution is just to check the HTTP Referer field, and check it matches your domain. Yes, this is easily faked by someone crafting their own HTTP requests. This is /not/ easily faked by someone causing your browser to make requests, though. And it provides very good coverage against the…

If you do that, you then have to make sure your app doesn't have any redirector anywhere or anything that writes Location. Almost all apps do. This is because you can get the site to insert the right referrer.

for eg. if the URL of the attack request is (both of these are close to real life examples that work(ed))

http://www.site.com/mail/filter?create=*%2Cattacker%40hush.c...

usually the site will have a redirector on the login action, which takes the user back to the page that they were on after login, so you just use the attack URL as the redir URL

http://www.site.com/login?return_to=%2Fmail%2Ffilter%3Fcreat...

amazing how many login scripts still do the redirect even if the user is already logged in, or still do the redirect even if there is no real login

even if you do a javascript in-place login, there is usually a mobile version that has this pattern. I rarely meet a site that doesn't have a way to bounce between URLs and fake the referrer.

I guess the real conclusion is that these types of attacks are complicated and better understood fully than implying a single short solution - because the next response is always "but, if you do that, then" and so forth, like a matryoshka doll

Post reply on HN