The Wikidata Query GUI allows users to build links with arbitrary, innocuous-looking link text and a javascript: URL, potentially allowing code execution when another user clicks the link: example query.
In T297570#7568944, I observed that the query UI already generates links with arbitrary HREFs as long as they’re returned by the query service, which can either come from Wikidata or just be created directly in the query, for example:
SELECT (<javascript:alert('hi')> AS ?url) {}
This generates a results table like this:
| url |
|---|
| <javascript:alert('hi')> |
Except that the link is clickable, which Phabricator doesn’t allow. I thought that this was not a catastrophic issue, since the URL is visible, and users hopefully won’t click it if it looks suspicious. But then I realized that we sometimes create links with custom link text, e.g. when we encounter a variable together with an associated label variable, in some result views:
#defaultView:Map SELECT (<javascript:alert('hi')> AS ?item) ("hi"@en AS ?itemLabel) ("Point(0 0)"^^geo:wktLiteral AS ?coordinates) {}
Try it!
If you run this query (or directly go to the embed link) and click the red dot, you see something like this:
<a title="item" href="javascript:alert('hi')" target="_blank" class="item-link" rel="noopener">hi</a>
This link may execute JavaScript if a user clicks it; thanks to the custom link text, they don’t really have any reason not to click it.
In my testing, the impact of this seems to be mitigated by the target=_blank, though. A simple click on the link opens javascript:alert('hi') in a new tab, apparently without running the JavaScript; a shift-click opens a new window on a blank tab, and the JavaScript runs (the alert is shown), but it does not seem to run on query.wikidata.org: changing the code to alert(document.location) shows about:blank.
Also, note that query.wikidata.org is not on the CORS allowlist (with each issue I discover I’m more and more glad that T218568 was declined).