Change to Html escaping method
If the language is set to a language with variants (e.g. zh, sr, etc), then its possible to create an XSS if some other code allows user input to be put in an attribute using the escaping done by Html::element (or Html::rawElement).
Example exploit code:
1. Set $wgLanguageCode = 'zh'; $wgDefaultLanguageVariant = 'zh-cn'; (Assuming you don't have a different default variant set in prefs)
Create a page with the following wikitext:
-{H|abc123=>zh-cn:" autofocus onfocus="alert('be evil');}-
{{Special:Contributions|target=>abc123}}
And you have your XSS. I imagine there's probably less obvious ways to exploit this once you take into all the extensions using Html:: for their escaping. The $wgDefaultLanguageVariant isn't really necessary as you can set the variant from the url.
If $wgWellFormedXml is off, I believe it becomes possible to directly insert a <script> tag instead of relying on event handlers (but haven't tested).
Solutions:
The fact that language converter basically does macro expansions after the html sanitization step, is pretty sketchy. But I'm not sure if there's a good way around that without redesigning the feature.
I would suggest fixing this by getting rid of the little weird tricks that Html::expandAttributes does. Well its cute that technically one doesn't need to escape that in that context, cute things like that seem like a bad idea in security critical code. (A similar thing occurs in the escaping of Html::element, however I don't think that is exploitable).
--------------------------
**Version**: unspecified
**Severity**: normal
**Patch**: {F99618} (fix the attack vectors, we'll address the root of the issue in a public patch)
- 1.24: (needed)
- 1.23: (needed)
- 1.19: (needed)
**Affected Versions**: Since f16d1e4ed70cd5a8fa6ae6ca8bb71bfe62f4f47e (1.17?)
**Type**: xss
**CVE**: (needed)