Security scan tools try to exploit known vulnerabilities in your web applications. This helps system administrators and software developers to detect potential issues in advance and take an action before the applications go live.
One of the vulnerabilities security scan tools look for (and attackers try to exploit) is the vulnerability specified in PCI DSS 3.2 requirement 1.3.7:
Do not disclose private IP addresses and routing information to unauthorized parties
We will see what this vulnerability about and how to fix it in this post.
The issue is the web server to include an internal IP address or internal network name in the response for a GET request. This could be the IP address of IIS server or a network device. This information could be in Content-Location header or 3xx redirect address.
The internal IP/name should be automatically masked by IIS 7 and newer versions. If you still see this information leaked (this vulnerability is raised by the security scan tool), follow the recommendations below.
You may see “The application doesn’t user secure cookie flag” warning in your scan report as well. Check this post out for the solution: Secure cookie flag
Solution for “Do not disclose private IP addresses and routing information”
Check what the information that is disclosed. Is it your IIS server IP? Is it Load Balancer IP? Based on what information is disclosed, you may want to focus your effort on that server/device.
There are 3 possible solutions to this issue:
- Go to IIS Manager
- Click on the website
- Double click on “Configuration Editor”
- Go to “system.webServer/serverRuntime”
- Enter the public domain name of the website into “alternateHostName” field
- Make sure “enabled” parameter is set to “True”
- Click “Apply”
- Reset IIS
You can set alternateHostName via Command Prompt as well:
appcmd.exe set config -section:system.webServer/serverRuntime /alternateHostName:"myServer" /commit:apphost
URL Rewrite rule
The rule below should remove the information in Content-Location header.
<configuration> <system.webServer> <rewrite> <outboundRules> <rule name="Remove RESPONSE_Server"> <match serverVariable="RESPONSE_Content-Location" pattern=".+"/> <action type="Rewrite" value=""/> </rule> </outboundRules> </rewrite> </system.webServer> </configuration>
Basic Authentication Realm
It’s a low possibility but if you are using Basic Authentication, setting the “Realm” in settings should solve this issue as well.
Load Balancer and Firewall
If you see the IP address or name of your load balancer or firewall, it is a good idea to check their configuration to see if they are adding the internal information that is flagged as vulnerability. In my case, it was caused by F5 load balancer.
Another area to look into might be the usage of HTTP/1.0. Here is more details.
Your security scan tool may flag the usage of HTTP TRACK and TRACE methods as well. Here is the solution: How to disable HTTP TRACK and TRACE verbs in IIS?