When you use a root article path, for [[/example.com]] getLocalURL will combine the "/$1" and "/example.com" together and return //example.com. This triggers a browser's protocol-relative handling instead of acting as a relative url. As long as you create an article at [[/example.com]] so that a live link shows up instead of an edit link links like [[/example.com|Example]] will end up as <a href="//example.com">Example</a>. Naturally this means you can abuse this to link to other websites bypassing nofollow. Additionally doing this will also cause Special:Random to randomly send users to other websites instead of pages on the wiki when one of the [[/...]] articles is randomly picked.
Description
Description
Details
Details
- Reference
- bz38048
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T34620 Support for root /Foo style pretty urls | |||
| Open | None | T40048 Root article paths allow creating local-like links to external sites (bypass nofollow, attacks Special:Random) |
Event Timeline
Comment Actions
Sigh. :)
Ideally, initial-slash would probably be forbidden from full titles... but we do have some in use on Wikipedia such as [[/]] and /me (at least as redirects).
Should consider the pluses/minuses of blacklisting em.
Comment Actions
Oh right, solution.
My thought was that we should tweak getLocalURL so that when a path starts with / and a root article path is used getLocalURL returns an index.php url instead of an article path url.
Comment Actions
The redirect surprises me, that should be an absolute url including host and protocol (with Vary header for protocol if needed).
Comment Actions
(In reply to comment #3)
The redirect surprises me, that should be an absolute url including host and
protocol (with Vary header for protocol if needed).
I have a feeling that's because we use wfExpandURL.
Comment Actions
(In reply to comment #4)
(In reply to comment #3)
The redirect surprises me, that should be an absolute url including host and
protocol (with Vary header for protocol if needed).I have a feeling that's because we use wfExpandURL.
Ah, right. It sees //Pagename.
Comment Actions
I think in this case
wfUrlencode("/example.com") should return "%2Fexample.com", not "/example.com".
Comment Actions
(In reply to comment #7)
I think in this case
wfUrlencode("/example.com") should return "%2Fexample.com", not
"/example.com".
We don't need to hack wfUrlencode to fix this bug. wfUrlencode is used in places other than just the root where such a hack is excessive.