Last modified: 2011-04-30 01:21:09 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 23076 - Login CSRF
Login CSRF
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
1.15.x
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Tim Starling
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-06 23:55 UTC by Tim Starling
Modified: 2011-04-30 01:21 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Tim Starling 2010-04-06 23:55:32 UTC
MediaWiki 1.15.2 and earlier is vulnerable to a cross-site request forgery (CSRF) vulnerability in both its HTML login interface and its API login interface. 

Login CSRF is a particularly problematic kind of CSRF when it is combined with user scripting. An attacker can create an account with a user-specific script, then force another user (the "victim") to log in to that account. The prepared user script then takes control of the victim's browser. It can display a login form, apparently on the same domain, which captures the username and password of the victim when they submit the form.

See section 3 of this paper for more discussion of login CSRF:

http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf

To counter this, MediaWiki 1.15.3 will apply the standard defence for CSRF, that is to ask for a secret "token" before it allows a login. In the HTML interface (Special:UserLogin), the token is provided via a hidden form field called wpLoginToken, which the browser will automatically submit.

In the API, the login process becomes:

1. Submit a request with lgname and lgpassword, in the same way as you did for MediaWiki 1.15.2 and earlier. Save the cookies in the response.

   * An old unpatched server will respond with a response like {"login": {"result": "Success", ... }, assuming JSON format. If this occurs, you are logged in and can stop.

   * A patched 1.15.3 server will respond with {"login": {"result": "NeedToken", "token": ...}. Save the token from this response and proceed to step 2.

2. Submit a request with the cookies from step 1, and additionally submit the parameter "lgtoken", with the value from the token in step 1.

   * If the session cookie was not submitted correctly, or if the server-side session expired, the server may respond with {"login": {"result": "WrongToken"}}. You can report this as an error to the user, or retry after a few seconds.

   * If everything was OK, the response will be  {"login": {"result": "Success", ... } as in MediaWiki 1.15.2.
Comment 1 Tim Starling 2010-04-07 01:28:40 UTC
Release announcement: <http://lists.wikimedia.org/pipermail/mediawiki-announce/2010-April/000090.html>
Comment 2 xqt 2010-04-15 11:41:25 UTC
<quote>
* If the session cookie was not submitted correctly, or if the server-side
session expired, the server may respond with {"login": {"result":
"WrongToken"}}. You can report this as an error to the user, or retry after a
few seconds.
</quote>
If the session cookie was not submitted the server respond again with {"login": {"result": "NeedToken", "token": ...}. This could cause a infinite loop during the login process.
Comment 3 Sam Reed (reedy) 2010-04-15 11:43:15 UTC
Should be relatively trivial to fix...
Comment 4 Roan Kattouw 2010-04-15 11:44:57 UTC
This is not MediaWiki's problem; sanely-written clients will give up after a number of tries instead of sheepishly going into an infinite loop.
Comment 5 xqt 2010-04-15 12:02:18 UTC
I agree, it's not a problem to solve infinite loops by client. But mw does not react as described
Comment 6 Bryan Tong Minh 2010-04-15 12:07:20 UTC
Tokens are associated with sessions, so obviously a session cookie is required for it to work at all.
Comment 7 xqt 2010-04-15 12:29:13 UTC
Step by step:
1. I submit a request with lgname and lgpassword and save the token from this response
2. I submit a request with parameter "lgtoken", with the value from the token in step 1. but without the cookies

This means the session cookie was not submitted correctly and I would expect {"result": "WrongToken instead of {"result": "NeedToken",
Comment 8 Roan Kattouw 2010-04-17 10:26:36 UTC
(In reply to comment #7)
> Step by step:
> 1. I submit a request with lgname and lgpassword and save the token from this
> response
> 2. I submit a request with parameter "lgtoken", with the value from the token
> in step 1. but without the cookies
> 
> This means the session cookie was not submitted correctly and I would expect
> {"result": "WrongToken instead of {"result": "NeedToken",

From comment #0:
> 1. Submit a request with lgname and lgpassword, in the same way as you did for
> MediaWiki 1.15.2 and earlier. Save the cookies in the response.
[...]
> 2. Submit a request WITH THE COOKIES FROM STEP 1, and additionally submit the
> parameter "lgtoken", with the value from the token in step 1.
> 
(emphasis mine)

The cookie thing was mentioned in the original instructions, seems you missed it.
Comment 9 Platonides 2010-11-29 17:48:25 UTC
Was fixed in r64677

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links