4 ms·
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 http:/
by paul 19y ago
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 http://en.wikipedia.org/wiki/Cross-site_request_forgery
To protect a site, you must include an unguessable parameter in all side-effecting requests.
- palish 19y agoRight, 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.
- paul 19y agoGET 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.
- palish 19y agoYou'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.
- brlewis 19y agoBrowser 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.