It's trivially easy to forge POST requests, too. What's really needed is a token...

Udo · on March 23, 2012

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.

simonw · on March 23, 2012

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

Udo · on March 23, 2012

Don'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 · on March 23, 2012

Would restricting to same-origin break http://hackerne.ws?

rabidsnail · on March 23, 2012

Or xhr with custom header, if you don't want to have to keep track of state.

kijin · on March 23, 2012

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.

simonster · on March 23, 2012

A custom header is not sufficient (blame Flash): http://lists.webappsec.org/pipermail/websecurity_lists.webap...