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

121–130 of 256 posts

Re: #1 CSRF Is A Vulnerability In All Browsers

#121

Post by aprescott »

driverdan wrote: post #109
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…

CORS isn't available in all browsers. You still need additional protection for browsers that don't support it. Plus it has nothing to do with using JS to submit a form.

It's certainly true that not every browser supports CORS. But thinking about it, is logging out via a cross-domain request even that necessary in the vast majority of cases? Same-origin violation would block the POST.

Plus it has nothing to do with using JS to submit a form.

I wasn't saying you submit a form with JavaScript, but rather that the non-JavaScript way you make a POST request is through a user-submitted form, and is therefore intended by the user as opposed to some invisible, unseen operation.

Re: #1 CSRF Is A Vulnerability In All Browsers

#122

Post by nitrogen »

tomjen3 wrote: post #114
spindritf wrote: post #19

Earlier quoted context omitted.

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.

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.

Re: #1 CSRF Is A Vulnerability In All Browsers

#123

Post by jasonkeene »

davepeck wrote: post #106
jasonkeene wrote: post #92

Earlier quoted context omitted.

If I'm blocking cookies/referer by default then the onus is upon me to enable them for sites that require them for stuff like this. I wouldn't worry about users who have this issue. Maybe customize django's CSRF failure page to say they need to enable both to use your service and call it a day.

I agree in principle. And I have built a custom CSRF page to help my potential customers out. In practice, lots of my potential users don't even understand that their AdBlock/whatever extensions are mucking about with Cookies in ways that break things. It's a tough sell to tell someone who is thinking about trying your service: "sorry, I don't work with your browser the way it is" when so much of the rest of the worl…

Humm.. I'm thinking you could write a middleware that checks for Referer over https and if not set, go ahead and set it to https://yourdomain.com That would allow you to continue to use CSRF middleware for the nonce check (just make sure yours is before theirs).

Re: #1 CSRF Is A Vulnerability In All Browsers

#124

Post by nbpoole »

aprescott wrote: post #117
nbpoole wrote: post #105

Earlier quoted context omitted.

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

To fire automatically, yes: getting people to click on a button of their own free will is easy though.

Re: #1 CSRF Is A Vulnerability In All Browsers

#125

Post by nbpoole »

jasonkeene wrote: post #123
davepeck wrote: post #106

Earlier quoted context omitted.

I agree in principle. And I have built a custom CSRF page to help my potential customers out. In practice, lots of my potential users don't even understand that their AdBlock/whatever extensions are mucking about with Cookies in ways that break things. It's a tough sell to tell someone who is thinking about trying your service: "sorry, I don't work with your browser the way it is" when so much of the rest of the worl…

Humm.. I'm thinking you could write a middleware that checks for Referer over https and if not set, go ahead and set it to https://yourdomain.com That would allow you to continue to use CSRF middleware for the nonce check (just make sure yours is before theirs).

Except an attacker can strip a referer header: if you fail open like that, you leave yourself open to attack.

See http://blog.kotowicz.net/2011/10/stripping-referrer-for-fun-... for examples

Re: #1 CSRF Is A Vulnerability In All Browsers

#126

Post by mhurron »

arohner wrote: post #83
sounds wrote: post #35

Earlier quoted context omitted.

Let's be fair to homakov: He used the exploit publicly and loudly (full disclosure to almost all affected parties) by doing a relatively harmless change to _rails_ _master_ on github. If his actions should be called an attack, then it was highly targeted - at the people who could fix it - to get their attention.

His relatively harmless change demonstrated a Major Security Vulnerability in the site that hosts thousands of companies secure code.

What kind of serious company puts important or 'secure' code on github?

Re: #1 CSRF Is A Vulnerability In All Browsers

#127

Post by f055 »

nbpoole wrote: post #119
f055 wrote: post #111

Earlier quoted context omitted.

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.

Ah you are correct, forgot about that. Thanks for this point.

Re: #1 CSRF Is A Vulnerability In All Browsers

#128

Post by simonw »

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?

Re: #1 CSRF Is A Vulnerability In All Browsers

#129

Post by simonw »

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?

Re: #1 CSRF Is A Vulnerability In All Browsers

#130

Post by technoweenie »

rosser wrote: post #5
akavlie wrote: post #2

For those who didn't see the recent kerfuffle: This guy recently found and demonstrated a major Rails exploit on github. He seems to know a thing or two about security exploits.

Clarification: he didn't recently find the exploit. He's been making noises about it for a very long time and being ignored, so he took the (dubious, to some) step of using the exploit publicly and loudly, to draw attention to the problem.

Another clarification: He wasn't making noises for a long time with _GitHub_ and being ignored. His support responses were replied to nearly immediately (except where the timezone differences came into play). We take security reports very seriously.

We'd have preferred a more responsible disclosure, and I hope he (and others) are more careful about this in the future. Most reporters we get act very responsible, and we are always gracious (and even contract work from them in some cases) In his case, we saw activity that he didn't report to us, and suspended his account while we did a deeper investigation.

The Rails community and we still think that his proposed solution is not a good idea, but it did provoke exploration in some other ideas.

https://github.com/rails/rails/issues/5228

http://techno-weenie.net/2012/3/19/ending-the-mass-assignmen...

http://weblog.rubyonrails.org/2012/3/21/strong-parameters/

Post reply on HN