Hacker News Reader

Comment by Xk | Hacker News Reader

The example there is one of a cross-site request forgery (CSRF or XSRF). They pose a solution for POST requests, namely, the "Anti-Forgery Token". This is the right way to stop CSRF on post forms.

However, this is a defense which works just as well for GET requests. Just put a nonce in the URL. /do.php?action=delete&id=3&nonce=88e3a6fe57854f2ed18c. Solves it just as well. (Another common solution is to duplicate the session cookie in the URL.) It is not bad form to have a get request which changes state so long as there is a nonce in the URL.

Edit: URL was being truncated.

View on HN

... and you just broke bookmarks ...

Why do people insist on hammering in the screws, and screwing in the nails?

If you want to send data from the browser back to the server, use a post. It isn't difficult!

Is the motivation behind this secretly that there is some retarded 3rd party framework in play here that doesn't support post? Something like Ruby on Rails or Django or some weird ass Java REST library???

There's no reason to bookmark the "Delete this email" link (a la SquirrelMail, RoundCube). Sometimes links make sense to use, and it's possible to safely make GET requests change state when you need to.

Edit:

Now that I think about it, why would you want to bookmark a link which modified state? The only time to use a nonce is to make it secure against CSRF attacks. You can't bookmark them when they're a post anyways, so you don't lose anything. Am I wrong somewhere?

Because links are links, and you are setting the wrong expectation by changing state via one.

I would disagree. Go to google, search anything. Notice that clicking a link is what sets safe search. It's a GET request. It's not all that unusual.

Rails does all of this stuff 100% correct. It basically gives you a Level 2[1] REST interface by default.

The people most likely screwing this up are the PHP-without-a-framework people.

1: http://martinfowler.com/articles/richardsonMaturityModel.htm...

I'm positive that rails and fairly sure that django don't subscribe to the madness of state changing get-requests. From what I've seen of Java though, all bets are off.

> duplicate the session cookie in the URL

Please don't do that. If you inadvertently paste the URL into an IM window, post in a forum, etc., it becomes trivial for me to steal your session.

On the other hand, if you store it in the cookie you can't have multiple sessions running at once in different tabs. Session hijacking is only a concern if there's something worth stealing in the session, which isn't always the case. Both approaches have their advantages and disadvantages.

Reply on news.ycombinator.com