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.

In T297570#7567708, @Dylsss wrote:

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.

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).

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.

Proposed patch:

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

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).

In T297570#7568892, @Lucas_Werkmeister_WMDE wrote:

Proposed patch:

T297570.patch2 KBDownload

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.)

Reproduced locally. I verified T297570#7568892 and it looks good to me!

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.)

In T297570#7567756, @sbassett wrote:

In T297570#7567708, @Dylsss wrote:

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.)

In T297570#7569403, @Lucas_Werkmeister_WMDE wrote:

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).

Change 748072 had a related patch set uploaded (by Tobias Andersson; author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@REL1_37] SECURITY: Ignore formatter URLs with bad protocol

https://gerrit.wikimedia.org/r/748072

Change 748073 had a related patch set uploaded (by Tobias Andersson; author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@REL1_36] SECURITY: Ignore formatter URLs with bad protocol

https://gerrit.wikimedia.org/r/748073

Change 748072 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@REL1_37] SECURITY: Ignore formatter URLs with bad protocol

https://gerrit.wikimedia.org/r/748072

Change 748073 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@REL1_36] SECURITY: Ignore formatter URLs with bad protocol

https://gerrit.wikimedia.org/r/748073