See also T109140: Special:UserLogin?returnto=interwiki:foo will redirect to external sites.

I guess the main bad for this would be use in a phishing attack? Anyways:

This would add a splash page anytime there's a redirect to an external interwiki that could be triggered directly from a url (Normal interwiki links where the user has to click, still work like normal).

So the patch causes Special:Search/google:foo to go to Special:GotoInterwiki/google:Foo, where the user is asked if they want to continue. Similarly for returnto parameters (T109140).

The other question is: For urls like /wiki/Google:Foo, should we continue to do Special:BadTitle, or should we also use the splash page for those? This patch leaves them alone for now, but we might want to consider making those use splash page too.

Code review:

• Title::getFullUrlForRedirect could probably just have a single $query argument. $query2 is used in some Title functions for backwards-compatibility only.
• GotoInterwiki is pretty inconsistent as a special page name. Mostly, "goto" is not a real word ;) so I'd rather use GoToInterwiki, or RedirectToInterwiki.
• Repeated typo in code comments: phising → phishing

Version 2: {F3328566}

I forgot to git add one file in version 2. Here's version 3:

I will try to review the patch soon since this has come up related to UrlShortener stuff (not a blocker, but nice to have) - T142068: Possible to circumvent shortening URL list by Special:Search.

Currectly typing words into the wikipedia search box and pressing Enter take users directly to the page. To keep this feature using POST instead of GET for search box may be considered.

In T122209#2521596, @Legoktm wrote:

I will try to review the patch soon since this has come up related to UrlShortener stuff (not a blocker, but nice to have) - T142068: Possible to circumvent shortening URL list by Special:Search.

We were actually just discussing this in the securityteam meeting. Since this issue is relatively low severity, and its kind of a big change (adds a special page) we were planning to allow this to go through normal public review process

Oh, that's even better! I'll take a look once you upload it publicly then.

In T122209#2524162, @Legoktm wrote:

Oh, that's even better! I'll take a look once you upload it publicly then.

Hmm, so patch is a little bit rotted, and being annoying to rebase, I don't think I'll be able to do that tonight, so I probably won't do it for another week as I'm going to be away all next week :(

Rebased patch:

(I applied @Bawolff F3328788 on top of 8aa6c9f43e9b54e4157a5feee42229a9a48b1764, then rebased. Most conflicts looked scary but were actually simple. One interesting one was that the change in SpecialChangePassword now needed to be applied in SpecialChangeCredentials instead.)

Also included @Tgr's fix from T109140 for AuthManager (slightly modified).

This needs to be tested carefully again, since I only fixed the obvious merge errors, and only checked the functionality briefly.

See T109140#2593573.

Can someone add me to T109140?

This is deployed on cluster

Change 346839 merged by jenkins-bot:
[mediawiki/core@master] SECURITY: Do not directly redirect to interwikis, but use splash page

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

Change 346848 merged by jenkins-bot:
[mediawiki/core@REL1_27] SECURITY: Do not directly redirect to interwikis, but use splash page

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

Change 346858 merged by jenkins-bot:
[mediawiki/core@REL1_28] SECURITY: Do not directly redirect to interwikis, but use splash page

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

Change 347018 had a related patch set uploaded (by Chad; owner: Brian Wolff):
[mediawiki/core@wmf/1.29.0-wmf.19] SECURITY: Do not directly redirect to interwikis, but use splash page

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

Change 347018 merged by jenkins-bot:
[mediawiki/core@wmf/1.29.0-wmf.19] SECURITY: Do not directly redirect to interwikis, but use splash page

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