Closed
Bug 877119
Opened 12 years ago
Closed 11 years ago
wiki.mozilla.org discloses internal IP
Categories
(Websites :: wiki.mozilla.org, defect)
Websites
wiki.mozilla.org
Tracking
(Not tracked)
RESOLVED
FIXED
2014-Q1
People
(Reporter: ldeller, Assigned: jd)
Details
Attachments
(1 file)
1.96 KB,
application/octet-stream
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
Steps to reproduce:
I registered a new account on wiki.mozilla.org
Actual results:
I received an email which began:
Someone, probably you, from IP address 10.8.81.216,
has registered an account "Luked" with this email address on MozillaWiki.
Expected results:
That IP address which is internal to your network should not have been disclosed to me. My own presenting IP address should have been shown instead, which starts with 110.33.
Comment 1•12 years ago
|
||
This probably means $wgUsePrivateIPs and $wgSquidServersNoPurge need to be set. I'll need a list of the IPs if there are more than the one listed here.
https://www.mediawiki.org/wiki/Manual:$wgUsePrivateIPs
https://www.mediawiki.org/wiki/Manual:$wgSquidServersNoPurge
Assignee | ||
Comment 2•12 years ago
|
||
From the config file
$wgUseSquid = true;
$wgSquidServers = array('10.8.81.215','10.8.81.216','10.8.81.217','10.8.81.218','10.8.81.219');
Let me know if this is not the information you need and what I need to do to correct the issue. From looking at the links you posted I am not sure what purge will do.
Thanks
Assignee: nobody → jcrowe
Flags: needinfo?(mah)
QA Contact: nmaul
Comment 3•12 years ago
|
||
k, settings look correct, but I was able to reproduce this. Could you confirm that the wiki does get X-Forwarded-For IPs for the proxy?
Flags: needinfo?(mah)
Assignee | ||
Comment 4•12 years ago
|
||
Due to a stupid decision to be unique like a snowflake, and back when they were Zeus the makers decided to create 'X-Cluster-Client-Ip' instead of using 'X-Forwarded-For' for the client IP header (they wanted to make sure no one could simply switch to Varnish IMHO).
There are two solutions, the first is to change the app to use the snowflake header (I do not know if this is possible in MW). The second is that I can add a traffic rule to the load balancer pool to add the 'X-Forwarded-For' header.
Let me know what you think is best / simplest / best.
Thanks
Comment 5•12 years ago
|
||
(In reply to Jason Crowe [:jd] from comment #4)
> There are two solutions, the first is to change the app to use the snowflake
> header (I do not know if this is possible in MW). The second is that I can
> add a traffic rule to the load balancer pool to add the 'X-Forwarded-For'
> header.
If I were to fix this in MW core, I would like to get some review for the change. Patching the code would be trivial, but the problem would pop up the next time MW is upgraded since X-Forwarded-For is currently hard-coded.
Client-IP was also checked pre-1.19 -- maybe that is available? I'll look at why it was removed in 1.19 (which just happens to be the version used)
Assignee | ||
Comment 6•12 years ago
|
||
I added the 'X-Forwarded-For' in a traffic rule. This is a trivial fix. It is unfortunate that a bad decision by Zeus some years ago has lead to this problem (It is actually quite common and causes a ton of problems). We will need to be diligent in the future to ensure this setting gets moved if this site is migrated, otherwise the issue will reoccur. It sucks to use a transient solution to attempt to work around bad decisions, but alas this is where we find ourselves.
Let me know if this solves the issue.
Assignee | ||
Comment 7•11 years ago
|
||
I believe this issue was resolved back when. I will close this bug out now.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•10 years ago
|
Target Milestone: --- → 2014-Q1
You need to log in
before you can comment on or make changes to this bug.
Description
•