Summary
There are several sources of arbitrary, unescaped user input being used to construct HTML, which allows any user that can edit pages or otherwise render wikitext to XSS other users.
Edit: Only the first XSS can be reproduced in production.
Details
✅ Verified and patched in f229cab
|
$tabBody = sprintf( '<div class="error">Invalid title: %s</div>', $pageName ); |
This doesn't escape the user-supplied page name when outputting, so an XSS payload as the page name can be used here.
This was caused by d8c3db4.
❌ Invalid as MediaWiki parser sanitizes dangerous HTML
|
return $parser->recursiveTagParse( $content, $frame ); |
The documentation for
Parser::recursiveTagParse() states that it returns unsafe HTML, and the
$content being supplied is from user input.
This was caused by 9535181.
❌ Invalid as TabberParsoid is not being used
|
return '<article class="tabber__panel" title="' . $tabName . |
This uses unescaped user input as the attribute of an element, thus allowing the user to break out of the attribute or element and injecting arbitrary attributes to the element, or inserting new ones (such as a script tag).
This was caused by 8278e66.
PoC
For the first XSS, render the following wikitext (whether it be through saving it to a page and viewing it, or via Special:ExpandTemplates):
<tabbertransclude>
<script>alert(1)</script> | hehe
</tabbertransclude>
For the second XSS, I have given up attempting to reproduce it after over twenty minutes of "surfing through the internals of the MediaWiki parser fishing for an XSS out of this giant contraption as I bring myself deeper and deeper into the cogs of the machine that no one knows how to maintain or fully operate ever since its conception".
For the third XSS, this is unreachable as the class is never used, though it should be fixed anyway (or the file removed).
Impact
Any user with the ability to cause another user to render wikitext (such as viewing a page that the user can edit, or an attacker tricking the victim to click on a link to Special:ExpandTemplates with the malicious wikitext in the wpInput parameter) can XSS said user.
BlankEclair Reporter
Summary
There are several sources of arbitrary, unescaped user input being used to construct HTML, which allows any user that can edit pages or otherwise render wikitext to XSS other users.
Details
mediawiki-extensions-TabberNeue/includes/TabberTransclude.php
Line 154 in 2526daa
This doesn't escape the user-supplied page name when outputting, so an XSS payload as the page name can be used here.
This was caused by d8c3db4.
mediawiki-extensions-TabberNeue/includes/Tabber.php
Line 160 in 2526daa
The documentation for
Parser::recursiveTagParse()states that it returns unsafe HTML, and the$contentbeing supplied is from user input.This was caused by 9535181.
mediawiki-extensions-TabberNeue/includes/TabberParsoid.php
Line 96 in 2526daa
This uses unescaped user input as the attribute of an element, thus allowing the user to break out of the attribute or element and injecting arbitrary attributes to the element, or inserting new ones (such as a script tag).
This was caused by 8278e66.
PoC
For the first XSS, render the following wikitext (whether it be through saving it to a page and viewing it, or via Special:ExpandTemplates):
For the second XSS, I have given up attempting to reproduce it after over twenty minutes of "surfing through the internals of the MediaWiki parser fishing for an XSS out of this giant contraption as I bring myself deeper and deeper into the cogs of the machine that no one knows how to maintain or fully operate ever since its conception".
For the third XSS, this is unreachable as the class is never used, though it should be fixed anyway (or the file removed).
Impact
Any user with the ability to cause another user to render wikitext (such as viewing a page that the user can edit, or an attacker tricking the victim to click on a link to Special:ExpandTemplates with the malicious wikitext in the
wpInputparameter) can XSS said user.