What's the completely unacceptable part? You're discussing the difference between https://w.wiki/foo redirecting to https://tools.wmflabs.org versus having a regular hyperlink to https://tools.wmflabs.org on any of our sites?

For example: https://w.wiki/foo -> https://www.mediawiki.org/wiki/Special:Search/toollabs:abcd -> https://tools.wmflabs.org/abcd (-> http://tinyurl.com/qwert12345) -> http://somesite-with-malware.com

This may also be a problem of Special pages as users may use this to circumvent spam blacklist.

Possible solution:

1. Show a page with "You are redirected to a non-Wikimedia site. This site may contain malware or other inappropriate content." when using Special:Search with non-forwarded interwiki prefixes
2. Use POST instead of GET for search box when JavaScript enabled (as this can also be circumvented by https://www.mediawiki.org/w/index.php?search=google:&title=Special%3ASearch&go=Go)

In T142068#2521527, @Bugreporter wrote:

For example: https://w.wiki/foo -> https://www.mediawiki.org/wiki/Special:Search/toollabs:abcd -> https://tools.wmflabs.org/abcd (-> http://tinyurl.com/qwert12345) -> http://somesite-with-malware.com

Right. The new part here seems to be that you can have a "w.wiki" short URL. Is that correct? If so, is that really so different from a user putting a regular hyperlink such as https://tools.wmflabs.org/abcd on a wiki page for users to click? It seems like we're only talking about a single extra hop.

Vaguely related: https://en.wikipedia.org/wiki/User_talk:MZMcBride/Archive_18#Your_template_wizardy_required and https://en.wikipedia.org/wiki/User_talk:MZMcBride/Archive_27#Tool_Questions.

Currently URLs such as https://www.mediawiki.org/wiki/Special:Search/google:Foo give a response similar to this:

$ curl -I "https://www.mediawiki.org/wiki/Special:Search/google:Foo"
HTTP/1.1 302 Found
Date: Thu, 04 Aug 2016 06:06:43 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Server: mw1213.eqiad.wmnet
X-Powered-By: HHVM/3.12.1
X-Content-Type-Options: nosniff
P3P: CP="This is not a P3P policy! See https://www.mediawiki.org/wiki/Special:CentralAutoLogin/P3P for more info."
Vary: Accept-Encoding,X-Forwarded-Proto,Cookie,Authorization
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Location: https://www.google.com/search?q=Foo
Backend-Timing: D=36893 t=1470290803175909
X-Varnish: 1282349625, 313197216
Via: 1.1 varnish, 1.1 varnish
Accept-Ranges: bytes
Age: 0
X-Cache: cp1067 pass, cp1052 pass
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Set-Cookie: WMF-Last-Access=04-Aug-2016;Path=/;HttpOnly;secure;Expires=Mon, 05 Sep 2016 00:00:00 GMT
X-Analytics: https=1;nocookies=1
X-Client-IP: 2601:146:c902:86af:9158:42c4:bc4b:41c
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Set-Cookie: GeoIP=:::::v6; Path=/; secure; Domain=.mediawiki.org

We could check that the target URL is HTTP 200 (i.e., not HTTP 301 or HTTP 302), but implementing such a check may create its own set of challenges.

The shortening URL list is useless if you can make short URL which are eventually redirected to arbitrary site.

I would kindly ask that if you think you've found a vulnerability in a *deployed* extension, that you file it as a security bug.

@Legoktm Can you let me subscribe that task? I want to find what things happen.

Also I have filed another task about circumventing shortening URL list (also security bug), named T142071: Disable Forward to non-WMF sites in interwiki data

In T142068#2521591, @Legoktm wrote:

T122209: Special:Search allows redirects to any interwiki link tracks fixing the external redirect stuff, so I'm going to close this as declined, but leave it private until that one becomes public.

The other task is public now, going to unseal this one given it is about the same thing.