Page MenuHomePhabricator

Allow CORS from query.wikidata.org to production wikis
Closed, DeclinedPublic

Description

In order to create short URLs for queries, query.wikidata.org needs to be able to send authenticated API requests (action=shortenurl) to some production wiki (Wikidata or Meta would be appropriate, but the config is probably the same for all wikis anyways). This shouldn’t be a security problem because query.wikidata.org only runs trusted JavaScript code.

That said, I’m not sure if the Wikidata Query UI code ever actually went through security review (it seems T105196 only covered the server-side parts), and apparently T108101 explicitly disabled CORS for this domain, so I’m not sure how trivial this request is.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 18 2019, 1:15 PM

Reading https://meta.wikimedia.org/w/api.php?action=help&modules=shortenurl - doesn't seem to require a CSRF token, so I'm not sure that CORS is needed here? (more specifically, you can use the generic origin=* I think).

Although query.wikidata.org is fairly trusted, its still nice to reduce exposure by limiting CORS in places that don't strictly need it.

origin=* makes the request anonymous. Apparently anonymous users are allowed to shorten URLs (subject to a rate limit), but I think it would be nicer to tie the URLs to the user if they’re logged in.

(I’m also surprised at the lack of a CSRF token, but if that’s an issue, it’s outside the scope of this task.)

Moving from email here:

Does the Query Service needs to, in any way, act on the UrlShortener API as the user who is currently logged-in? Trusted or not, that

Well, that was kinda my question from the start. Right now, WDQS UI does not know anything about any users, so if we could keep it this way, it'd be fine with me.
That said, I can see a value in ability of the user to log in and then track the short URLs for the query they are creating. So if it is not too much trouble, may be a nice addition. That said, it is in no way required for the URL shortening in the UI to work, on the contrary - it is currently not a supported mode and will require additional code to support.

is logged-in on the main domain. Given that serving app-tokens to the client-side javascript of the query service would be a problem, this means you'll probably want to make that API request server-side instead. Thus leaving two options:

WDQS UI does not have server side, so that definitely would be a problem.

  • Use the API with auth, as an OAuth user with its credentials and the request made server-side, possibly exposed indirecrtly via wikidata-query's own API.

WDQS UI does not have server side, as I mentioned. While we did plan to add OAuth capabilities for Blazegraph as a module for other reasons (see T179879) it is a very long-term plan and is not something planned for right now.

When WDQS first launched, we intentionally removed it from the CORS whitelist (previously *.wikidata.org was whitelisted IIRC) as a security hardening measure.

I would suggest that WDQS plan to shorten URLs anonymously. Since it's happening client-side (AIUI), it shouldn't run into rate limits unless someone is shortening too many URLs. We should revisit this if it's actually a problem of course, but I don't think we should be weakening our hardening measures for a problem that we don't even know exists.

Smalyshev closed this task as Declined.Apr 15 2019, 6:43 PM

Looks like URL shortener works without it, so we don't need this for now.