#1 CSRF Is A Vulnerability In All Browsers

Post by txt » Sat, Mar 31, 2012, 4:04 AM UTC

eurleif wrote: post #71

txt wrote: post #68

Adding a extra token for protection against CSRF attacks will only work if is changed on each request. Some of the biggest sites out there do not do this. I know of one site in particular (I won't name it, but its HUGE) that generates a unique token every time a user logs in. The token doesn't change until the user logs out even if the user closes the browser and doesn't go back to the site for a week, the token will…

You shouldn't be able to get the token from another domain, regardless of how long it lasts. How are you able to?

Post by txt » Sat, Mar 31, 2012, 4:05 AM UTC

yuliyp wrote: post #137

txt wrote: post #68

Adding a extra token for protection against CSRF attacks will only work if is changed on each request. Some of the biggest sites out there do not do this. I know of one site in particular (I won't name it, but its HUGE) that generates a unique token every time a user logs in. The token doesn't change until the user logs out even if the user closes the browser and doesn't go back to the site for a week, the token will…

Did you consider reporting it? Many such "huge" sites have bug bounty/white hat programs.

Post by tptacek » Sat, Mar 31, 2012, 4:27 AM UTC

majke wrote: post #194

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…

> The difference between browser-based CSRF protections (which don't exist) What about the X-Frame-Options and Origin headers? They are browser-based mechanisms that hint server side, right? (not for the classic POST case though...)

Post by tptacek » Sat, Mar 31, 2012, 4:28 AM UTC

ricardobeat wrote: post #210

nbpoole wrote: post #148

Earlier quoted context omitted.

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

Post by nbpoole » Sat, Mar 31, 2012, 4:40 AM UTC

ynniv wrote: post #216

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…

Firefox already blocks off-domain POST requests, unless the 3rd party domain responds to an OPTIONS preflight request. So, I'm talking only about forms sending and GET is ok sure. Google's logout CSRF works because the logout link is a GET request. So, no, there is no quick fix.