6 ms·
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.
by kijin 15y ago
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.
- 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
- Udo 15y agoDon't be so condescending, you didn't read my entire post. To quote myself: > POST (and restricting to same-origin) I still don't think it's possible to forge the referer header on an uncompromised browser.
- sp332 15y agoWould restricting to same-origin break http://hackerne.ws http://hackerne.ws?