News for hackers. Stuff that matters.
Re:#1 CSRF Is A Vulnerability In All Browsers by divtxt on Friday March 30, 2012 @08:10PM (#3778747)
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:

<form action="http://bank.com/send_money><input name="to_account" value="SCAMMER-1234"></form>

Worse, one article will tell you to only allow Referrer == "bank.com", and then another will tell you that even that is no longer enough?!!!

Why can't we change the browser or the web server layer to prevent this by default?!

Re:#1 CSRF Is A Vulnerability In All Browsers by eurleif on Friday March 30, 2012 @08:11PM (#3778753)
Browsers don't prevent it because there are legitimate uses for cross-domain posts. Good frameworks do prevent it with CSRF tokens.
Re:#1 CSRF Is A Vulnerability In All Browsers by divtxt on Friday March 30, 2012 @08:14PM (#3778762)
I don't want the legitimate uses prevented. The default behavior should be to prevent, and the legitimate uses should explicitly opt-in. That way, you only have to do security analysis for those explicit points.
Re:#1 CSRF Is A Vulnerability In All Browsers by tedivm on Friday March 30, 2012 @08:36PM (#3778837)
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) it should be the server developers, not the browsers.
Re:#1 CSRF Is A Vulnerability In All Browsers by eurleif on Friday March 30, 2012 @08:37PM (#3778845)
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.
Re:#1 CSRF Is A Vulnerability In All Browsers by tedivm on Monday April 09, 2012 @11:08PM (#3820465)
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.
Re:#1 CSRF Is A Vulnerability In All Browsers by divtxt on Friday March 30, 2012 @08:57PM (#3778888)
Thank you for pointing me to X-Frame-Origin!

So, in the context of this discussion, why don't the browsers make X-Frame-Origin: DENY the default behavior?????

Re:#1 CSRF Is A Vulnerability In All Browsers by eurleif on Friday March 30, 2012 @08:18PM (#3778779)
But there's existing code that would break.
Re:#1 CSRF Is A Vulnerability In All Browsers by tomjen3 on Saturday March 31, 2012 @03:35AM (#3779717)
Can you give some examples of legitemate post requests that need to work cross-domain.
Re:#1 CSRF Is A Vulnerability In All Browsers by sdevlin on Friday March 30, 2012 @08:17PM (#3778778)
It's not that the referer header is not "enough". "Enough" implies that it falls somewhere on the scale of trustworthiness.

It's user input. Don't trust user input.

Re:#1 CSRF Is A Vulnerability In All Browsers by eurleif on Friday March 30, 2012 @08:19PM (#3778783)
Why shouldn't you trust user-provided data to secure the same user's data? The potential attack is someone forging their own referer header in order to attack themself.
Re:#1 CSRF Is A Vulnerability In All Browsers by sdevlin on Friday March 30, 2012 @08:53PM (#3778880)
The referer header can easily be forged. The whole point of a CSRF attack is to turn a user's credentials against him.
Re:#1 CSRF Is A Vulnerability In All Browsers by eurleif on Friday March 30, 2012 @08:53PM (#3778881)
How do you forge the referer header as a third-party site?
Re:#1 CSRF Is A Vulnerability In All Browsers by sdevlin on Friday March 30, 2012 @09:16PM (#3778944)
Ha, I'm wrong. I thought you could set the referer with setRequestHeader on an XHR. Mea maxima culpa.