Hacker News Reader

"Am I correct in interpreting that the fix would the be the same as the functionality provided by RequestPolicy (which he mentions in the post)? I've used that for it for quite a while now, and although it works well for me as a power-user (who is concerned about security), I can't imagine the confusion and pain a user will feel despite the message suggested."

That was my interpretation as well and I reached the same conclusion. Having the average user make application-level security decisions is a very bad idea.

RequestPolicy is a wonderful extension and I think its use should be encouraged. But the average user does not understand enough about an application and how it interacts with third-party websites to make informed decisions about whether a particular interaction is good or not. False positives (where the user flags a good interaction) will lead to loss of functionality while false negatives (where the user fails to flag a bad interaction) will lead to security vulnerabilities that website owners can't prevent.

In fact, if you're using Amazon's CloudFront CDN, and you're using HTTPS, you have NO way to keep everything under the same TLD; CloudFront can only serve its own SSL cert, not yours.

As my other comment highlighted, disabling 3rd party cookies will prevent most CSRF. As an added bonus it will also increase your privacy by preventing some (but not all) cross domain tracking.

I'm not following (but I'm a little buzzed). What do third-party cookies have to do with CSRF? CSRF is a flaw in the victim application.

Er, Third Party Cookies have absolutely no influence over CSRF.

And I am kind of at a loss where the cross-domain part of what you are saying is part of cross-domain tracking.

Kindly enlighten.

No need to go that far. The X-Frame-Options: SAMEORIGIN header, supported by all major browsers, can prevent the majority of these attacks (unwanted GET requests in the background).

https://developer.mozilla.org/en/The_X-FRAME-OPTIONS_respons...

Other than that, it should be hammered into developer's heads that GET should not have side effects.

"The X-Frame-Options: SAMEORIGIN header, supported by all major browsers, can prevent the majority of these attacks"

No it can not. I've seen this assertion popping up a few times on HN this past week: it's conflating two similar but very different attacks in a dangerous way.

X-Frame-Options prevents a type of attack known as clickjacking. It is similar to a CSRF, but it involves creating an iframe to a page with a form and convincing the targeted user to submit it. It provides this protection at the browser level: if an HTTP response contains the X-Frame-Options header and the requesting page violates that directive, the response is not rendered.

It does not prevent a CSRF attack. It's impossible for it to do so: once the malicious request had made it to the server and the server has sent back a response, the attack is already complete. There's nothing the browser can do to prevent it at that point. If you use nothing but X-Frame-Options to try and prevent CSRF, you'll have a site completely vulnerable to CSRF.