Last modified: 2013-10-04 00:29:37 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T40048, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 38048 - Root article paths allow bypassing of nofollow and attacks on Special:Random
Root article paths allow bypassing of nofollow and attacks on Special:Random
Status: NEW
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal major (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 54950
Blocks: 32620
  Show dependency treegraph
 
Reported: 2012-06-28 21:59 UTC by Daniel Friesen
Modified: 2013-10-04 00:29 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Daniel Friesen 2012-06-28 21:59:13 UTC
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.
Comment 1 Brion Vibber 2012-06-28 22:04:40 UTC
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 2 Daniel Friesen 2012-06-28 22:15:37 UTC
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 3 Krinkle 2012-06-28 22:25:53 UTC
The redirect surprises me, that should be an absolute url including host and protocol (with Vary header for protocol if needed).
Comment 4 Daniel Friesen 2012-06-28 22:44:16 UTC
(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 5 Krinkle 2012-06-28 23:06:52 UTC
(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 6 Matthew Flaschen 2013-09-20 00:20:27 UTC
This seems pretty serious, bumping it up one.
Comment 7 Marcin Cieślak 2013-10-03 23:12:19 UTC
I think in this case 

wfUrlencode("/example.com") should return "%2Fexample.com", not "/example.com".
Comment 8 Daniel Friesen 2013-10-04 00:29:37 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links