"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

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz42202.
csteipp created this task.Via LegacyNov 16 2012, 5:51 PM
Catrope added a comment.Via ConduitNov 16 2012, 6:12 PM
  • Bug 42203 has been marked as a duplicate of this bug. ***
Catrope added a comment.Via ConduitNov 16 2012, 6:55 PM

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).

Attached: 0001-bug-42202-Validate-editfont-before-embedding-it-in-C.patch

Catrope added a comment.Via ConduitNov 16 2012, 6:56 PM

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.

Attached: 0001-bug-42202-Validate-preference-values-in-action-optio.patch

csteipp added a comment.Via ConduitNov 17 2012, 1:05 AM

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.

Platonides added a comment.Via ConduitDec 2 2012, 10:08 PM

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

PleaseStand added a comment.Via ConduitDec 2 2012, 10:58 PM

For the resource loader change:

For the API module change:

Anomie added a comment.Via ConduitDec 3 2012, 4:36 AM

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

kaldari added a comment.Via ConduitFeb 2 2013, 8:06 AM

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!

csteipp added a project: Security.Via WebMar 26 2015, 8:39 PM

Add Comment