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

Re: #1 CSRF Is A Vulnerability In All Browsers

#251

Post by tptacek » Sat, Mar 31, 2012, 11:23 PM UTC

javajosh wrote: post #250

tptacek wrote: post #249

Earlier quoted context omitted.

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

I think you would enjoy the book _The Tangled Web_ by Michel Zalewski, of Google's browser & web security team.

Re: #1 CSRF Is A Vulnerability In All Browsers

#252

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

spamizbad wrote: post #18

homakov wrote: post #12

Earlier quoted context omitted.

nope. Token Pattern is ugly workaround browsers' vulnerability - that's the point.

You know more about this stuff than me, but I always assumed it was the cost of using the HTTP protocol due to its stateless nature. Even if browsers "fix" this issue, you're still placing a measure of trust in the client by not implementing server-side protections.

He is incorrect on this point. Authentication of requests is not an "ugly workaround" to a browser security issue.

The browser isn't just doing what it's "supposed to be doing" (always a flimsy argument in favor of the status quo, I agree!) but also all it can do, since only the server has the information needed to judge how sensitive a request is.

It's true that servers & browsers work together to create a semblance of a security model for the web. But the bulk of the job belongs to the server; there are hundreds of thousands of different applications each with different needs. And the servers have a means of enforcing controls flexibly: by authenticating requests.

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 protecting your HN karma. The server is. The browser isn't protecting your code repository. The server is. No simple HTTP standard will cover all these cases, and so it's silly to suggest that HTTP is where this security controlled should be expressed.

Re: #1 CSRF Is A Vulnerability In All Browsers

#253

Post by huxley » Sun, Apr 01, 2012, 3:42 PM UTC

davepeck wrote: post #25

My app's web site is built with Django. I use the built-in CSRF tools. (I should emphasize that my site is strictly HTTPS.) In theory, no normal user will ever fail CSRF checks. In practice, tons of people have complained that they see Django's (very confusing) CSRF error page when they try to sign up for my service. This was surprising to me; I thought we were _way_ past this point. Digging into it, I've learned tha…

In terms of the error page, you can modify the CSRF error page by setting CSRF_FAILURE_VIEW:

https://docs.djangoproject.com/en/dev/ref/settings/#std:sett...

Update: I noticed that later in the thread you mention that you already provide a custom error page. I'll leave this for others who might not be familiar with custom CSRF error pages.

Re: #1 CSRF Is A Vulnerability In All Browsers

#254

Post by txt » Mon, Apr 02, 2012, 10:14 AM UTC

nbpoole wrote: post #220

txt wrote: post #213

Earlier quoted context omitted.

Im getting it on the same domain, but the request can be sent from any domain, as long as the user is logged in. And yeah, but they aren't offering anything that would be worth the time.

I think I know what site you're talking about. If I'm right, they do have a security bug bounty reporting program and you should take advantage of it: it will take maybe two minutes of your time and can net you a bit of cash! :-) (sorry for being oblique, but I have no way to contact you privately and ask you more directly!)

I haven't made up my mind yet what to do with it but you know there are some ways of being evil without so much evil. ;]

Re: #1 CSRF Is A Vulnerability In All Browsers

#255

Post by slurgfest » Tue, Apr 03, 2012, 5:47 AM UTC

There is a HUGE vested commercial interest in the CONTINUATION of the insecure status quo, in which all the control is on the server side (hence, with the companies doing tracking and advertising using third party requests, rather than with the end user).

Furthermore, the players funding browser development all share strongly in that vested interest. (Even for Firefox, follow the money - and if Firefox did try to lock down without industry agreement, it would lose, which Mozilla knows).

So you will not see any change. This also explains the degree of heat directed at the suggestion that client behavior could be less insecure by default, with regard to third party requests.

This is not new. Much of HTTP as originally conceived actually dictated a great deal more user control over what happened. Those standards had to be compromised from the word go in order to reach the present state.

Re: #1 CSRF Is A Vulnerability In All Browsers

#256

Post by tedivm » Tue, Apr 10, 2012, 3:08 AM UTC

eurleif wrote: post #169

tedivm wrote: post #168

Earlier quoted context omitted.

This to me is a server side issue- but that doesn't necessarily mean it's on the app developer. The behavior you're talking about can be set most servers directly, by adding the "X-Frame-Options" header into every request by default. Then exceptions would have to be made explicitly, by either the server admin or application developer. If anyone should change the default behavior (which I am not convinced is the case)…

X-Frame-Options only prevents the page from being displayed in a frame. It doesn't prevent a page on another domain from submitting a POST request.

CSRF is solved very simply by using tokens for each field. If the attacking site can't load the other page, it can't pull the token out, and without the token the post gets discarded. If you've abstracted your form generation this should be super simple to add.