Related bug: https://jira.toolserver.org/browse/MAGNUS-327

https://toolserver.org/~magnus/file_siblings.php is vulnerable against JavaScript injection via uselang:

https://toolserver.org/~magnus/file_siblings.php?language=commons&project=wikimedia&file=Magnify-clip.png&sort_by_date=0&sib_cat=1&sib_gal=1&mode=html&message=&doit=Do+it!&uselang=en%27+onmouseover%3D%22alert%28%27XSS%27%29%22+title%3D%27

The gadget https://de.wikipedia.org/wiki/MediaWiki:Gadget-ImageSiblings.js
includes this page and has the same vulnerability:

https://de.wikipedia.org/wiki/Datei:Magnify-clip.png?uselang=en%27+onmouseover%3D%22alert%28%27XSS%27%29%22+title%3D%27

BCP 47 writes in: https://tools.ietf.org/html/bcp47#section-7

language tags use only the characters A-Z, a-z, 0-9, and HYPHEN-MINUS

This should be the only allowed characters.

Fomafix,

Thanks for reporting this too! I've been out on leave for a the last two weeks, so apologies for the slow response.

I see exactly what you mean and yes, that is bad. We need to figure out the best place to put in the fix for this, but we will get it addressed asap.

The uselang attribute commonly contains punctuation characters that aren't allowed by BCP-47, due to the {{int:}} hack commonly used on multilanguage wikis. Only the minimum set of characters required for security should be rejected, plus the ones rejected by Language::isValidCode().

(In reply to comment #4)

The uselang attribute commonly contains punctuation characters that aren't
allowed by BCP-47

Such as? I thought it was only used for things like en-upload-ownwork. But always within BCP-47, in general even structer (never numbers or uppercase even).

Working with Tim on this yesterday, he pulled a list of all of the uselang values that hit WMF sites from the cache (http://paste.tstarling.com/p/qzhZBz.html). There were several obvious attack strings, and some that looked like they probably were errors. Almost all the rest were a-zA-Z0-9.-+ characters, with a few ?, =, and ncr-encoded characters where it was hard to figure out if they were errors or intentional.

From a security perspective, I think we should at least implement Nikerabbits patch now and if anyone was intentionally using ', ", or &, we can work with the site admins to get those cleaned up. Then we can later look at whitelisting [a-zA-Z+.-] only.

With the rollout of wmf8 today on de.wikipedia.org, the particular issues reported by fomafix appears to be resolved. Thanks everyone!