Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

#1 CSRF Is A Vulnerability In All Browsers

homakov.blogspot.com

Post reply on HN
Print view View original

231–240 of 256 posts

Re: #1 CSRF Is A Vulnerability In All Browsers

#231

Post by meow »

euroclydon wrote: post #173
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…

Is the following accurate: If a form is served from domain A (via GET) in to an iframe on a page that was served from domain B, then the JS on the page from domain B is prevented from reading or writing data on the page from domain A (unless an x-domain policy is in place) though it may be able to post it.

Yes it wont be able to read it. But that's not what they are after. What they do want is to execute some user action on the server side. So this action would have taken place just by executing the GET/POST request.

Re: #1 CSRF Is A Vulnerability In All Browsers

#232

Post by nbpoole »

simonw wrote: post #229
wglb wrote: post #183

Earlier quoted context omitted.

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.

I get that - but the Google security FAQ suggests that fixing the issue is essentially impossible, whereas I'm pretty sure fixing it is the same as fixing any other CSRF hole.

The point that those blog posts make is that it's possible for a malicious attacker to log people out of a third-party site in multiple ways (specifically by messing with the user's cookies). Protecting one of those ways provides little to no benefit if the others are still unprotected.

One reason I've also heard cited is that you always want the logout links in your application to work: you want users to be able to terminate their sessions quickly and easily. If you have a CSRF token tied to your user's session and that user happens to click on an old logout link (maybe they had an old tab open or something), the user won't be logged out of the application.

Re: #1 CSRF Is A Vulnerability In All Browsers

#233

Post by tomjen3 »

nitrogen wrote: post #122
tomjen3 wrote: post #114

Earlier quoted context omitted.

Well no, it is illegally accessing a computer system, which i do believe is a felony.

But he didn't access Google's systems, your browser did. You requested the page, and your browser dutifully loaded the cross-site request image.

Almost all exploits work by making your computer requst or recieve some resource which causes your computer to take some action you didn't intent.

By your argument if I shoot you with your gun, I am not guilty of murder.

Re: #1 CSRF Is A Vulnerability In All Browsers

#234

Post by tomjen3 »

nbpoole wrote: post #222
akaBruce wrote: post #221

Earlier quoted context omitted.

Am I missing something here? Let's say you're logged into Gmail and Gmail had no CSRF protection anywhere. You're logged in while visiting my site. In my site, I include a little bit of JavaScript to make a POST request to Gmail telling it to forward copies of all your incoming email to my email address. This will not work even without CSRF protection. It would only work if Google sends back the header Access-Control…

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

Re: #1 CSRF Is A Vulnerability In All Browsers

#235

Post by tomjen3 »

eurleif wrote: post #150
divtxt wrote: post #149

Earlier quoted context omitted.

I have no problem with cross-site GET requests because I know GETs should behave as 'read-only' anyway for lots of reasons. What I don't get is how arbitrary cross-site POSTs with malicious values are allowed. As far as I can tell, anyone can post this form: http://bank.com/send_money> name="to_account" value="SCAMMER-1234"> Worse, one article will tell you to only allow Referrer == "bank.com", and then another will…

Browsers don't prevent it because there are legitimate uses for cross-domain posts. Good frameworks do prevent it with CSRF tokens.

Can you give some examples of legitemate post requests that need to work cross-domain.

Re: #1 CSRF Is A Vulnerability In All Browsers

#236

Post by baddox »

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

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

Re: #1 CSRF Is A Vulnerability In All Browsers

#237

Post by pbiggar »

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…

So rather than deny ALL requests, I think it would work if browsers merely stopped passing cookies on cross-site POST form submissions, no?

Then if 3rd party sites wanted to still use form submissions, they could use an auth token in the form (though I'm unsure why they would do this instead of using JSONP).

Re: #1 CSRF Is A Vulnerability In All Browsers

#238

Post by jim_lawless »

I had envisioned what I think is a more solid defense against CSRF ... I just haven't had time to build a proof.

Earlier commenters have noted that each request back to the server should include an unguessable token that cannot be derived by mining other pages on the site with cross-site AJAX requests.

My hypothetical solution is to embed that token in the prefix to the hostname after logging into the given site. The token would then be sent in the Host: header for all dynamic requests.

Step 1: You log in to www.somesite.kom.

Step 2: You are then forwarded to dynXXXXXXXX.somesite.kom where XXXXXXXX represents a unique, dynamically-generated token tied to your session.

The attacker must now know XXXXXXXX to properly form up a GET or POST request to attack your account.

The site itself could then use relative URL's for dynamic content or could use the appropriate templating system to ensure that any dynamic URL's ( either in HTML markup or script text ) contain the generated hostname.

Re: #1 CSRF Is A Vulnerability In All Browsers

#240

Post by euroclydon »

meow wrote: post #231
euroclydon wrote: post #173

Earlier quoted context omitted.

Is the following accurate: If a form is served from domain A (via GET) in to an iframe on a page that was served from domain B, then the JS on the page from domain B is prevented from reading or writing data on the page from domain A (unless an x-domain policy is in place) though it may be able to post it.

Yes it wont be able to read it. But that's not what they are after. What they do want is to execute some user action on the server side. So this action would have taken place just by executing the GET/POST request.

Thank you. I just wanted to make sure I understood the basis of why CRSF Tokens work.
Post reply on HN