Page MenuHomePhabricator

Add warning to user Javascript files, warning the contents is public
Closed, ResolvedPublic



TARGETS: The following pages:

DESCRIPTION: MediaWiki allows users to upload custom JavaScript and CSS to alter the interface and
functionality of the system. This code is stored as a wiki page, and is visible to any user of the system.

EXPLOIT SCENARIO: A user uploads JavaScript containing personal information that may de-anonymize
that user. While the contents of this script are not part of the main indexed website, another user
changes the username in one of the above URLs to view the victim's custom code, learning information
that may be used to identify the owner of the custom code.

SHORT TERM SOLUTION: Treat custom script the same as other user preferences by disallowing users
from examining these customizations unless they are associated with the logged in account.

LONG TERM SOLUTION: The custom JavaScript system has several deficiencies. Consider deprecating
this functionality and allowing users to customize the site using client-side code instead.

Event Timeline

csteipp raised the priority of this task from to Needs Triage.
csteipp updated the task description. (Show Details)
csteipp added a project: acl*security.
csteipp changed Security from None to Software security bug.
csteipp added a subscriber: csteipp.
Restricted Application changed the visibility from "Public (No Login Required)" to "Custom Policy". · View Herald TranscriptJan 5 2015, 9:14 PM
Restricted Application changed the edit policy from "All Users" to "Custom Policy". · View Herald Transcript

I'm inclined to wontfix this and accept the risk on it

Restricted Application changed the visibility from "Custom Policy" to "Custom Policy". · View Herald TranscriptJan 5 2015, 9:18 PM
Restricted Application changed the edit policy from "Custom Policy" to "Custom Policy". · View Herald Transcript

I agree, particularly since the ability to view other users' JS is what led to the Gadgets extension.

Users are more likely to expose personal information on their user pages, IMO.

The complete solution to this would be to force all client Javascript components to be gadgets, and instead only allow users to enable gadgets rather than have custom arbitrary code. (There's also the related discussion on code review of gadgets and global JS.)

However, I'm sure we all know how well that would go over with the community. I agree that the risk is not really significant. Maybe if we just emphasize in the red warning on JS pages that anybody else can see the code? That should be enough IMO.

I agree, the code does not need to be hidden. If users are assuming it is private, we should fix that instead.

csteipp triaged this task as Lowest priority.Apr 1 2015, 11:15 PM

I'm planning to make the report public in the next few days.

Maybe if we just emphasize in the red warning on JS pages that anybody else can see the code?

This seems like it would be nice, but probably low priority and not something that needs to be handled as a security bug.

Unless anyone objects, I'll update the title of the task to be to add this warning message, set the priority to low, and make it public with the release of the report.

csteipp renamed this task from Users can inspect each other's personal JavaScript to Add warning to user Javascript files, warning the contents is public.Apr 20 2015, 5:11 PM
csteipp added a project: Design.
csteipp changed the visibility from "Custom Policy" to "Public (No Login Required)".
csteipp changed the edit policy from "Custom Policy" to "All Users".
csteipp changed Security from Software security bug to None.

It has always been clear that the content of user pages or subpages were publicly visible, including their custom javascript, which is essential for many Wikimedian users.

They also share these scripts (users can choose themselves whever or not to include them or copy them for their own user page, and even the same user may want to load the custom javascript from other wikis, possibly with several identities, i.e. multiple user accounts such as the normal user, a bot user, a WMF user, a special identity for specific tasks or roles).

So this is really not a serious issue. (Adding a warning banner at top of the javascript page, saying that this code is publicly visible, may be userful).

But if users really want to have private javascript, may be a special tag in the user javascript subpage may inform MediaWiki that its content will not be publicly visible

In my opinion it would be simpler to have this private javascript stored using a name within a standard subpage like "User:XXXX/private/custom.js", because it will not require processing the content of the subpage, but only its name! Or otherwise use a special namespace prefix such as "User private:XXX/custom.js" (this special namespace will not be a subject namespace, it will not have any associated talk page, or its associated talk page displayed by default at top of pages will be the standard user talk page, but I think this is not needed as this link to the user's own talk page is present in the user's navbar displayed at top of all pages).

This is also applicable with custom private CSS that would then be allowed to contain javascript using functions defined in the custom private javascript. In other words, load first the private javascript before the public javascript, and load the private CSS (which can include javascript properties defined in the private javascript) before the public CSS (which cannot include any javascript properties, but may still "@import CSS" from another wiki using a plain URL; you may also want to restrict this URL, or support a safer wikilink syntax for this public CSS such as "@import [[wikilink]]", which would be expanded to the standard API query URL to load it in "raw" mode with the standard "text/javascript" mediatype).

So this is really not a serious issue. (Adding a warning banner at top of the javascript page, saying that this code is publicly visible, may be userful).

Right, pending a little UX input, I think that will be the final result.

But if users really want to have private javascript, may be a special tag in the user javascript subpage may inform MediaWiki that its content will not be publicly visible

I don't believe this is requested, and would add a layer of complexity to MediaWiki that I would very much oppose.

Indeed. In the current form MediaWiki does not currently officially support content security at the page level. Only at the level of an entire wiki. There are too many ways revision'ed content can be exposed.

The only feasible option would be to use the user preferences system, in which case there is no versioning. However if a user wants private customisations, there are browser extensions available that will allow them to never even have to submit it in the first place.

Your remarkj about user preferences is pertinent, because it requires a server-side store.
However in Wikimedia, we have lots of wikis and SUL that complicates things a lot.

If we want to support a real single-signon system, those multiple server-side stores will have to be converted into a single store for the whole farm of wikis working with the same user authentication and their associated preferences. But this is not the case (and we also have different user rights per wiki, independantly of the single user identity : all happens in fact if a single user authentication is used in fact to manage a group of identities (that users don't really manage themselves as they are created automatically and msot often the user does not know when this happens).

This has consequences ! users suddently start receiving emails even if they have initially create their account to forbid it on thei initial wiki (and there's not even any global setting to set a global restriction against this, except on specific wikis where this has been allowed).

The situtation is even more complex because the signon process occurs in fact in a different server which is not really a wiki (the loginwiki), but they now have another default user page which is not the same: Metawiki ! Multiple stores on distinct servers for the same default identity...

Potentially this opens various security holes because it is possible to bypass a restriction just by selecting another wiki to perform the same action in order to target a user. This has to be rethought. We need a manageable central store for global authentification and global preferences, on an common central wiki, fully internationalized: Wikipedia editions are not suitable Commons is too much specialized, MetaWiki is OK and the LoginWiki should be deprecated and moved to MetaWiki... But MetaWiki has its own local restrictions too.

So effectively people don't really know where their preferences are mamanged, and they always need to check their preferences on each wiki (but there are hundreds wikis... this is impossible to do in practice, and in fact difficult becuase user preferences on many wikis are unreadable: users have to first guess where is the correct link to it, only to be able to select their UI language preference first and then check these preferences, and don't assume that even if that wiki displays some help in English this will be enough, not everyone can read the alternate English if they cannot read the default language of that wiki!). The problem being that there's still NO global preference for the user's language (the first barrier to remove before cleaning up the way to allow them manage preferences without having to visit hundreds of wikis)

Finally, the user preferences (that have no history) would be useful to store personal data (including personal scripts of stylesheets) in a dedicated special namespace (working across all wikis).

This global user space should also have contained the global "user page", except that it is made to be exposed publicly on all wikis... and versioned: so it cannot be the same namespace and has to be on a separate repository, and MetaWiki is OK for storing it (and sharing it publicly across all other wikis). But there's still no simple way for a user to remove a local version of his user page by the global user configured in MetaWiki (and to forbid it to be recreated locally by someone else to hide the global page configured on MetaWiki).

@Verdy_p, you should add your comments about global preferences to the existing tickets about it.

For the purposes of this ticket, we will add a warning for users (as the title says). If there is demand for private scripts, that should be tracked as a separate task.

Change 298188 had a related patch set uploaded (by Brian Wolff):
Tell users that js/css subpages are public

Bawolff added a subscriber: Bawolff.

So I'm just going to make a public patch for this, since not really an exploitable issue.

Change 298188 merged by Dpatrick:
Tell users that js/css subpages are public

Bawolff claimed this task.

I don't think this needs to be backported. I'm going to mark resolved.