You can pull off this kind of attack with any common URL shortener, so I don't think it's worth having w.wiki forbid usage of the withJS parameter, which does have plenty of legitimate uses that merit URL shortening.

If you were an attacker with IA access on tinywiki.wiktionary.org with the ability to get away with creating obfuscated JS in the MediaWiki namespace, you could turn your payload into a default gadget or stick it in Common.js, etc. And then link directly to the wiki, no withJS or even URL shortener needed.

Is there something I'm missing?

I agree with Lego, This was in my mind when I was deploying url shortener but given the separation of IA and general admin rights (that happened a couple years ago) this is not a big of vector. Most importantly, if someone could take over IA rights in a small or medium wiki, there is a bigger problem (compromise of accounts large number of people, large-scale disruption and so on) than specific users could potentially be targeted via w.wiki. A proper solution to this is to strengthen security of small wikis via strong policies on IA [1] rather than hiding the actual problem under the rug.

[1]: Some ideas: we don't allow indef admins in lots of wikis anymore, we could simply ban IA rights on small wikis and make them request changes via global interface admins, similar to CU). Given the potential of bad actors compromising PII on wikis, I think it's sensible. It's not even bad actors getting rights, it's the higher chance of the admin account getting compromised for such attacks.

Perhaps we could add a way to see what the target would be, before actually proceeding? Like https://meta.wikimedia.org/wiki/Special:UrlShortener/d showing the target of w.wiki/d ?

In T333723#8749093, @Legoktm wrote:

Is there something I'm missing?

Primarily the potential for spoofing. In the other attack you describe, the hypothetical enwiki admin knows they're visiting tinywiki.wiktionary.org, a site they probably have no intention of ever editing. But if they click on a link that they're told will take them to enwiki, and the link has the w.wiki implied certificate of authenticity, and then they're now on a website that looks just like enwiki, there's a greater chance of them taking the bait. Put simply: IAs can only affect their own wikis, but this vulnerability lets their wiki be any wiki.

In T333723#8757593, @Tamzin wrote:

Primarily the potential for spoofing. In the other attack you describe, the hypothetical enwiki admin knows they're visiting tinywiki.wiktionary.org, a site they probably have no intention of ever editing. But if they click on a link that they're told will take them to enwiki, and the link has the w.wiki implied certificate of authenticity, and then they're now on a website that looks just like enwiki, there's a greater chance of them taking the bait.

I mean... https://en.wikipedia.org/wiki/wikt:zh:Foo?withJs=pwned ?

Put simply: IAs can only affect their own wikis, but this vulnerability lets their wiki be any wiki.

I would not consider the first part of your statement to be true. There are enough SWMT, global sysops, stewards, etc. that are regularly visiting small wikis that any IA effectively can attack any wiki.

In T333723#8755082, @DannyS712 wrote:

Perhaps we could add a way to see what the target would be, before actually proceeding? Like https://meta.wikimedia.org/wiki/Special:UrlShortener/d showing the target of w.wiki/d ?

Sure. Special:UrlExpander I suppose :)

I'd agree with the idea that int-admins are already highly-trusted users and that considering a possible exploit like this really starts heading down a slippery slope of not allowing any advanced user rights since any account could theoretically be compromised or have the user go rogue, thus enabling plenty of forms of on-wiki damage. There's a real question here of how feasibly-protective we can be for issues like this.

In T333723#8755082, @DannyS712 wrote:

Perhaps we could add a way to see what the target would be, before actually proceeding? Like https://meta.wikimedia.org/wiki/Special:UrlShortener/d showing the target of w.wiki/d ?

This sounds a bit cumbersome, but could certainly work for highly-concerned users. We could even have it flag URLs with withJS= as a query param and throw an additional warning message. But I think that's about the most something like this should do.

In T333723#8759465, @sbassett wrote:

In T333723#8755082, @DannyS712 wrote:

Perhaps we could add a way to see what the target would be, before actually proceeding? Like https://meta.wikimedia.org/wiki/Special:UrlShortener/d showing the target of w.wiki/d ?

This sounds a bit cumbersome, but could certainly work for highly-concerned users. We could even have it flag URLs with withJS= as a query param and throw an additional warning message. But I think that's about the most something like this should do.

It's still possible to check a redirect chain via curl without sharing any creds (or even tell it not to follow redirects and read the 302 response). It's a bit more cumbersome but not that much.

FWIW bitly has a feature where you add a "+" to the end of the URL and it sends you to an interstitial instead of directly redirecting. E.g. https://bit.ly/3nS07lI vs https://bit.ly/3nS07lI+ - so I think it's a reasonable feature to add to a URL shortener. But maybe we can move that to a public ticket?

Hi - this task will be made public soon.