Last modified: 2011-03-13 18:05:52 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 7664 - Creation of external links with literal non-routable IP addresses should be blocked
Creation of external links with literal non-routable IP addresses should be b...
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Lowest normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-22 10:16 UTC by Neil Harris
Modified: 2011-03-13 18:05 UTC (History)
2 users (show)

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


Attachments

Description Neil Harris 2006-10-22 10:16:01 UTC
It should not be possible to make the MediaWiki software render links of any
sort to literal loopback, RFC1918, or zeroconf IP addresses from within the
Wikipedia software, since these 

a) cannot possibly benefit Wikipedia, since they are not publically routable,
and thus can never link to any publicly-available resource

b) could potentially be used for cross-site request attacks on badly-programmed
network devices or host-local services which accept commands to their Web-based
control interfaces via HTTP GET at well-known IP addresses (for examples ADSL
routers, printers)

This should be the default for Wikimedia sites: I can think of some valid uses
for this within private MediaWiki sites, so perhaps this feature should be
controlled by a site-settable option.

This can be achieved by preventing links being created for URLs with the
following regexp patterns

[a-z]+://127\.[0-9]+\.[0-9]+\.[0-9:]+
[a-z]+://127\.[0-9]+\.[0-9]+\.[0-9:]+/.*
[a-z]+://10\.[0-9]+\.[0-9]+\.[0-9:]+
[a-z]+://10\.[0-9]+\.[0-9]+\.[0-9:]+/.*
[a-z]+://172\.[12][0-9]\.[0-9]+\.[0-9:]+
[a-z]+://172\.[12][0-9]\.[0-9]+\.[0-9:]+/.*
[a-z]+://172\.3[01]\.[0-9]+\.[0-9:]+
[a-z]+://172\.3[01]\.[0-9]+\.[0-9:]+/.*
[a-z]+://192\.168\.[0-9]+\.[0-9:]+
[a-z]+://192\.168\.[0-9]+\.[0-9:]+/.*
[a-z]+://169\.254\.[0-9]+\.[0-9:]+
[a-z]+://169\.254\.[0-9]+\.[0-9:]+/.*
Comment 1 Neil Harris 2006-10-22 10:28:52 UTC
When impementing this, it also would make sense to block all-numberic IP address
representations in URLs, since 

a) they are a historic relic of browser implementation that is now only ever
used to maliciously obfuscate IP addresses.

b) they could potentially be used to get around the blocks above, by obfuscating
the various non-routable addresses above

These can be blocked with the following regexps:

[a-z]+://[0-9]+
[a-z]+://[0-9]+/.*
Comment 2 Neil Harris 2006-10-22 10:29:54 UTC
IPv6 loopback and link-local addresses should also be blocked: but they are far
less of a threat than the above, due to the lack of deployment of IPv6 
Comment 3 Neil Harris 2006-10-22 10:33:52 UTC
Correction to comment #1:

Those regexps do not take into account port numbers, they should be

[a-z]+://[0-9]+:?[0-9]*
[a-z]+://[0-9]+:?[0-9]*/.*

instead of the versions given in comment #1. (Note that only addresses with zero
or one colons are blocked: this is to prevent the blocking of literal IPv6
addresses).
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-10-22 21:57:13 UTC
How many such links already exist on WMF projects?  It would be a bad idea to
break a ton of links.
Comment 5 Brion Vibber 2006-10-24 12:04:07 UTC
I tend to be skeptical, but perhaps there would be some reason to do this.

Whole-URL regexes probably aren't the best place though; would be cleabner to check within the url normalizaiton.
Comment 6 Andrew Garrett 2006-10-25 08:23:13 UTC
What about internal company wikis? This needs to be an on/off switch feature.
Comment 7 Neil Harris 2006-10-26 23:18:25 UTC
See the bug description, where I explicitly mentioned this. 

Another approach to the same problem might be to put these regexps into the
existing spam blocker list, in which case there should be no need to add this to
the software as an explicit feature, although this would mean that a full scan
of the entire database would be needed to root out any old copies of such URLs
that are already in the wiki.
Comment 8 Aaron Schulz 2008-09-16 16:39:24 UTC
(In reply to comment #5)
> I tend to be skeptical, but perhaps there would be some reason to do this.
> 
> Whole-URL regexes probably aren't the best place though; would be cleabner to check within the url normalizaiton.

I don't see the use for this. Just more overhead.
Comment 9 Juliano F. Ravasi 2008-09-16 19:05:27 UTC
It is also completely pointless. A perfect example of security got completely wrong.

See, for example:
http://example.gotdns.org/

I just created this hostname that points to 192.168.1.100 (the address used by several home ADSL modems) in a few seconds using a free DNS hosting service in the internet. How would MediaWiki possibly detect such address as local?

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


Navigation
Links