Last modified: 2014-07-24 18:41:56 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T50931, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 48931 - Load user javascript on Special:Preferences
Load user javascript on Special:Preferences
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
1.22.0
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-29 09:26 UTC by Michael M.
Modified: 2014-07-24 18:41 UTC (History)
7 users (show)

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


Attachments

Description Michael M. 2013-05-29 09:26:44 UTC
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.
Comment 1 Liangent 2013-05-29 09:34:35 UTC
What about site js then?
Comment 2 Chris Steipp 2013-05-31 22:02:14 UTC
(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.
Comment 3 Michael M. 2013-06-03 08:24:53 UTC
(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("..."));
}
Comment 4 Nemo 2014-05-17 08:50:50 UTC
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.

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


Navigation
Links