5 ms·
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).
by naz 15y 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).
- olalonde 15y agoSomeone in the other thread pointed out it at least checked the referrer header.
- simonw 15y agoThat'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.
- ben0x539 15y agoReally? I block the referer header so I guess all my upvotes haven't been counted. :(
- danielrm26 15y agoThe referer header is also controlled by the client. Anything controlled by the client should be considered tainted.
- jbri 15y agoThis 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.
- kijin 15y agoIt'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.
- rabidsnail 15y agoOr xhr with custom header, if you don't want to have to keep track of state.
- simonster 15y agoA custom header is not sufficient (blame Flash): http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-February/007533.html http://lists.webappsec.org/pipermail/websecurity_lists.webap...
- kijin 15y agoSo 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.
- Udo 15y agoIn 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.
- simonw 15y agoBut 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 http://en.wikipedia.org/wiki/CSRF
- psychotik 15y agoPOST with CSRF protection is the answer: http://crazyviraj.blogspot.com/2009/10/xsrfcsrf-attacks-in-non-geek-speak.html http://crazyviraj.blogspot.com/2009/10/xsrfcsrf-attacks-in-n...