Page MenuHomePhabricator

Load user javascript on Special:Preferences
Closed, DuplicatePublic

Description

Currently the User:XXX/common.js etc. is not loaded on Special:Preferences. I've read many reasons for this, but IMHO none is (still) valid:

  • If a user breaks something, he should be able to switch to a working skin.
    • This is no longer a valid reason, as common.js is active in any skin anyway.
    • It actually never was a valid reason, as the .css files are loaded even on Special:Preferences, and a * {display:none;} breaks more than you can break with javascript.
  • An evil script could manipulate the password/email.
    • Password and email are now on their own special pages (and scripts aren't and shouldn't be loaded there for exactly that reason).
  • An evil script could read other settings (like the watchlist token).
    • These are available via mw.user.options on any page.
    • And of course $.get('/wiki/Special:Preferences').done(function(html) { //analyze html }); was always possible.
  • An evil script could change settings.
    • There is even an API module for this.
    • And of course using $.post as above for $.get was always possible.

So I can't find any reason not to load the user's javascript on Special:Preferences. On the other hand there are many user scripts that add some entries to the side bar or other navigation elements which should be there on Special:Preferences, too, to ensure a consistent layout.


Version: 1.22.0
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68521

Details

Reference
bz48931

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:39 AM
bzimport set Reference to bz48931.
bzimport added a subscriber: Unknown Object (MLST).
Schnark created this task.May 29 2013, 9:26 AM

What about site js then?

(In reply to comment #0)

  • An evil script could manipulate the password/email.
    • Password and email are now on their own special pages (and scripts aren't and shouldn't be loaded there for exactly that reason).

I think the more likely attack is that the evil script changes the links to those pages, shows a fake form, which then ships the password off to the attacker.

Of course, once an evil script has taken over the user's UI, they can just change the preferences link, so it's really not that much less secure. But it's one more obstacle for the attacker.

(In reply to comment #2)

I think the more likely attack is that the evil script changes the links to
those pages, shows a fake form, which then ships the password off to the
attacker.

Well, those links are on [[Special:SpecialPages#Users_and_rights]], too, though probably more users will go through their preferences. Anyway, an email "Somebody is trying to crack your (Wikipedia|...) password [that's not even a lie!], please visit <fake address> and change it!" sent to many users, is much easier than changing links.

In IE in quirks mode you can also execute javascript using CSS:

.mw-special-Preferences {
color:expression(importScript("..."));
}

Per comment 2, there is a reason for scripts to be disabled: I don't see compelling reasons to enable them, so I don't expect the security advantage, however small, to be dropped.