GET requests to the MediaWiki API on Wikimedia wikis get silently redirected from HTTP to HTTPS. This is insecure because the application seems to just work, but requests are initially sent in clear - it's better to make such requests fail loudly. There has been plenty of time for legacy tools to adapt.
(Might apply to other APIs also, haven't checked.)
The specific issue where this came up was T247474: Unable to get edit token - invalid signature in authorization header.
Yeah this is an interesting angle on things. Currently for all traffic to canonical domains, we redirect GETs and HEADs, but we return a 403 error for POST, as shown in this VCL code block:
// *** HTTPS-forcing recv code
sub https_recv_redirect {
if (req.http.X-Forwarded-Proto != "https") {
if (req.method == "GET" || req.method == "HEAD") {
set req.http.Location = "https://" + req.http.Host + req.url;
return (synth(301, "TLS Redirect"));
} else {
return (synth(403, "Insecure Request Forbidden - use HTTPS - https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-May/000110.html"));
}
}
}I could see a pretty strong argument that we should give the 403 treatment to GET/HEAD which contain sensitive info like authorization headers and session cookies, perhaps universally and not just for a particular API. There might be some fallout for some users, and we might want to investigate the incidence rate of this and what projects/domains it mostly happens on first?
The swap of Traffic for Traffic-Icebox in this ticket's set of tags was based on a bulk action for all such tickets that haven't been updated in 6 months or more. This does not imply any human judgement about the validity or importance of the task, and is simply the first step in a larger task cleanup effort. Further manual triage and/or requests for updates will happen this month for all such tickets. For more detail, have a look at the extended explanation on the main page of Traffic-Icebox . Thank you!