Page MenuHomePhabricator

Javascript inject by anonymous users on private wikis with $wgRawHtml enabled
Closed, ResolvedPublic


Omer Iqbal noticed that invalid usernames on Special:PasswordReset were parsed as wikitext.

Although this can't be abused on a typical wiki, in the very special case that a wiki has wgRawHtml enabled, and rely on limiting who can edit to prevent attackers from adding javascript, the username on Special:PasswordReset can be supplied by anyone and will be parsed with wgRawHtml enabled.

Since Special:PasswordReset is whitelisted by default on private wikis, this could potentially lead to an xss crossing a privilege boundary.

The attack is additionally mitigated by default XFO rules preventing that special page from being used in an iframe, so the threat from this is very low.

Omer also reported the "html injection" directly to mozilla:

Version: unspecified
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:24 AM
bzimport set Reference to bz65501.
bzimport added a subscriber: Unknown Object (MLST).

Created attachment 15443
Escape username wikitext

When onSubmit returns an array, it's added to the output with, wfMessage( $msg, $params )->parse(), so that errors can contain wikitext.

This puts the username through wfEscapeWikiText. Having the function return a Status object instead of array would do the same thing, but a more complex patch that I would rather not do as a security fix.



*Probably* the second portion of the patch isn't necessary since $firstUser is a user object either from the database (which I hope wouldn't have any vulnerable names in it!) or User::newFromName with 'valid' validation mode (which I hope wouldn't allow through any vulnerable names!). But I doubt there's any harm in escaping it either, so better to be safe.

Cluster was patched today:
20:05 csteipp: fix deployed for bug 65501

Jeff, adding you since donatewiki has wgRawHtml enabled.

Markus, this was introduced in commit 399f9557, so 1.19-1.23 should probably get patched whenever you do the next release.

Patch applies nicely to REL1_19, REL1_21, REL1_22 and master. So it will be included in the next round on 28th May 2014. Tomorrow, I'll send out a pre-release announcement.

also, REL1_23 works well with the patch.

Gerrit bot probably can't comment here, but the patch for core was uploaded

Marking as fixed as it's been released by Markus today. Waiting on Jeff to confirm donatewiki has been patched before moving this out of the Security component.

awight deployed this patch over the weekend.