Comment by naz
13 years ago
This is why you shouldn't allow GET for performing actions. An image tag in an article could do the same thing (e: if it didn't check the referrer).
13 years ago
This is why you shouldn't allow GET for performing actions. An image tag in an article could do the same thing (e: if it didn't check the referrer).
POST with CSRF protection is the answer: http://crazyviraj.blogspot.com/2009/10/xsrfcsrf-attacks-in-n...
It's trivially easy to forge POST requests, too.
What's really needed is a token (nonce) that is tied to the session. That's like CSRF Prevention 101.
In this specific case merely forging a POST request externally does nothing as the user has to be signed in for this to work. Thus, restricting actions such as voting to POST (and restricting to same-origin) does constitute adequate protection if there is no XSS vulnerability on the site.
But if the user IS signed in (and if someone arrives at your site from a link on Hacker News there's a very good chance they will be signed in) a POST forged from your site can affect their session. Read up on CSRF - it's a very different vulnerability from XSS (though having an XSS vulnerability will make any CSRF protection you have in place null and void).
http://en.wikipedia.org/wiki/CSRF
1 reply →
Would restricting to same-origin break http://hackerne.ws?
Or xhr with custom header, if you don't want to have to keep track of state.
So that anyone who has JavaScript disabled will be treated like an attacker? No thanks, HN is one of very few sites nowadays that work fine without JavaScript tricks, and I'd much rather PG kept it that way.
A custom header is not sufficient (blame Flash): http://lists.webappsec.org/pipermail/websecurity_lists.webap...
Someone in the other thread pointed out it at least checked the referrer header.
That's not a good enough solution - there are decent reasons that a referrer header might be missing (some PC antivirus software strips out referrer headers for example). The only safe way to handle this is with a POST request protected by a CSRF token tied to a cookie.
+1 You can’t trust the Referer header.
GET with randomized ids and checking referrer should be good enough to keeps things simple.
Really? I block the referer header so I guess all my upvotes haven't been counted. :(
The referer header is also controlled by the client. Anything controlled by the client should be considered tainted.
This doesn't really apply when you are trying to verify whether the client actually performed some action.
In a CSRF scenario, the client itself can presumably be "trusted" - A client behaving maliciously can only hurt itself, not any one else. The important thing is to not trust anything that may have been provided by a third party.