Roan Kattouw wrote:
brion@svn.wikimedia.org schreef:
Revert r27151 -- allows session fixation attacks. Just get a user to visit a URL with the user ID and token you like in the query string (say, in an <img> referenced in a page you convince them to go to or post for their review) and their login session will be replaced with the one you provided.
I don't see how this is bad: you can try and trick another user into doing something *logged in as you*, so it will appear as if *you* did it. Why not do it yourself if it's gonna be logged under your name anyway? Besides, this login session substitution only works for the API: the UI completely ignores the lg* stuff, and your cookies aren't overwritten.
Perhaps you didn't look at the code or test it, but I can confirm that it most definitely overwrites the live session, leaving the UI logged in with the attacker's account.
Now if this provided a way for a non-sysop to trick a sysop into deleting an article, I would acknowledge that that's a security issue. I don't see the issue here, however: the delete, or whatever it is you're trying to do, is gonna be logged with the attacker's name, checked against the attacker's permissions, etc. Also, the session is not really a session: the API doesn't spit out any cookies outside of the login module (that I'm aware of, anyway).
I fail to see the security issue here.
Session fixation is generally dangerous because it allows an attacker to gain some amount of access to privileged information.
An example off the top of my head: force someone to a login session with customized JS which alters the user interface to appear as though they've been logged out, then capture the password when they attempt to log back in (with a URL on the genuine site, thus being harder to recognize as illegitimate).
-- brion vibber (brion @ wikimedia.org)