[Possible] Internal IP Address Disclosure
Description
The application exposes internal IPv4 addresses (such as 10.x.x.x, 172.16.x.x-172.31.x.x, or 192.168.x.x) in its responses. These addresses reveal details about the organization's internal network topology and IP addressing scheme. Attackers can leverage this information to map the internal infrastructure, identify potential targets for lateral movement, and craft more sophisticated attacks against internal systems.
Remediation
Remove or sanitize internal IP addresses from all application responses, error messages, and debug output. Implement the following measures:<br/><br/>1. <strong>Review and sanitize output:</strong> Audit all application code that generates user-facing content, logs, or error messages to ensure internal IP addresses are not included.<br/><br/>2. <strong>Configure web servers and proxies:</strong> Ensure web servers and reverse proxies do not expose internal IP addresses in headers (such as X-Forwarded-For or Via headers) or error pages.<br/><br/>3. <strong>Implement output filtering:</strong> Use a centralized output filter to detect and replace internal IP addresses before sending responses to clients.<br/><br/>Example filter implementation:<br/><pre> // Example: Sanitize internal IPs in application responses function sanitizeInternalIPs(content) { const internalIPPatterns = [ /\b10\.\d{1,3}\.\d{1,3}\.\d{1,3}\b/g, /\b172\.(1[6-9]|2[0-9]|3[0-1])\.\d{1,3}\.\d{1,3}\b/g, /\b192\.168\.\d{1,3}\.\d{1,3}\b/g ]; let sanitized = content; internalIPPatterns.forEach(pattern => { sanitized = sanitized.replace(pattern, '[INTERNAL IP]'); }); return sanitized; } </pre><br/>4. <strong>Disable verbose error messages:</strong> Configure production environments to display generic error messages instead of detailed stack traces or system information.<br/><br/>5. <strong>Regular security testing:</strong> Periodically scan application responses to verify that internal IP addresses are not being leaked.