CVE-2021-45472: ⚓ T297570 XSS in Wikibase using formatter URL

**

XSS in Wikibase using formatter URL

Closed, ResolvedPublicSecurity

**

• Edit Task

• Edit Related Tasks…

• Edit Related Objects…

• Mute Notifications

• Protect as security issue

• Award Token

• Flag For Later

Users can specify a URL format in an external identifier property using a formatter URL with a string like “https://viaf.org/viaf/$1” and then use the external identifier property in an item to substitute a string into the URL. However there seems to be no protocol validation, meaning users can use a string like “javascript:alert() //$1” to execute javascript when the URL is clicked.

Risk Rating

Low

Author Affiliation

Wikimedia Communities

• Task Graph

Event Timeline

Comment Actions

Someone seems to have noticed this before me as you can see at https://test.wikidata.org/wiki/Property:P95266. So either this is a duplicate task or it just wasn’t reported, or it’s some sort of regression.

We get a lot of folks who play around/test things out on live wikis. Given the author’s history, I doubt this was at all intentionally malicious, though it might not be a terrible idea to delete/os that wikidata item just to be safe, in that it actively points any would-be attacker in the correct direction here.

Also, specifically adding a few WMDE folks here for additional attention.

Comment Actions

I made myself oversighter (let me know if I should !log that, I wasn’t sure) and deleted the property. I hope that doesn’t generate a notification to the user, though even if it does, they hopefully won’t remember what the property was (given that it was created in February 2020; I didn’t put any details in the log message).

Comment Actions

Looks like the only currently used protocols (on Wikidata) are https (4650 times), http (1829), tel (2), and httsp (1, clearly a typo). We allow some more protocols in URL values (e.g. email; UrlSchemeValidators::getValidator() has a fairly long list), but it looks like those aren’t used in formatter URLs at the moment, so let’s limit those to https, http and tel for now. (And by “limit”, I mean that we just don’t use the formatter URL if it uses another property, though we won’t block anyone from saving it.)

TODO: Also look into formatter URI for RDF resource.

Comment Actions

Proposed patch:

I haven’t yet been able to reproduce this issue locally – I think formatter URLs have some weird caching.

Comment Actions

As far as I can tell, the ExternalIdentifierRdfBuilder has the same problem, i.e. we might emit javascript: “URIs” in our RDF output. (I’ve been able to reproduce this locally, too – note that the property must have the datatype external-id.) I’m not sure if that’s considered a security issue? I don’t think we make these URIs clickable anywhere on wikidata.org; on query.wikidata.org, users can build arbitrary URIs anyways (example).

Comment Actions

Proposed patch:

I haven’t yet been able to reproduce this issue locally – I think formatter URLs have some weird caching.

I have been able to reproduce it locally now and the patch seems to fix it. (It looks like turning the property into an external-id one was required – I thought we also supported formatter URLs on the string type, but I might’ve been wrong. Try running php extensions/Wikibase/repo/maintenance/changePropertyDataType.php --new-data-type external-id --property-id P___, or just make sure your test property ID for this task has datatype external identifier to begin with.)

Comment Actions

Someone seems to have noticed this before me as you can see at https://test.wikidata.org/wiki/Property:P95266. So either this is a duplicate task or it just wasn’t reported, or it’s some sort of regression.

We get a lot of folks who play around/test things out on live wikis. Given the author’s history, I doubt this was at all intentionally malicious, though it might not be a terrible idea to delete/os that wikidata item just to be safe, in that it actively points any would-be attacker in the correct direction here.

The user in question is @Bugreporter on Phabricator, by the way, if anyone wants to check if they created any security tasks which this might be a duplicate of. (I’m not in acl*security, so I can’t check myself.)

Comment Actions

Deployed to wmf.9 and .12, and notified @hashar for wmf.13 coordination. Bug no longer occurs on Special:Undelete for that property, where it had previously still been reproducible. (Note: requires oversighter rights to see.)

Thanks, I’ve updated T276237 and T292236.

The user in question is @Bugreporter on Phabricator, by the way, if anyone wants to check if they created any security tasks which this might be a duplicate of. (I’m not in acl*security, so I can’t check myself.)

Subbing them to see if they remember (I view this action as very low-risk in the context of this bug).

sbassett changed the task status from Open to In Progress.Tue, Dec 14, 7:07 PM

sbassett triaged this task as Low priority.

sbassett changed Author Affiliation from N/A to Wikimedia Communities.

sbassett changed Risk Rating from N/A to Low.

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