CVE-2023-22911: ⚓ T149488 E:Widgets does widget replacement in html attributes potentially leading to XSS

**

E:Widgets does widget replacement in html attributes potentially leading to XSS

**

• Edit Task

• Edit Related Tasks…

• Edit Related Objects…

• Mute Notifications

• Protect as security issue

• Award Token

• Flag For Later

This can lead to security issues because most widget authors do not expect their widget to be executed in an html attribute context.

For example, consider the following wikitext :

<div title="{{#widget:UStreamLive|width=onmouseover=alert(1);//}}">

executed at http://www.mediawikiwidgets.org/Special:ExpandTemplates . It executes arbitrary js whenever your mouse goes over the widget.

• Mentions

Event Timeline

Comment Actions

p.s. If this used MW’s builtin StripMarker support, this would be taken care of automatically.

Comment Actions

I do not have a clue what to do about this and since Yaron does not seem to have a clue either I guess we are stuck here.

Comment Actions

So interestingly, https://minecraft.gamepedia.com/Template:Sprite seems to intentionally (or maybe accidentally) use this behaviour to bypass MediaWiki’s CSS sanitization.

The template makes a span that has a background-image css property. Normally, url() in css would be stripped. It looks like because widgets are replaced after CSS sanitization, it bypasses MediaWiki’s builtin CSS sanitization. (Which on a scale of badness, isn’t too bad. At worst it allows some privacy leaks, possibly allows an attacker to associate usernames and ip addresses.). But its interesting.

Comment Actions

I do not have a clue what to do about this and since Yaron does not seem to have a clue either I guess we are stuck here.

Hi. Sorry i didn’t give much context.

Easiest fix, change WidgetRenderer::$markerPrefix to be something like “START_WIDGET\"’” (edit: to clarify, that fixes the situation, since if thr marker prefix has ' and " in it they will get escaped anywhere that those characters aren’t allowed like attributes. Thus preventing the replacement if its potentially dangerous) However, that would likely break some use cases (basically any time someone uses the result of a widget inside an attribute).

I’m not sure of a way to fix this off the top of my head, well still working inside attributes (If that is important). It would probably require something much more complicated

Comment Actions

With @Bawolff’s patch merged, can we resolve and make this task public now? I don’t believe this implicates Wikimedia production in any way.

sbassett lowered the priority of this task from High to Low.

sbassett changed the visibility from “Custom Policy” to "Public (No Login Required)".

Comment Actions

@Bawolff Any chance to get this backported at least to MW 1.39 since this one is no longer an extension with tags? Will be cool if possible.

Content licensed under Creative Commons Attribution-ShareAlike 3.0 (CC-BY-SA) unless otherwise noted; code licensed under GNU General Public License (GPL) or other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL