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

Re: #1 CSRF Is A Vulnerability In All Browsers

#241

Post by nbpoole » Sat, Mar 31, 2012, 1:37 PM UTC

tomjen3 wrote: post #234

nbpoole wrote: post #222

Earlier quoted context omitted.

" This will not work even without CSRF protection. " It actually will work. What you're describing is what's known as a "simple" request in XMLHttpRequest terms. That means there is no pre-flight necessary. Your browser will simply make the POST as requested and receive the response. It won't make the response available to you since the Access-Control-Allow-Origin header isn't set, but you're a malicious attacker in…

I would like to know one thing. Who the hell thought it was a good idea to allow crossdomain XmlHttpRequests? Given that the standard say that post is for modification no other website should ever make thoes requsts.

The CORS standard for 'simple' POSTs is no different than what you can already submit via a form from a technological perspective. In that way, it actually makes a lot of sense.

And the whole point of CORS is that some websites do want to make those requests. ;-)

Re: #1 CSRF Is A Vulnerability In All Browsers

#242

Post by swah » Sat, Mar 31, 2012, 1:50 PM UTC

Are REST APIs susceptible in the same way? Or as long as we don't store our auth token on the client cookie we're ok?

Re: #1 CSRF Is A Vulnerability In All Browsers

#243

Post by tptacek » Sat, Mar 31, 2012, 4:17 PM UTC

baddox wrote: post #236

homakov wrote: post #206

Earlier quoted context omitted.

>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

You're both just choosing different places to draw the line between developer responsibility and browser responsibility .

That is like saying "you're both just suggesting two totally different designs for the HTTP security model".

His model is wrong. Again: I assume he wants to know that, so, bluntness.

Re: #1 CSRF Is A Vulnerability In All Browsers

#244

Post by javajosh » Sat, Mar 31, 2012, 7:48 PM 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…

I'm actually quite curious about your viewpoint, and why it seems so difficult to shift - set in your ways, so to speak. So let me see if I can't let Charle's Stross give it a try:

"You're right in principle, but you're right for the same reason and to the same limited extent as if you said "people have a responsibility to be aware of the locks on their front door and windows and to use them". Which is that you omit the other side of the social contract: we all have an obligation not to exploit our neighbors' negligence if they leave their door unlocked by burgling them."[1]

[1] http://www.antipope.org/charlie/blog-static/2012/03/not-an-a...

Re: #1 CSRF Is A Vulnerability In All Browsers

#245

Post by tptacek » Sat, Mar 31, 2012, 7:56 PM UTC

javajosh wrote: post #244

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…

I'm actually quite curious about your viewpoint, and why it seems so difficult to shift - set in your ways, so to speak. So let me see if I can't let Charle's Stross give it a try: "You're right in principle, but you're right for the same reason and to the same limited extent as if you said "people have a responsibility to be aware of the locks on their front door and windows and to use them". Which is that you omit…

I have no idea what you are trying to say here. This is an engineering discussion, not a dorm room debate.

What you've tried to argue here is that we should add new HTTP verbs to express "this endpoint shouldn't allow cross-domain requests". Or, more generally, that we should add HTTP features to allow browsers to prevent CSRF attacks.

But CSRF isn't a browser security problem. It isn't even necessarily a cross-domain problem! (CSRF is in that respect misnamed.) The specific changes you've suggested would drastically change the HTTP protocol but couldn't even theoretically solve the request forgery problem, not just because of intra-site CSRF but because your suggested locked-down HTTP requests would also break otherwise viable apps --- meaning that many apps couldn't use these features even if they wanted to, and would have to rely on something else for CSRF protection.

The fact is that having browsers police request validity just doesn't make sense. Even if they could do that, they still obviously have to rely on serverside signals to determine whether a request is or isn't valid. If the serverside knows a request isn't valid, it already has the means to block it! Why on earth would the server punt this to the browser?

Your suggestions have the appearance of not being familiar with how CSRF protection works in apps today. It is almost a one-liner in many modern frameworks.

Re: #1 CSRF Is A Vulnerability In All Browsers

#246

Post by javajosh » Sat, Mar 31, 2012, 8:36 PM UTC

tptacek wrote: post #245

javajosh wrote: post #244

Earlier quoted context omitted.

I'm actually quite curious about your viewpoint, and why it seems so difficult to shift - set in your ways, so to speak. So let me see if I can't let Charle's Stross give it a try: "You're right in principle, but you're right for the same reason and to the same limited extent as if you said "people have a responsibility to be aware of the locks on their front door and windows and to use them". Which is that you omit…

I have no idea what you are trying to say here. This is an engineering discussion, not a dorm room debate. What you've tried to argue here is that we should add new HTTP verbs to express "this endpoint shouldn't allow cross-domain requests". Or, more generally, that we should add HTTP features to allow browsers to prevent CSRF attacks. But CSRF isn't a browser security problem. It isn't even necessarily a cross-domai…

The thing that troubles me is not that you don't like the HTTP verb solution, but that you don't seem to accept the fact that there is a client-side problem to solve in the first place.

Your argument is equivalent to saying that websites should protect themselves from DDoS attacks - and that users should simply accept that their machines will be hacked and will become part of a botnet (or several botnets) at some point in time. In other words, DDoS is a server-side problem, not a client problem. Whereas I (and I think that most people) believe that it is our responsibility to use our computing resources responsibly, and work hard to avoid being included in a botnet.

You seem like a smart person, and I'm sure you have something to contribute to the client-side of this issue, but that won't happen until you are convinced that there is a client-side problem.

In any event, somewhat selfishly I suppose, I've found this discussion quite useful in clarifying my own views on the matter. So, thank you for violently disagreeing with me. :)

Re: #1 CSRF Is A Vulnerability In All Browsers

#247

Post by tptacek » Sat, Mar 31, 2012, 8:40 PM UTC

javajosh wrote: post #246

tptacek wrote: post #245

Earlier quoted context omitted.

I have no idea what you are trying to say here. This is an engineering discussion, not a dorm room debate. What you've tried to argue here is that we should add new HTTP verbs to express "this endpoint shouldn't allow cross-domain requests". Or, more generally, that we should add HTTP features to allow browsers to prevent CSRF attacks. But CSRF isn't a browser security problem. It isn't even necessarily a cross-domai…

The thing that troubles me is not that you don't like the HTTP verb solution, but that you don't seem to accept the fact that there is a client-side problem to solve in the first place. Your argument is equivalent to saying that websites should protect themselves from DDoS attacks - and that users should simply accept that their machines will be hacked and will become part of a botnet (or several botnets) at some poi…

Request forgery is nothing like DDoS. I found the rest of your comment too vague to respond to. I can't rebut anything you've said without repeating myself.

You keep saying CSRF is a "client-side problem", but you haven't explained why you think that, other than that it's a problem that is occurring in a client-server system so somehow the client must be involved. That's flimsy logic.

Re: #1 CSRF Is A Vulnerability In All Browsers

#248

Post by javajosh » Sat, Mar 31, 2012, 9:09 PM UTC

tptacek wrote: post #247

javajosh wrote: post #246

Earlier quoted context omitted.

The thing that troubles me is not that you don't like the HTTP verb solution, but that you don't seem to accept the fact that there is a client-side problem to solve in the first place. Your argument is equivalent to saying that websites should protect themselves from DDoS attacks - and that users should simply accept that their machines will be hacked and will become part of a botnet (or several botnets) at some poi…

Request forgery is nothing like DDoS. I found the rest of your comment too vague to respond to. I can't rebut anything you've said without repeating myself. You keep saying CSRF is a "client-side problem", but you haven't explained why you think that, other than that it's a problem that is occurring in a client-server system so somehow the client must be involved. That's flimsy logic.

> Request forgery is nothing like DDoS.

Forgery is like DDoS in that they both use the unwitting (and unwilling) compute resources of an intermediate victim to mount the attack. The unit of distribution of the DDoS case is a binary rootkit (for example) and the unit of distribution for a forgery attack is a web page.

The impact of successful DDoS and CSRF attacks are very different, of course, but the mechanism used to carry them out is very similar. In particular, they both differ from an ordinary hacker-to-target penetration, DoS, forgery etc. attack.

Re: #1 CSRF Is A Vulnerability In All Browsers

#249

Post by tptacek » Sat, Mar 31, 2012, 9:14 PM UTC

javajosh wrote: post #248

tptacek wrote: post #247

Earlier quoted context omitted.

Request forgery is nothing like DDoS. I found the rest of your comment too vague to respond to. I can't rebut anything you've said without repeating myself. You keep saying CSRF is a "client-side problem", but you haven't explained why you think that, other than that it's a problem that is occurring in a client-server system so somehow the client must be involved. That's flimsy logic.

> Request forgery is nothing like DDoS. Forgery is like DDoS in that they both use the unwitting (and unwilling) compute resources of an intermediate victim to mount the attack. The unit of distribution of the DDoS case is a binary rootkit (for example) and the unit of distribution for a forgery attack is a web page. The impact of successful DDoS and CSRF attacks are very different, of course, but the mechanism used…

You didn't answer my question.

Re: #1 CSRF Is A Vulnerability In All Browsers

#250

Post by javajosh » Sat, Mar 31, 2012, 10:33 PM UTC

tptacek wrote: post #249

javajosh wrote: post #248

Earlier quoted context omitted.

> Request forgery is nothing like DDoS. Forgery is like DDoS in that they both use the unwitting (and unwilling) compute resources of an intermediate victim to mount the attack. The unit of distribution of the DDoS case is a binary rootkit (for example) and the unit of distribution for a forgery attack is a web page. The impact of successful DDoS and CSRF attacks are very different, of course, but the mechanism used…

You didn't answer my question.

You didn't ask a question (was there a question mark in your post that I missed?). You did, however, make an assertion which I corrected.

In an honest, respectful discussion that would occasion a response along the lines of either: "Ah, I didn't think about it like that. Let me see about adjusting the line of my reasoning," or, "No, your correction is invalid because..."