Last modified: 2012-04-16 09:15:56 UTC
Created attachment 7791 [details] patch fixes mentioned issue If you make a post to api.php with something like "action=login&lgname=TestUser&lgpassword=gotcha" the api responds with a NeedToken error, inside the error message the current session is included... so you can trick the api into telling you what the sessionid is to bypass httponly and get access to the user's login session. On wiki farm (like Wikia) an evil admin could alter common.js to run this POST request via AJAX for every logged in user that enters his wiki - having sessions he would be able to log in as any visitor of his wiki by creating proper cookie. Simple patch attached - for case LoginForm::NEED_TOKEN do not return sessionid.
All output of session IDs removed in r76077. I contemplated other ways of doing this, but none of them were secure. The session ID was output to help clients that couldn't read cookies properly, but I'm afraid we're having to drop support for those now.
And thanks for reporting this!
Hmm, on second thought, this isn't a security issue at all. Reverted r76077 in r76080. The only way an attacker can read the echoed session ID is if they can request it using JS running on the same domain (evil admin scenario, like you said). Cross-domain, it won't work. And if the attacker can run JS on the same domain, they can do much worse things already (e.g. bypass the CSRF safeguards and edit things as you), most notably access our cookies directly without needing the API to echo them back at them.
CC Tim Starling, want him to look at this in case I'm missing something.
This cookie is httponly so using document.cookie won't allow you to get it. The API call makes it possible. CSRF allows evil admin to run unprotected actions - such actions should be fixed (by require token for example). The bug mentioned here allows you not only to run unprotected action but take over the whole account and fixing it sounds reasonably.
(In reply to comment #5) > This cookie is httponly so using document.cookie won't allow you to get it. You're right about that, my mistake. > The > API call makes it possible. Yes, but it doesn't matter much, see below. > CSRF allows evil admin to run unprotected actions - such actions should be > fixed (by require token for example). > Yes, and we do require tokens. Tokens prevent CROSS-site scripting, but they can't protect against SAME-site scripting. Once the attacker has JS running on the same site, they can edit as you, create/move/delete pages at you, etc., etc., and we can't protect against that. So in practice, they've already taken over your account, and they can take it over for real by changing your e-mail address, using the "I forgot my password" feature to reset the password, then logging you out. > The bug mentioned here allows you not only to run unprotected action but take > over the whole account and fixing it sounds reasonably. Stealing someone's cookies does allow you to take over their account, but once you're running JS from the same domain you can already do the same thing without needing the cookie data.
