brion@svn.wikimedia.org schreef:
Revision: 27514 Author: brion Date: 2007-11-15 04:24:49 +0000 (Thu, 15 Nov 2007)
Log Message:
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. 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.
Roan Kattouw (Catrope)
Roan Kattouw writes:
brion@svn.wikimedia.org schreef:
Revision: 27514 Author: brion Date: 2007-11-15 04:24:49 +0000 (Thu, 15 Nov 2007)
Log Message:
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. 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.
Roan Kattouw (Catrope)
User may accidantly give an URL with API registration token. Also, you can make user to edit with *his* account, but with *yours* IP (so it may cause mess on checkusing) --VasilievVV
vasilvv@gmail.com schreef:
User may accidantly give an URL with API registration token.
Non-stupid users generally don't do that
Also, you can make user to edit with *his* account, but with *yours* IP (so it may cause mess on checkusing)
True. But he's the one who'll get blocked for it if the edit is bad.
Roan Kattouw (Catrope)
Roan Kattouw wrote:
vasilvv@gmail.com schreef:
User may accidantly give an URL with API registration token.
Non-stupid users generally don't do that
This isn't about whether users are stupid or not, it is about possibility.
Also, you can make user to edit with *his* account, but with *yours* IP (so it may cause mess on checkusing)
True. But he's the one who'll get blocked for it if the edit is bad.
Not if the admin keeps autoblock enabled.
MinuteElectron.
Generally speaking, no confidential information should be provided as GET parameters. This includes session info and passwords. People have a tendency to copy and paste URLs and expect that they'll work for everyone. If the user clicks a link to another page, the confidential information will be provided in the Referer header. It also screws with search engines, and so on.
Tricking someone into logging in as an account you have control over has ridiculously many security issues. Just stick some malicious JavaScript in your user JS, for instance, and you can possibly steal *their* account passwords, cookies, or other sensitive info, because you're running the JS from en.wikipedia.org.
Of course theoretically some of this might not apply to bots, but why do bots mind staying logged in through cookies, or at least POST parameters?
Simetrical wrote:
Of course theoretically some of this might not apply to bots, but why do bots mind staying logged in through cookies, or at least POST parameters?
It wa aded for dumb frameworks which only support GET (see mediawiki-api-l). We could fix the session replacing by requiring a token from the same ip but forcing people to use better ways might be better. A token would prevent it from being cached, but not from having the password on the logs.
Simetrical schreef:
Of course theoretically some of this might not apply to bots, but why do bots mind staying logged in through cookies, or at least POST parameters?
True. I've always thought the lg* feature to be somewhat superfluous, but it's become clear to me now that it's even dangerous.
Roan Kattouw (Catrope)
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)
wikitech-l@lists.wikimedia.org