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

111–120 of 256 posts

Re: #1 CSRF Is A Vulnerability In All Browsers

#111

Post by f055 »

ceol wrote: post #97
epimenov wrote: post #16

Earlier quoted context omitted.

he discovered that you can log out from google via a GET request (surprise!)

Specifically, When your browser loads the page, it requests that "image", which logs you out. I don't see a way browsers could effectively enable CSRF protections. How is it supposed to know you don't want to request that page as an image? What about sites linking to images on other domains? CDNs would be blocked, because how is Chrome supposed to know you actually wanted to load the image from fbcdn.net or s3.amazon…

You can prevent the iframe CSRF with X-Frame-Options: SAMEORIGIN I suppose? - maybe browser could implement X-Image-Options: SAMEORIGIN as well - kind of a hotlinking prevention header.

Re: #1 CSRF Is A Vulnerability In All Browsers

#112

Post by redthrowaway »

inchcombec wrote: post #80
kami8845 wrote: post #72

Earlier quoted context omitted.

do some friendly hacking to annoy the admins (but only them), and watch them fix the issue in real-time

That is TERRIBLE advice. I don't know exactly what you mean by 'friendly hacking' but ANY exploitation of a website vulnerability without that site's permission would be a crime pretty much anywhere; even if it isn't malicious. It would be far from the first time that an administrator or owner didn't understand that the person was trying to help or just didn't really want to deal with it and it then just ended up bei…

Not much different from the recent Github hack, really.

Re: #1 CSRF Is A Vulnerability In All Browsers

#113

Post by ovi256 »

homakov wrote: post #8
elisee wrote: post #4

Just in case it might be a problem for anyone: The article uses the CSRF vulnerability to log you out of all Google services (and says so in a PS at the bottom). Don't open the article if you don't want to have to log in to Google again afterwards (might be a problem if you're using two-factor auth and you don't have your phone handy for instance).

hm yep. should I hide that thing? hm.. Sorry guys in advance.

Maybe make it a button, but just disconnecting is not harmful. Great work by the way, and oh so badly needed.

FWIW, worked on Chrome / Mac OS X Snow Leopard.

Re: #1 CSRF Is A Vulnerability In All Browsers

#114

Post by tomjen3 »

spindritf wrote: post #19
elisee wrote: post #4

Just in case it might be a problem for anyone: The article uses the CSRF vulnerability to log you out of all Google services (and says so in a PS at the bottom). Don't open the article if you don't want to have to log in to Google again afterwards (might be a problem if you're using two-factor auth and you don't have your phone handy for instance).

There's an info now at the top of the post > To stir up your interest - check any google service e.g. gmail, you are logged out. Great hook btw. Even more impressively, I have all js on his blog blocked through NoScript and it still worked.

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

Re: #1 CSRF Is A Vulnerability In All Browsers

#115

Post by [deleted] »

huhtenberg wrote: post #88

[ repost from below ] I just read on CSRF and its mitigation with Synchronized Tokens on [1] and there's one thing I don't seem to understand. What does prevent an attacker from open an original site's page in an iframe and then have a script fill in and submit the form on it? In other words, say I am logged in into my bank's site. I then open a malicious page that has an iframe pointing at http://bank/move-funds tha…

[deleted]

Re: #1 CSRF Is A Vulnerability In All Browsers

#117

Post by aprescott »

nbpoole wrote: post #105
aprescott wrote: post #99

If Google required a POST to log out (as it should be, since logging someone out is changing the session state and therefore not a "safe" GET-able request[1]), we could fall back to CORS as protection which removes the need for a CSRF token. Since the only way (I believe) to get a POST to fire cross-domain, without explicit user interaction through, say, a regular HTML form, is through JavaScript, the browser would r…

" Since the only way (I believe) to get a POST to fire cross-domain, without explicit user interaction through, say, a regular HTML form, is through JavaScript, the browser would refuse to make the request unless the CORS headers explicitly allowed it. " I'm not quite sure what you're trying to say here. But you can make cross-domain POST requests in two ways, both involving JavaScript: 1. Create an HTML form, use Ja…

Yes: "the only way [...] to get a POST to fire cross-domain [...] is through JavaScript".

The request would go against the same-origin policy, at which point CORS comes into play.

Edit: Ah, but creating a form in the DOM and submitting it via JavaScript... that one I hadn't thought of.

Re: #1 CSRF Is A Vulnerability In All Browsers

#118

Post by dwc »

homakov wrote: post #8
elisee wrote: post #4

Just in case it might be a problem for anyone: The article uses the CSRF vulnerability to log you out of all Google services (and says so in a PS at the bottom). Don't open the article if you don't want to have to log in to Google again afterwards (might be a problem if you're using two-factor auth and you don't have your phone handy for instance).

hm yep. should I hide that thing? hm.. Sorry guys in advance.

Leave it. I think it has exactly the effect you wanted.

Re: #1 CSRF Is A Vulnerability In All Browsers

#119

Post by nbpoole »

f055 wrote: post #111
ceol wrote: post #97

Earlier quoted context omitted.

Specifically, When your browser loads the page, it requests that "image", which logs you out. I don't see a way browsers could effectively enable CSRF protections. How is it supposed to know you don't want to request that page as an image? What about sites linking to images on other domains? CDNs would be blocked, because how is Chrome supposed to know you actually wanted to load the image from fbcdn.net or s3.amazon…

You can prevent the iframe CSRF with X-Frame-Options: SAMEORIGIN I suppose? - maybe browser could implement X-Image-Options: SAMEORIGIN as well - kind of a hotlinking prevention header.

That prevents the result from being displayed, it doesn't prevent the request from being made. The distinction is subtle but hugely important. In other words, the browser makes the request, gets the response, and doesn't render it. The server doesn't know that the browser didn't render it: it treats it like any other request.

Re: #1 CSRF Is A Vulnerability In All Browsers

#120

Post by [deleted] »

huhtenberg wrote: post #77
spamizbad wrote: post #10

I'm having a little trouble parsing this post. Is he saying he's discovered a variant of CSRF that cannot be stopped by using the Synchronizer Token Pattern? Or has he found something that a lot of site's protection patterns don't follow?

You seem to be familiar with the subject. I just read through CSRF and Token stuff on [1] and there's one thing I don't seem to understand. What would prevent an attacker from open an original site's page in an iframe and then have a script fill in and submit the form on it? In other words, say I am logged in into my bank's site. I then open a malicious page that has an iframe pointing at http://bank/operations/move-…

[deleted]
Post reply on HN