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.
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.
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.
Comments
Not a very interesting hack.
I am sure that when they created the website they did not want to take a ton of security precautions in order to prevent things like this.
I am sure that you can create a hack that will start 1 million threads, post 1 million comments, and create 1 million users.
Ok, will fix.
geeks.
I did.
Not multiple times, though.
nope...i didnt
Okay, good. The ID's appear to rotate, so it seems pretty secure.
Or not.
i guess it doesnt update my session that i voted and can still vote the normal way
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
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.
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.
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.
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)
What I did was grab the ID of this article, then embed an iframe on the next page with a link pointing to it.
Worked for me.