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

141–150 of 256 posts

Re: #1 CSRF Is A Vulnerability In All Browsers

#141

Post by nbpoole »

ricardobeat wrote: post #139
Zirro wrote: post #60

Am I correct in interpreting that the proposed fix would the be the same as the functionality provided by RequestPolicy (which he mentions in the post)? I've used it for quite a while now, and although it works well for me as a power-user (who is concerned about security), I can't imagine the confusion and pain a user will feel despite the message suggested. Blocking resources loaded over separate domains breaks a lo…

No need to go that far. The X-Frame-Options: SAMEORIGIN header, supported by all major browsers, can prevent the majority of these attacks (unwanted GET requests in the background). https://developer.mozilla.org/en/The_X-FRAME-OPTIONS_respons... Other than that, it should be hammered into developer's heads that GET should not have side effects.

"The X-Frame-Options: SAMEORIGIN header, supported by all major browsers, can prevent the majority of these attacks"

No it can not. I've seen this assertion popping up a few times on HN this past week: it's conflating two similar but very different attacks in a dangerous way.

X-Frame-Options prevents a type of attack known as clickjacking. It is similar to a CSRF, but it involves creating an iframe to a page with a form and convincing the targeted user to submit it. It provides this protection at the browser level: if an HTTP response contains the X-Frame-Options header and the requesting page violates that directive, the response is not rendered.

It does not prevent a CSRF attack. It's impossible for it to do so: once the malicious request had made it to the server and the server has sent back a response, the attack is already complete. There's nothing the browser can do to prevent it at that point. If you use nothing but X-Frame-Options to try and prevent CSRF, you'll have a site completely vulnerable to CSRF.

Re: #1 CSRF Is A Vulnerability In All Browsers

#142

Post by Cushman »

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.

He provided instructions to my browser without my consent, the exact same way he would have if he had done it from his computer. How far are we willing to take the semantics here?

I guess a lot of people disagree with this? To clarify, I don't think this guy's guilty of a felony-- to my knowledge computer fraud requires at least some malicious intent or damage. But you seriously think if somebody used CSRF to drain your bank balance that wouldn't count as hacking because it was your browser? That's absurd.

Re: #1 CSRF Is A Vulnerability In All Browsers

#143

Post by jaylevitt »

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.

I don't think a "button" quite conveys the malicious feeling you want to inspire... but maybe a "Read more" link?

Re: #1 CSRF Is A Vulnerability In All Browsers

#144

Post by ricardobeat »

technoweenie wrote: post #130
rosser wrote: post #5

Earlier quoted context omitted.

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

I'm sorry, but why should he? If I find a major hole in SHA1 key handling, should I contact GitHub since you are users of it? Of course not.

Re: #1 CSRF Is A Vulnerability In All Browsers

#145

Post by phleet »

divtxt wrote: post #136
vectorpush wrote: post #70

it took me a long time to understand the point behind CSR (cross-site requests) and CRSF fully enough to find them EXTREMELY malicious. I think this is a very important line. The sense I get around most of my colleagues is that CSRF exploits are only something "bad programmers" get wrong. Of course, they're all rockstars who've never been exploited (yet/AFATK) so it's not like they need to spend a weekend or five pag…

CSRF is like a kafka-esque joke. Here's my take away from every CSRF article: A malicious site will load your site in an iframe, fill in your form and post it. Fixing it requires some a token in your form, but I can see you don't understand how an extra hidden field in your form will make a difference so you're clearly not going to handle it correctly. You're screwed. Go home. As far as I can tell, CSRF should have e…

The difficulty is how to deny this happening.

Pages making GET requests across domains is so common and necessary that several technology standards would have to come together to propose a real fix. Every image or script loaded from a CDN. Anyone hosting their own static assets domains. Anyone using a plugin from Google, Facebook, Twitter, Disqus uses this ability.

The tech companies can't even easily create a system to whitelist sites allowed to embed them, because that would severely limit third party's ability to use their services freely and would introduce a huge performance bottleneck.

I haven't seen any particularly compelling solution to solving this. Things only guarded behind a GET request can be loaded by script, link, embed, object, img and iframe tags, and all of those have legitimate reasons for loading resources cross domain without requesting permissions for each one from the user.

Re: #1 CSRF Is A Vulnerability In All Browsers

#146

Post by jey »

seanalltogether wrote: post #26

Is a GET request in an iframe now considered a CSRF vulnerability? As far as I know, he hasn't actually done any cross site scripting. If i submit this as a link on hacker news and get a bunch of people to click it, have I forged a cross domain request as well? https://mail.google.com/mail/u/0/?logout

The other replies to your post are focusing on the fact that you mistakenly used "cross site scripting" in your post, but you raise a valid point: is it really a problem to cause a GET request to that URL? It would be a lot more convincing if he used a POST to a URL that seemed to be doing the normal sanity checks, like if he caused Gmail to send a mail. Right now his example is unconvincing because it's possible that the Google guys just allow logouts via GET because it's relatively harmless to log someone out.

Re: #1 CSRF Is A Vulnerability In All Browsers

#147

Post by jaylevitt »

Zirro wrote: post #60

Am I correct in interpreting that the proposed fix would the be the same as the functionality provided by RequestPolicy (which he mentions in the post)? I've used it for quite a while now, and although it works well for me as a power-user (who is concerned about security), I can't imagine the confusion and pain a user will feel despite the message suggested. Blocking resources loaded over separate domains breaks a lo…

In fact, if you're using Amazon's CloudFront CDN, and you're using HTTPS, you have NO way to keep everything under the same TLD; CloudFront can only serve its own SSL cert, not yours.

Re: #1 CSRF Is A Vulnerability In All Browsers

#148

Post by nbpoole »

ricardobeat wrote: post #144
technoweenie wrote: post #130

Earlier quoted context omitted.

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

I'm sorry, but why should he? If I find a major hole in SHA1 key handling, should I contact GitHub since you are users of it? Of course not.

There's a difference between complaining about a class of vulnerability and exploiting a particular instance of a vulnerability that you seem to be failing to grasp.

If you find a major hole in a part of Git, you are by no means obligated to tell GitHub. You are, however, legally obligated not to compromise their site using that hole.

Or, a better example: you can talk about XSS mitigation strategies all you want. You can't go around looking for XSS vulnerabilities on random websites and then exploiting them.

Re: #1 CSRF Is A Vulnerability In All Browsers

#149

Post by divtxt »

phleet wrote: post #145
divtxt wrote: post #136

Earlier quoted context omitted.

CSRF is like a kafka-esque joke. Here's my take away from every CSRF article: A malicious site will load your site in an iframe, fill in your form and post it. Fixing it requires some a token in your form, but I can see you don't understand how an extra hidden field in your form will make a difference so you're clearly not going to handle it correctly. You're screwed. Go home. As far as I can tell, CSRF should have e…

The difficulty is how to deny this happening. Pages making GET requests across domains is so common and necessary that several technology standards would have to come together to propose a real fix. Every image or script loaded from a CDN. Anyone hosting their own static assets domains. Anyone using a plugin from Google, Facebook, Twitter, Disqus uses this ability. The tech companies can't even easily create a system…

I have no problem with cross-site GET requests because I know GETs should behave as 'read-only' anyway for lots of reasons.

What I don't get is how arbitrary cross-site POSTs with malicious values are allowed. As far as I can tell, anyone can post this form:

http://bank.com/send_money> name="to_account" value="SCAMMER-1234">

Worse, one article will tell you to only allow Referrer == "bank.com", and then another will tell you that even that is no longer enough?!!!

Why can't we change the browser or the web server layer to prevent this by default?!

Re: #1 CSRF Is A Vulnerability In All Browsers

#150

Post by eurleif »

divtxt wrote: post #149
phleet wrote: post #145

Earlier quoted context omitted.

The difficulty is how to deny this happening. Pages making GET requests across domains is so common and necessary that several technology standards would have to come together to propose a real fix. Every image or script loaded from a CDN. Anyone hosting their own static assets domains. Anyone using a plugin from Google, Facebook, Twitter, Disqus uses this ability. The tech companies can't even easily create a system…

I have no problem with cross-site GET requests because I know GETs should behave as 'read-only' anyway for lots of reasons. What I don't get is how arbitrary cross-site POSTs with malicious values are allowed. As far as I can tell, anyone can post this form: http://bank.com/send_money> name="to_account" value="SCAMMER-1234"> Worse, one article will tell you to only allow Referrer == "bank.com", and then another will…

Browsers don't prevent it because there are legitimate uses for cross-domain posts. Good frameworks do prevent it with CSRF tokens.
Post reply on HN