Hacker News Reader

Comment by palish | Hacker News Reader

Sorry.. I probably seem like I'm doing this for the karma. I'm not; I just wanted to see if a flaw existed. It does.. The upvote needs to be a POST, not a GET.

Shawn Presser

View on HN

Nope, POST does not prevent this kind of thing -- it's just as easy to forge a POST as a GET. See http://en.wikipedia.org/wiki/Cross-site_request_forgery

To protect a site, you must include an unguessable parameter in all side-effecting requests.

Right, like the session ID. Except I'm not sure arc has session ids.. Just ids embedded into all links in the site.

And if you're going to be putting the session id somewhere, it should be in a POST request, not a GET request, otherwise it can be hijacked.

GET and POST have nothing to do with it. You could have written this hack just as easily (or nearly as easily) if POST were required.

To fix the problem, PG needs to check that the userid that clicked the fnid is the same as the userid for which it was created.

BTW, browser bugs actually make the problem even more complex than this because it is sometimes possible to steal content off of other pages.

You're right :) But I don't see how that can be done if the front page is cached, so therefore the same ID is assigned to many people. I haven't researched session cookies yet to know if that can solve the problem.

Browser bugs that steal content off other pages -- is that why oftentimes the session id is not used as the secret in side-effecting requests? I've seen a lot of sites use random unique secrets and wondered why they didn't just use the session id.

GET operations should be safe:

"If you use GET for interactions with side-effects, your make your system insecure."

(from http://www.w3.org/2001/tag/doc/whenToUseGet.html#safe)

Reply on news.ycombinator.com