Page MenuHomePhabricator

"options" API module allows injecting JavaScript code as an "editfont"
Closed, ResolvedPublic


Reported by Kevin Israel. Roan is adding a fix for this now.

I found MediaWiki 1.20 and newer allow arbitrary code to be injected
into ''every'' page (even Special:ChangeEmail, Special:ChangePassword,
and Special:Preferences) through the "editfont" option.

Although not an immediate security problem, it has the implication that
trojanized user scripts and other malware could potentially a) store
malicious JavaScript code where hardly anyone would notice it; and b)
bypass the OutputPage::disallowUserJs() check.

Previously, all preference changes had to be made through
Special:Preferences, which performs some validation (at least for the
"editfont" option). However, the API "options" module does not validate
preference values, and neither does the ResourceLoader code
that generates a corresponding CSS rule.


Because users cannot see each other's preferences, such code injection
might allow long-term account compromise to remain undetected for a while.

Also, because style elements are added in the head section of the HTML
code, at the top of the page, such injection can be used to create more
convincing phishing attacks, especially when it is used to inject code
into the special pages mentioned above.

Version: 1.20.x
Severity: major



Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:12 AM
bzimport set Reference to bz42202.
bzimport added a subscriber: Unknown Object (MLST).
  • Bug 42203 has been marked as a duplicate of this bug. ***

Created attachment 11382
Validate editfont in RL module

Perform basic validation of 'editfont' in the user.cssprefs module. This whitelists the characters needed to support the current options for editfont (a-z and -) as well as [A-Z0-9_] for future use, and [, ] for specifying multiple font families in the future. After briefly talking to Chris I chose not to include " (needed for font names with spaces in them, but scary from a validation perspective).


Created attachment 11383
Perform validation in action=options API

The action=options API module wasn't performing any validation whatsoever, so validate preference values before storing them.


Patches look good to me. I'll have Reedy push these to the cluster on Monday (at least the ResourceLoaderUserCSSPrefsModule.php patch), unless anyone sees a problem with them.

Can you add here a pointer to the change, for future reference?

For the resource loader change:

For the API module change:

Note the change fixing this bug caused bug 42638 and bug 42639.

This fix also caused bug 44359 and some other extension bugs. Next time please advertize more widely before turning off a major API feature. Thanks!