Page MenuHomePhabricator

Common misuse of importScript in global js pages make users load scripts from non-protected pages
Closed, ResolvedPublic

Description

A number of users have created their global.js page on Meta-Wiki by copying some content from their home wiki, with calls of importScript that use a localized version of the user namespace, for instance:

importScript('Utilisateur:Orlodrim/ArticlesRecents.js');

importScript('Benutzer:APPER/WikiHistory.js');

On any wiki whose language is not French or German (for these examples), the pages are in the main namespace, so they can be edited by anyone.

I could contact those users or have a bot fix all occurrences, but new ones are likely continue to appear continously. Is there any chance that it could be blocked by MediaWiki itself? For instance, ignoring importScript for pages in the main namespace that contain a colon.

Event Timeline

Maniphest changed the visibility from "Public (No Login Required)" to "Custom Policy".Sep 17 2015, 7:09 PM
Maniphest changed the edit policy from "All Users" to "Custom Policy".
Orlodrim updated the task description. (Show Details)
Orlodrim added a project: WMF-NDA.
Orlodrim changed Security from None to Other confidential issue.
Orlodrim edited subscribers, added: Orlodrim; removed: Aklapper.
Krenair changed the visibility from "Custom Policy" to "Custom Policy".
Krenair changed the edit policy from "Custom Policy" to "Custom Policy".
Krenair changed Security from Other confidential issue to Software security bug.

You could add an AbuseFilter warning whenever importScript is added to a .js page, which warns of this issue specifically. You might be able to narrow the regex to look for a colon between ( and ) too.

Unfortunately, javascript can be written and obfuscated many ways, so the only way to know for sure if that function is being called on a title with those specific characteristics would be be to actually emulate or execute the javascript and see if it produces a call to mediawiki that match a request like that.

We could restrict action=raw to only return content with a ctype=text/javascript if the page has a JavaScript content model. ResourceLoader already has that check: https://phabricator.wikimedia.org/diffusion/MW/browse/master/includes/resourceloader/ResourceLoaderWikiModule.php;22c163326fc7ea711332b7ae2870ea802d228b77$156

We could restrict action=raw to only return content with a ctype=text/javascript if the page has a JavaScript content model. ResourceLoader already has that check: https://phabricator.wikimedia.org/diffusion/MW/browse/master/includes/resourceloader/ResourceLoaderWikiModule.php;22c163326fc7ea711332b7ae2870ea802d228b77$156

That would break stuff like https://en.wikipedia.org/wiki/Wikipedia:WikiProject_User_scripts/Scripts/Six_tabs which is fine IMO. Those pages should be moved into the MediaWiki namespace anyways.

We could restrict action=raw to only return content with a ctype=text/javascript if the page has a JavaScript content model. ResourceLoader already has that check: https://phabricator.wikimedia.org/diffusion/MW/browse/master/includes/resourceloader/ResourceLoaderWikiModule.php;22c163326fc7ea711332b7ae2870ea802d228b77$156

Seems reasonable

I opened this three years ago, and the last comment on T113042 says "The first one [this issue] seems hard to fix right now".
If this is no concrete plan to implement a protection against this in MediaWiki, I think it is better at this point to ask a sysop on meta to fix broken scripts (I found 34 affected users in the last dump of metawiki) and use AbuseFilter to catch new errors (at least the simplest cases). Any objections?

We definitely are going to work on this in the very near term (I'll be on vacation next 2 weeks, but after that I plan to work on this issue).

I'm sorry nobody has touched this in the last three years.

That said, I also think its totally fine to let sysops start fixing this too.

Ok, biting the bullet.

Javascript can no longer be loaded from unprotected pages outside of NS_MEDIAWIKI/user js subpage.

Possibly we may follow this up later with further restrictions, but the main restriction is now live

Krinkle closed subtask Restricted Task as Resolved.Aug 6 2022, 12:34 AM

This has been fixed and can be published and closed, right? (cc @sbassett)

sbassett closed this task as Resolved.EditedJul 14 2023, 5:46 PM
sbassett assigned this task to Bawolff.

This has been fixed and can be published and closed, right? (cc @sbassett)

I believe what @Bawolff is referring to in T112937#4623325 is:

https://gerrit.wikimedia.org/r/q/I27e049bae78b5c0f63b10f454b740cb1dc394813

Which was merged/backported in 2018. I think this was a good first step that works as a reasonable solution to this issue. I'd personally like to see far more restrictions around importScript, mw.loader.load and even raw XMLHttpRequests for UserJS/Gadgets, but those can obviously be separate tasks or proposals.

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".Jul 14 2023, 5:46 PM
sbassett changed the edit policy from "Custom Policy" to "All Users".
sbassett removed a subscriber: csteipp.