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

Re: #1 CSRF Is A Vulnerability In All Browsers

#181

Post by javajosh » Sat, Mar 31, 2012, 1:00 AM UTC

tptacek wrote: post #172

javajosh wrote: post #170

Earlier quoted context omitted.

It's clear that developers need a simple way to specify that a piece of API should not be accesible from third-party sites. I propose a new set of HTTP verbs, "SECPOST", "SECGET", etc that comes with the implication that it is never intended to be called by third-party sites or even navigated to from third-party sites. It is a resource that can only be called from the same origin. Application developers (and framewor…

Two things. First, every mainstream web framework already comes with a simple-to-use way to block forged requests. Even if we adopted new HTTP verbs to give them a common name in the protocol, by the time developers are making decisions they're not working with the ALL-CAPS-NAMES-OF-HTTP-VERBS anyways. Second, there isn't anything inherently "cross-site" about CSRF, so denying off-site POSTs isn't a complete solution…

Personally, I would be happy to eliminate any possibility of inter-site forgeries. It's unlikely that my bank will be putting user-generated content in front of me any time soon (and if they do I presume that they'll sanitize it well enough to not be a problem).

It troubles me deeply to have CSRF declared a purely server-side application problem. The browser is quite literally my agent in all of my interaction with the web. It is an extension of me, and when it does things that pretend that they are me, that feels very wrong. That is why I propose new HTTP verbs: my browser should know (and verify) that when it sends out a SEC* request, that my eyeballs are on that data and my finger physically clicked that button, and it can do this if those requests are, essentially, tagged as particularly sensitive.

To place the onus soley on the server-side is for me to abrogate my responsibility to fully control my browser-as-agent. Frankly, even if the server successfully rejects forged attacks, it is not acceptable that my browser, acting as my trusted agent, attempted that attack in the first place.

Re: #1 CSRF Is A Vulnerability In All Browsers

#182

Post by [deleted] » Sat, Mar 31, 2012, 1:04 AM UTC

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?

[deleted]

Re: #1 CSRF Is A Vulnerability In All Browsers

#183

Post by wglb » Sat, Mar 31, 2012, 1:05 AM UTC

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?

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.

Re: #1 CSRF Is A Vulnerability In All Browsers

#184

Post by [deleted] » Sat, Mar 31, 2012, 1:05 AM UTC

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?

[deleted]

Re: #1 CSRF Is A Vulnerability In All Browsers

#185

Post by Cushman » Sat, Mar 31, 2012, 1:07 AM UTC

andypants wrote: post #180

Cushman wrote: post #142

Earlier quoted context omitted.

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

He provided instructions to your browser to include an image. If that is considered 'without your consent', then so is every site that is embedding external plugins, images, and videos. How are you supposed to 'give your consent'? Must you be given a list of all the content on the website before the browser will be allowed to display it? When you requested the page, you gave your consent to load whatever was on that…

I don't understand this argument. If I buy a box of cereal, and open it to find it contains a live rattlesnake, have I consented to be bitten by the snake because I knowingly purchased the box?

Of course I don't know everything that's in cereal -- I trust the manufacturers to provide me with the product I paid for, whatever that involves. But I know for sure that that doesn't involve snakes, and had I had reason to believe that there might be a snake in there, I wouldn't have bought it. And the rational response to this is definitely not "If you didn't want snakes, you should have x-rayed the cereal before you bought it."

Arguing that my ignorance of something which I wouldn't have wanted had I been aware of it constitutes consent is severely shaky.

(Again, I'm not saying that logging me out of Google is like getting bit by a snake, and I do think it was a decently harmless demonstration of the issue with CSRF for anyone who was unaware. I'm just speaking hypothetically here.)

Re: #1 CSRF Is A Vulnerability In All Browsers

#186

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

javajosh wrote: post #181

tptacek wrote: post #172

Earlier quoted context omitted.

Two things. First, every mainstream web framework already comes with a simple-to-use way to block forged requests. Even if we adopted new HTTP verbs to give them a common name in the protocol, by the time developers are making decisions they're not working with the ALL-CAPS-NAMES-OF-HTTP-VERBS anyways. Second, there isn't anything inherently "cross-site" about CSRF, so denying off-site POSTs isn't a complete solution…

Personally, I would be happy to eliminate any possibility of inter-site forgeries. It's unlikely that my bank will be putting user-generated content in front of me any time soon (and if they do I presume that they'll sanitize it well enough to not be a problem). It troubles me deeply to have CSRF declared a purely server-side application problem. The browser is quite literally my agent in all of my interaction with t…

There are 3 major browser codebases. There are hundreds of thousands of web applications, each with different security needs. I think it's lunacy to suggest that the browsers should take on this problem.

At any rate: there isn't going to be SECGET and SECPOST, so the academic argument over whether end-to-end is better than Apple, Mozilla, Google and Microsoft deciding amongst themselves how security is going to work for every web application is moot.

Re: #1 CSRF Is A Vulnerability In All Browsers

#187

Post by [deleted] » Sat, Mar 31, 2012, 1:13 AM UTC

javajosh wrote: post #181

tptacek wrote: post #172

Earlier quoted context omitted.

Two things. First, every mainstream web framework already comes with a simple-to-use way to block forged requests. Even if we adopted new HTTP verbs to give them a common name in the protocol, by the time developers are making decisions they're not working with the ALL-CAPS-NAMES-OF-HTTP-VERBS anyways. Second, there isn't anything inherently "cross-site" about CSRF, so denying off-site POSTs isn't a complete solution…

Personally, I would be happy to eliminate any possibility of inter-site forgeries. It's unlikely that my bank will be putting user-generated content in front of me any time soon (and if they do I presume that they'll sanitize it well enough to not be a problem). It troubles me deeply to have CSRF declared a purely server-side application problem. The browser is quite literally my agent in all of my interaction with t…

[deleted]

Re: #1 CSRF Is A Vulnerability In All Browsers

#188

Post by sdevlin » Sat, Mar 31, 2012, 1:16 AM UTC

eurleif wrote: post #176

sdevlin wrote: post #175

Earlier quoted context omitted.

The referer header can easily be forged. The whole point of a CSRF attack is to turn a user's credentials against him.

How do you forge the referer header as a third-party site?

Ha, I'm wrong. I thought you could set the referer with setRequestHeader on an XHR. Mea maxima culpa.

Re: #1 CSRF Is A Vulnerability In All Browsers

#189

Post by andypants » Sat, Mar 31, 2012, 1:21 AM UTC

Cushman wrote: post #185

andypants wrote: post #180

Earlier quoted context omitted.

He provided instructions to your browser to include an image. If that is considered 'without your consent', then so is every site that is embedding external plugins, images, and videos. How are you supposed to 'give your consent'? Must you be given a list of all the content on the website before the browser will be allowed to display it? When you requested the page, you gave your consent to load whatever was on that…

I don't understand this argument. If I buy a box of cereal, and open it to find it contains a live rattlesnake, have I consented to be bitten by the snake because I knowingly purchased the box? Of course I don't know everything that's in cereal -- I trust the manufacturers to provide me with the product I paid for, whatever that involves. But I know for sure that that doesn't involve snakes, and had I had reason to b…

Well, my point is that almost all (harmless) sites do the exact same thing that this blog does, which is request an external resource such as an image. The browser can't differentiate between malicious ones or not, it simply loads them all, which is exactly what it's designed to do.

Imagine you are buying a 'random flavour' box of cereal, inside of which you may possibly find a snake flavoured cereal which does happen to contain a snake. Similarly, you don't know what you'll get on the Internet until you've received it, and you can't be sure that what you get will be safe.

Of course, you want the manufacturer to make sure there is no snake in your snake flavoured cereal. In this analogy, google is the manufacturer/snake owner. It is up to google to make sure their logout page can't be embedded in an image like in this blog.

Re: #1 CSRF Is A Vulnerability In All Browsers

#190

Post by Cushman » Sat, Mar 31, 2012, 1:29 AM UTC

andypants wrote: post #189

Cushman wrote: post #185

Earlier quoted context omitted.

I don't understand this argument. If I buy a box of cereal, and open it to find it contains a live rattlesnake, have I consented to be bitten by the snake because I knowingly purchased the box? Of course I don't know everything that's in cereal -- I trust the manufacturers to provide me with the product I paid for, whatever that involves. But I know for sure that that doesn't involve snakes, and had I had reason to b…

Well, my point is that almost all (harmless) sites do the exact same thing that this blog does, which is request an external resource such as an image. The browser can't differentiate between malicious ones or not, it simply loads them all, which is exactly what it's designed to do. Imagine you are buying a 'random flavour' box of cereal, inside of which you may possibly find a snake flavoured cereal which does happe…

Edit: I think I sounded a little sharp before... what I'm trying to say is this: Your explanation makes perfect sense to explain why my browser makes the request. I asked for the page, it assumes I want everything that's in the page. It's dumb. That's fine.

But imagine trying to explain to a judge that the fact that I asked for the page means that it's okay that it did something that I didn't want to happen. She's not going to believe you, and she'll be right not to. That's all I'm saying.