#1 CSRF Is A Vulnerability In All Browsers • Hacker News Board

Re: #1 CSRF Is A Vulnerability In All Browsers

#201

Post by arohner » Sat, Mar 31, 2012, 2:51 AM UTC

sounds wrote: post #197

tptacek wrote: post #158

Earlier quoted context omitted.

From experience: had he simply told Github about it, they would have fixed it quickly, and there would have been no window of public exposure. That's the point being made here.

Fair enough, that's basically what was said in the bug he filed with Ruby on Rails. I won't try to impute motives but I think he did it this way because he felt like he was being treated poorly.

There are two different issues here. 1) A bad security vulnerability at GitHub. 2) Poor design in Rails that makes it easy to produce security vulnerabilities.

Igor found 2, and got ignored by the Rails team. His frustration led him to publicly demonstrating 1, which caused a whole lot of people a whole lot of trouble.

The people that are irritated at him are irritated at him because of 1, not 2.

Re: #1 CSRF Is A Vulnerability In All Browsers

#202

Post by Xk » Sat, Mar 31, 2012, 2:54 AM UTC

homakov wrote: post #200

Xk wrote: post #199

Earlier quoted context omitted.

CSRF is NOT a browser vulnerability. The browser is doing exactly what it's supposed to do: load content. The browser can not (and should not) attempt to identify the "evil" HTTP requests from the "good" ones. The browser's job is to make requests. Now, you could argue the browser's job should be to implement security features as well. It does, after all, implement the same-origin policy. But, if you think about it,…

>I would guess well over half of all websites do one of the following: (1) load an external JS file, (2) load an external image, (3) load an external CSS file, (4) use an iframe which points to a different origin, (5) use a JS redirect, (6) use a meta redirect, or (7) open a new window. The proposed "solution" to CSRF breaks ALL of these uses. You definitely kidding me. Please point out where in my post I said to den…

Either you do it for everything, or you do it for only POST and you end up missing half of the vulnerabilities. Correct me if I'm wrong, but your CSRF attack used a GET request, did it not? [1]

Web applications make state-changing operations on GET requests. You might not like it, but they do.

[1] https://mail.google.com/mail/u/0/?logout style="display: none;" />

Re: #1 CSRF Is A Vulnerability In All Browsers

#203

Post by gcb » Sat, Mar 31, 2012, 3:10 AM UTC

Web is already too useless because people can't think about security in a decent way.

Still baffles me that i can't allow a script at one domain to automate something in another domain for me.

Re: #1 CSRF Is A Vulnerability In All Browsers

#204

Post by tptacek » Sat, Mar 31, 2012, 3:12 AM UTC

homakov wrote: post #200

Xk wrote: post #199

Earlier quoted context omitted.

CSRF is NOT a browser vulnerability. The browser is doing exactly what it's supposed to do: load content. The browser can not (and should not) attempt to identify the "evil" HTTP requests from the "good" ones. The browser's job is to make requests. Now, you could argue the browser's job should be to implement security features as well. It does, after all, implement the same-origin policy. But, if you think about it,…

>I would guess well over half of all websites do one of the following: (1) load an external JS file, (2) load an external image, (3) load an external CSS file, (4) use an iframe which points to a different origin, (5) use a JS redirect, (6) use a meta redirect, or (7) open a new window. The proposed "solution" to CSRF breaks ALL of these uses. You definitely kidding me. Please point out where in my post I said to den…

Perfectly solid web apps routinely ask browsers to POST to other domains.

Re: #1 CSRF Is A Vulnerability In All Browsers

#205

Post by tptacek » Sat, Mar 31, 2012, 3:13 AM UTC

homakov wrote: post #195

tptacek wrote: post #164

CSRF isn't a browser vulnerability. It's a serverside application vulnerability. To say otherwise is to say there there is some trivial policy, just an HTTP header away, that would allow IE, Firefox, and Webkit to coherently express cross-domain request policy for every conceivable application --- or to say that no FORM element on any website should be able to POST off-site (which, for the non-developers on HN, is an…

I see some points but >CSRF isn't a browser vulnerability. It's a serverside application vulnerability. you didn't prove this one. CSRF is a browser vulnerability. ANd I don't care about another stuff you said further - you probably right that most popular frameworks have the protection out of box - I know it, no surprise here:). But I did pretty wide audit - only rails' protection looks really elegant. Hm.. probably…

"I did pretty wide audit - only rails' protection looks really elegant."

This is handwaving. You were wrong about this. I assume you want to know that, so I'm saying it bluntly.

"I just want to make browsers think about the issue as millions of developers have to. Because it is their issue, they are in charge."

No, the web browsers are not in charge. The secrets and sensitive actions are occurring on the servers, not in the browsers. The servers are what matter. The browser isn't protecting your email. The server is. The browser isn't protecting your bank account. The server is. The browser isn't controlling who is or isn't your Facebook friend. The server is.

Re: #1 CSRF Is A Vulnerability In All Browsers

#206

Post by homakov » Sat, Mar 31, 2012, 3:15 AM UTC

Xk wrote: post #202

homakov wrote: post #200

Earlier quoted context omitted.

>I would guess well over half of all websites do one of the following: (1) load an external JS file, (2) load an external image, (3) load an external CSS file, (4) use an iframe which points to a different origin, (5) use a JS redirect, (6) use a meta redirect, or (7) open a new window. The proposed "solution" to CSRF breaks ALL of these uses. You definitely kidding me. Please point out where in my post I said to den…

Either you do it for everything, or you do it for only POST and you end up missing half of the vulnerabilities. Correct me if I'm wrong, but your CSRF attack used a GET request, did it not? [1] Web applications make state-changing operations on GET requests. You might not like it, but they do. [1] https://mail.google.com/mail/u/0/?logout style="display: none;" />

>Web applications make state-changing operations on GET requests. You might not like it, but they do.

but when developer made a mistake with GET it is 100% his problem - it's out of question. he should be punished :D

Re: #1 CSRF Is A Vulnerability In All Browsers

#207

Post by tptacek » Sat, Mar 31, 2012, 3:23 AM UTC

homakov wrote: post #206

Xk wrote: post #202

Earlier quoted context omitted.

Either you do it for everything, or you do it for only POST and you end up missing half of the vulnerabilities. Correct me if I'm wrong, but your CSRF attack used a GET request, did it not? [1] Web applications make state-changing operations on GET requests. You might not like it, but they do. [1] https://mail.google.com/mail/u/0/?logout style="display: none;" />

>Web applications make state-changing operations on GET requests. You might not like it, but they do. but when developer made a mistake with GET it is 100% his problem - it's out of question. he should be punished :D

Nonsensical. CSRF isn't God's punishment for REST-lessness.

Re: #1 CSRF Is A Vulnerability In All Browsers

#208

Post by ricardobeat » Sat, Mar 31, 2012, 3:42 AM UTC

tptacek wrote: post #155

ricardobeat wrote: post #144

Earlier quoted context omitted.

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.

"SHA1 key handling"? Anyways, you misread him. All he's saying is that the delay Egor Homakov experienced was with the Rails dev team, not Github. Github's response to Homakov's finding was very fast.

I just pulled something out of my ass to fill in the gap. Was probably thinking of RSA.

Re: #1 CSRF Is A Vulnerability In All Browsers

#209

Post by [deleted] » Sat, Mar 31, 2012, 3:42 AM UTC

tptacek wrote: post #155

ricardobeat wrote: post #144

Earlier quoted context omitted.

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.

"SHA1 key handling"? Anyways, you misread him. All he's saying is that the delay Egor Homakov experienced was with the Rails dev team, not Github. Github's response to Homakov's finding was very fast.

[deleted]

Re: #1 CSRF Is A Vulnerability In All Browsers

#210

Post by ricardobeat » Sat, Mar 31, 2012, 3:50 AM UTC

nbpoole wrote: post #148

ricardobeat wrote: post #144

Earlier quoted context omitted.

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. Yo…

technoweenie pointed out that he wasn't being ignored by GitHub, I was saying that's irrelevant. GH is just one of thousands of Rails apps that were/are vulnerable.

> You can't go around looking for XSS vulnerabilities on random websites and then exploiting them.

exploit: to use a situation so that you get benefit from it, even if it is wrong or unfair to do this; to utilize, especially for profit; etc