XSS靶场通关全解析：从基础注入到高级绕过实战-尧图网络科技

1. 项目概述：为什么我们需要一个XSS靶场？

如果你刚开始接触Web安全，或者想深入理解XSS（跨站脚本攻击）的种种花样，光看理论文章和漏洞描述，总感觉隔靴搔痒。XSS-labs这个靶场，就是为这个目的而生的。它不是一个复杂的综合渗透平台，而是精准地聚焦于XSS这一种漏洞类型，通过20个由浅入深的关卡，模拟了真实环境中可能遇到的各种过滤、编码和防御场景。我当年学XSS的时候，就是靠着反复“折腾”这类靶场，才把那些书本上的“反射型”、“存储型”、“DOM型”概念，真正变成了肌肉记忆。

这个靶场的设计很纯粹：给你一个存在漏洞的输入点，你需要构造特定的Payload（攻击载荷）来弹出一个对话框（通常是alert函数），证明漏洞存在并成功执行了任意JavaScript代码。别小看这个“弹窗”，在实战中，它能执行的远不止弹窗，窃取Cookie、劫持会话、钓鱼、键盘记录等恶意操作都基于此。通关的过程，本质上就是一场与开发者防御逻辑的攻防博弈。你提供的GitHub仓库（do0dl3/xss-labs）是它的一个流行实现版本，结构清晰，代码开源，非常适合我们拿来搭建、分析和通关。

接下来，我会带你从零开始，不仅通关这20关，更重要的是拆解每一关背后的防御逻辑、绕过思路，并附上关键源代码的解读。我的目标是，你看完这篇详解后，不仅能复现通关，更能理解“为什么这样能绕过”，从而在实战审计或CTF比赛中，具备独立构造Payload的能力。

2. 靶场环境搭建与核心文件解析

在开始“打怪”之前，我们得先把“战场”布置好。XSS-labs靶场基于PHP开发，对环境要求极低，这大大降低了我们的上手门槛。

2.1 本地环境快速搭建

最省事的方法是利用PHP内置的Web服务器。假设你已经将下载的xss-labs文件夹放在了本地目录，比如D:\xss-labs。

打开命令行终端（CMD或PowerShell）。
切换到靶场目录：cd D:\xss-labs
启动PHP开发服务器：php -S localhost:8080

现在，打开浏览器访问http://localhost:8080，你应该就能看到靶场的首页了。首页通常会列出所有关卡（level1-level20）的链接。这种方式无需配置复杂的Apache或Nginx，特别适合学习和测试。

注意：确保你的系统已经安装了PHP，并且php命令可以在命令行中直接调用。如果未安装，去PHP官网下载一个Windows版本，安装时记得把PHP添加到系统环境变量PATH中。

2.2 核心文件结构一览

搭建好环境后，我们简单看下靶场的目录结构，这对后续分析至关重要：

index.php: 靶场入口文件，通常包含关卡选择界面。
level1.php到level20.php: 每个关卡的核心逻辑文件。我们的主要分析和攻击目标就是这些文件。
chk.js: 一个关键的JavaScript文件。它的作用是验证你的攻击是否成功。很多关卡的成功标准是执行window.alert函数，这个文件里可能定义了验证弹窗内容或触发成功提示的逻辑。
angular.min.js: 一个前端框架库。在某些关卡（尤其是涉及DOM型XSS的关卡）中，它可能会被引入，成为攻击向量的一部分。
xsf01.swf到xsf04.swf: Flash文件。在某些关卡中，可能会涉及通过Flash参数传递Payload，这是一种比较古老的攻击面，但在特定场景下仍有学习价值。
各种.png文件：通常是每关的提示或界面图片。

理解了这个结构，我们就知道，我们的攻击输入会提交给对应的levelX.php文件处理，而成功与否则由前端（可能结合chk.js）来判定。

3. 通关详解与原理剖析（第1-10关）

前10关是基础篇，主要帮助我们建立对XSS三种基本类型（反射型、存储型、DOM型）的直观认识，并接触最简单的过滤绕过。

3.1 第1关：毫无防护的反射型XSS

关卡场景：一个简单的搜索框，输入关键词后，页面会回显“您搜索的关键词是：XXX”。

通关Payload：<script>alert(1)</script>

分析与实操：这一关是“Hello World”级别的XSS。查看level1.php的源代码（右键页面查看源代码或直接打开文件），你会发现类似这样的代码：

<?php $input = $_GET['keyword']; // 直接从URL的GET参数获取输入 echo "您搜索的关键词是: " . $input; // 未经任何处理，直接输出到HTML中 ?>

我们的Payload被直接拼接进了HTML页面，形成了<script>alert(1)</script>这样一个完整的脚本标签，浏览器在解析页面时就会执行它。

核心要点：这一关展示了反射型XSS最原始的模样——用户输入被服务器直接“反射”回响应页面，且未经过滤。攻击者需要诱骗用户点击一个构造好的恶意链接（如http://靶场地址/level1.php?keyword=<script>alert(1)</script>）。

3.2 第2关：简单的标签属性注入

关卡场景：一个输入框，内容会被放入一个HTML标签的属性值里，比如<input value=”你的输入”>。

通关Payload：“><script>alert(2)</script>

分析与实操：查看源码，输出部分可能类似：

<input type="text" value="<?php echo $_GET['keyword']; ?>">

如果我们直接输入<script>alert(2)</script>，它会被当作一个字符串整体放入value属性中，变成value=”<script>alert(2)</script>”，这无法执行。

我们的Payload“><script>alert(2)</script>起到了以下作用：

“>：首先闭合value属性的双引号，然后闭合<input>标签。
<script>alert(2)</script>：随后插入我们自己的脚本标签。最终生成的HTML是：<input type=”text” value=””><script>alert(2)</script>，脚本成功脱离属性值的束缚，被浏览器解析执行。

核心要点：当输入点位于HTML标签的属性内时，需要先闭合当前的属性值和标签，才能插入新的可执行标签。

3.3 第3关：事件处理器与属性过滤

关卡场景：输入内容依然被放入某个标签的属性值，但服务器对<、>等字符进行了过滤或转义。

通关Payload：‘ onclick=’alert(3)

分析与实操：假设源码过滤了<和>，使得我们无法插入新的标签。输出点可能在<input>或<a>标签的属性里，比如：

<input type="text" value='<?php echo htmlspecialchars($_GET['keyword'], ENT_QUOTES); ?>'>

htmlspecialchars函数会将<、>、”、’等字符转义成HTML实体（如<、>），从而无法构成标签。

但我们可以利用HTML事件处理器。Payload‘ onclick=’alert(3)的作用是：

‘：闭合value属性开始的单引号。
onclick=’alert(3)：添加一个onclick事件属性，其值为alert(3)。注意，这里我们故意没有闭合最后的单引号，因为原标签可能自带闭合。最终生成：<input type=”text” value=”’ onclick=’alert(3)”>。当用户点击这个输入框时，onclick事件触发，执行alert(3)。

核心要点：当无法插入新标签时，利用现有标签的事件属性（如onclick、onmouseover、onload等）是常见的绕过手段。关键在于闭合属性值，注入新的事件处理器。

3.4 第4关：JavaScript协议与伪协议

关卡场景：输入内容被放入一个超链接的href属性中，如<a href=”你的输入”>点击</a>。

通关Payload：javascript:alert(4)

分析与实操：查看源码：

<a href="<?php echo $_GET['keyword']; ?>">点击这里</a>

href属性通常用于指定链接地址。javascript:是一个伪协议，当浏览器遇到href=”javascript:代码”的链接时，点击它不会跳转页面，而是执行:后面的JavaScript代码。

因此，注入javascript:alert(4)后，链接变为<a href=”javascript:alert(4)”>点击这里</a>。用户点击后即触发弹窗。

核心要点：javascript:伪协议是XSS攻击中利用链接属性的经典方式。类似的还有data:协议等。防御时需要对输入进行严格的URL格式校验，或禁用此类危险协议。

3.5 第5关：大小写绕过过滤

关卡场景：服务器可能对<script>、onclick等关键词进行了黑名单过滤，但过滤逻辑不严谨。

通关Payload：<ScRiPt>alert(5)</ScRiPt>

分析与实操：假设后端有一个简单的黑名单，将输入中的script、onclick等字符串替换为空。代码可能如下：

$keyword = $_GET['keyword']; $keyword = str_replace(‘script’, ‘’, $keyword); $keyword = str_replace(‘onclick’, ‘’, $keyword); echo $keyword;

这种替换是大小写敏感的。str_replace(‘script’, ‘’, $input)只会替换全小写的script。因此，我们使用大小写混合的<ScRiPt>就能轻松绕过。浏览器在解析HTML标签时是不区分大小写的，<ScRiPt>和<script>效果一样。

核心要点：黑名单过滤往往存在遗漏。大小写变异是最简单直接的绕过方式之一。完善的过滤应该使用正则表达式进行不区分大小写的匹配（如preg_replace(‘/script/i’, ‘’, $input)）。

3.6 第6关：双写绕过过滤

关卡场景：黑名单过滤不仅检查关键词，还会将其删除。但删除逻辑存在缺陷。

通关Payload：<scrscriptipt>alert(6)</scrscriptipt>

分析与实操：假设过滤逻辑是：找到script字符串并将其删除一次。

$keyword = str_replace(‘script’, ‘’, $_GET['keyword']);

当我们输入<scrscriptipt>时，过滤过程如下：

查找字符串中的script。
找到中间部分的script（即scrscriptipt中的加粗部分）。
将其删除，字符串变为<script>。
输出<script>，攻击成功。

核心要点：这是针对简单删除式过滤的经典绕过。防御方需要递归地或多次执行过滤，直到字符串中不再包含黑名单词汇，但这可能影响性能且仍有被其他方式绕过的风险。

3.7 第7关：利用HTML实体编码

关卡场景：服务器对某些特殊字符（如<、>）进行了转义，但转义可能不彻底或存在上下文问题。

通关Payload：先尝试<script>alert(7)</script>，发现被转义。观察输出点上下文。假设输出在一个<input>的value里，且只转义了尖括号，但允许引号。我们可以尝试闭合标签：“onclick=”alert(7)。如果引号也被转义，则需要寻找其他可用的属性。

分析与实操：这一关的防御可能更强。我们需要查看页面源代码，看我们的输入被转换成了什么。例如，输入<script>可能被输出为<script>，这是HTML实体编码，浏览器会将其显示为文本<script>，而不会解析为标签。

此时，我们需要思考：输出点是否在另一个可执行上下文中？例如，是否在<script>标签内部？或者是否在某个事件处理器内部？如果是在<script>标签内，我们注入的代码可能需要符合JavaScript语法。例如，如果源码是：

<script> var x = "<?php echo htmlspecialchars($_GET['keyword']); ?>"; </script>

htmlspecialchars会转义引号，但我们如果注入”;alert(7);//，经过转义后可能变成";alert(7);//，这依然可能破坏原JS字符串结构并执行新代码，具体取决于转义模式。这一关需要结合实际情况进行测试。

核心要点：上下文是关键。必须明确你的输入最终位于HTML文档的哪个部分（HTML标签内、属性内、JavaScript代码块内、CSS样式内）。不同上下文，绕过过滤和构造Payload的方法截然不同。

3.8 第8关：编码与解码的博弈

关卡场景：输入内容可能会经过一次或多次编码/解码，我们需要利用解码过程来让我们的Payload“复活”。

通关Payload：javascript:alert(8)（使用HTML实体编码）

分析与实操：假设服务器对输入进行了HTML实体编码，但输出点是在href属性中，且浏览器会自动对属性值进行解码。

我们输入javascript:alert(8)，但服务器可能过滤了javascript:这个字符串。
我们改为输入javascript:alert(8)。其中t是字母t的HTML十六进制实体编码。
服务器可能不会识别编码后的字符串为黑名单，因此放行。
当浏览器渲染页面，解析到href=”javascript:alert(8)”时，它会自动将t解码还原为t，最终得到有效的javascript:alert(8)。

核心要点：浏览器在解析HTML的不同阶段会对编码进行解码。常见的编码有HTML实体编码（<）、URL编码（%3C）、JavaScript Unicode编码（\u003c）等。利用编码差异（服务器过滤时解码一层，浏览器渲染时再解码一层）是高级绕过技巧。

3.9 第9关：利用协议完整性检测

关卡场景：针对javascript:伪协议的防御加强了，可能会检查整个字符串是否以http://或https://开头，或者检查javascript:后面是否跟了“合法”内容。

通关Payload：javascript:alert(9)//http://xxx

分析与实操：有些防御代码会检查href的值，如果它不是以http开头，就认为不安全。或者，它会检查javascript:后面是否有内容，并尝试验证其“合法性”。我们的Payload做了两件事：

javascript:alert(9)：核心攻击代码。
//http://xxx：//在JavaScript中是单行注释符，它会让后面的http://xxx被当作注释忽略掉。但对于一些简单的字符串匹配检查来说，整个字符串里确实包含了http://，可能因此通过检查。

核心要点：利用注释符来“欺骗”简单的字符串匹配或正则表达式检查，是绕过协议和内容校验的常见手法。

3.10 第10关：隐藏参数与DOM型XSS初探

关卡场景：页面上可能有多个输入点，但并非所有都显示在表单里。可能存在通过URL参数控制的隐藏输入框或DOM操作。

通关Payload：观察URL，尝试其他参数。例如，可能存在?keyword=test&submit=submit&hidden_param=<script>alert(10)</script>。

分析与实操：查看第10关的页面源代码，仔细寻找所有可能接收参数的地方。除了明显的输入框，还要注意：

隐藏域（<input type=”hidden”>）。
URL中的其他参数（如submit,t_sort,t_link等，具体名字需看源码）。
页面中的JavaScript代码，是否从URL（location.search）或document.referrer等地方获取了参数，并动态写入了DOM。

例如，源码中可能有：

<input type="hidden" name="t_sort" value="<?php echo $_GET['t_sort']; ?>">

那么攻击向量就是t_sort参数。我们可以尝试注入：?t_sort=” onmouseover=”alert(10)。

核心要点：不要只盯着最明显的输入框。审计时，要分析前端所有可能的数据流入点，包括URL所有参数、Cookie、Referer，以及页面中的JavaScript如何操作DOM。这是DOM型XSS的典型场景——数据在客户端JavaScript中被处理并写入页面，服务器端可能没有直接参与输出。

4. 通关详解与原理剖析（第11-20关）

后10关难度显著提升，融合了更多实战中可能遇到的复杂场景，如HTTP头注入、Flash参数、JSON解析、AngularJS框架利用等。

4.1 第11关：HTTP Referer头注入

关卡场景：漏洞点不在普通的GET/POST参数，而在HTTP请求头中，特别是Referer头。

通关Payload：需要借助浏览器插件（如HackBar）或Burp Suite等代理工具，修改HTTP请求的Referer头，将其值设置为”><script>alert(11)</script>。

分析与实操：查看level11.php的源代码，你可能会发现类似这样的代码：

$referer = $_SERVER['HTTP_REFERER']; // 获取Referer请求头 echo "<input type='text' value='$referer'>"; // 将其输出到页面中

Referer头是浏览器自动发送的，表示当前请求是从哪个页面链接过来的。服务器端信任了这个头信息，并将其未经过滤地输出到了HTML标签属性里。

操作步骤：

使用Burp Suite拦截访问level11.php的请求。
在拦截的请求中，找到Referer头，将其值修改为” onmouseover=”alert(11)。
转发请求。服务器接收到修改后的Referer值，并将其输出到页面，构造出可执行的onmouseover事件。

核心要点：任何用户可控的输入源都可能成为XSS的入口，包括HTTP请求头（Referer, User-Agent, Cookie等）、服务器环境变量等。在安全测试中，需要对所有输入向量进行测试。

4.2 第12关：User-Agent头注入

关卡场景：与第11关类似，但注入点换成了User-Agent请求头。

通关Payload：使用代理工具修改User-Agent的值为XSS Payload，例如：Mozilla/5.0 ... <script>alert(12)</script>。

分析与实操：原理与Referer注入完全一致。源码中可能用$_SERVER['HTTP_USER_AGENT']获取该值并输出。User-Agent是浏览器标识自己的字符串，通常很长且复杂，开发者更容易忽略对其的过滤。

实操心得：在Burp Suite的Intruder或Repeater模块中，可以很方便地修改这些头部信息进行测试。这也提醒我们，在编写Web应用时，除非必要，否则不应将任何HTTP头信息直接输出到HTML页面中。

4.3 第13关：Cookie注入

关卡场景：注入点隐藏在Cookie中。

通关Payload：修改名为user（或其他名称，需看源码）的Cookie值为” onfocus=”alert(13) autofocus “。

分析与实操：查看level13.php源码，寻找类似$_COOKIE[‘user’]的代码。攻击者可以通过JavaScript（document.cookie）或浏览器开发者工具（Application/Storage -> Cookies）直接修改当前站点的Cookie值。

操作步骤：

在浏览器中打开靶场页面。
按F12打开开发者工具，进入“应用”（Application）或“存储”（Storage）标签页。
找到当前网站的Cookies，修改其中某个看起来会被输出的Cookie值（如user），插入XSS Payload。
刷新页面，Payload随Cookie发送到服务器，并被输出到页面中执行。

核心要点：Cookie同样是用户可控的（虽然通常由服务端设置）。如果应用将Cookie值未经验证就输出，则存在风险。HttpOnly属性可以防止JavaScript读取Cookie，但无法阻止攻击者修改Cookie并发起请求。

4.4 第14关：利用图片EXIF信息（或类似文件上传点）

关卡场景：这一关可能模拟了一个图片上传功能，但服务器在处理图片时，会读取并输出图片的某些元数据（如EXIF信息中的注释字段）。

通关Payload：准备一张图片，使用工具（如exiftool）将XSS Payload写入图片的EXIF注释（Comment）字段，然后上传。

分析与实操：

安装exiftool：brew install exiftool(Mac) 或从官网下载(Windows)。
准备一张无害的图片（如test.jpg）。
执行命令：exiftool -Comment=’<script>alert(14)</script>’ test.jpg
上传这张图片到靶场。
假设服务器端代码用exif_read_data()函数读取了Comment并输出：echo $exif[‘COMMENT’][0];，那么Payload就会被执行。

核心要点：攻击面不仅限于表单和URL。文件内容、元数据、文件名都可能成为注入载体。对于文件上传功能，必须对文件内容进行严格检查和过滤，而不仅仅是检查文件后缀名。

4.5 第15关：AngularJS Client-Side Template Injection (CSTI)

关卡场景：页面引入了AngularJS框架，并且用户输入被放入了AngularJS的模板表达式中。

通关Payload：{{constructor.constructor(‘alert(15)’)()}}或{{$eval(‘alert(15)’)}}

分析与实操：查看页面源代码，确认是否引入了angular.min.js。AngularJS使用双大括号{{ }}进行数据绑定。如果服务器将用户输入直接拼接进模板，且未使用ng-bind-html等安全方式，就会导致客户端模板注入。

例如，服务器端可能这样写：

<div ng-app> 你好， <?php echo $_GET['name']; ?>! </div>

如果我们输入{{$eval(‘alert(15)’)}}，AngularJS会将其作为表达式执行。更危险的Payload是{{constructor.constructor(‘alert(15)’)()}}，它利用了JavaScript的constructor属性动态创建函数并执行。

核心要点：在现代前端框架（AngularJS, Vue, React）中，不安全的动态模板渲染是新型XSS的高发区。防御的关键在于：永远不要将用户输入作为模板或表达式的一部分进行拼接，应使用框架提供的安全绑定方法。

4.6 第16关：利用Flash文件（SWF）参数

关卡场景：页面内嵌了一个Flash文件（.swf），并且该Flash文件会从URL参数或FlashVars参数中读取数据并输出。

通关Payload：?keyword=a&flash_param=<script>alert(16)</script>或通过FlashVars参数传递。

分析与实操：查看level16.php源码，可能会发现嵌入SWF的代码：

<embed src="xsf01.swf" flashvars="text=<?php echo $_GET['keyword']; ?>">

flashvars是传递给Flash的参数。如果Flash内部存在漏洞，未能妥善处理接收到的text参数，就可能导致XSS。攻击Payload需要根据具体的Flash漏洞来构造，可能非常复杂。在旧版Flash中，存在一些可以执行脚本的API（如getURL、ExternalInterface.call）被不当使用的情况。

核心要点：这是一种基于插件的攻击。随着Flash的淘汰，这类漏洞已不常见，但其原理仍然有教育意义：任何浏览器插件或组件（如PDF阅读器、Java Applet、Silverlight）如果存在脚本执行接口且处理输入不当，都可能成为XSS的跳板。

4.7 第17关：JSON注入与解析

关卡场景：页面通过AJAX获取数据，数据格式为JSON，但JSON数据被动态生成并包含用户输入，且在前端使用eval()或JSON.parse()后的数据被不安全地插入DOM。

通关Payload：keyword={“name”: “test”, “message”: “</script><script>alert(17)</script>”}

分析与实操：假设后端代码根据输入生成一个JSON字符串：

$data = array(‘message’ => $_GET[‘keyword’]); echo json_encode($data);

前端JavaScript用eval或JSON.parse解析后，直接将message的内容用innerHTML或类似方法插入页面。如果message中包含闭合标签</script>和新的<script>标签，就可能逃逸出JSON字符串上下文，被当作HTML解析。

更隐蔽的方式是利用JSONP（JSON with Padding）回调函数名注入，如果回调函数名用户可控且未过滤，可能直接执行代码。

核心要点：JSON本身不是代码，但处理JSON的过程可能产生代码执行。永远不要使用eval()解析JSON，应使用JSON.parse()。在将JSON数据插入DOM时，必须进行HTML编码或使用安全的API（如textContent而非innerHTML）。

4.8 第18关：基于DOM的XSS与`document.write`

关卡场景：漏洞完全发生在客户端JavaScript中，服务器端不参与输出。JavaScript代码从URL片段（location.hash）或参数中获取数据，并通过document.write()或innerHTML等不安全的方式写入DOM。

通关Payload：level18.html#<img src=x onerror=alert(18)>

分析与实操：查看页面JavaScript源码，可能会发现：

var hash = location.hash.substring(1); // 获取#后面的内容 document.write(‘<div>’ + hash + ‘</div>’); // 危险！直接写入

location.hash是URL中#号后面的部分，不会发送到服务器。攻击者可以构造一个恶意URL，用户访问时，客户端的JavaScript会将hash中的Payload直接写入页面，导致XSS。

核心要点：这是纯DOM型XSS的典型例子。防御方法包括：避免使用document.write()、innerHTML、outerHTML直接拼接HTML；如果必须动态生成内容，应使用createElement、setAttribute、textContent等安全的DOM API；或者对用户输入进行严格的HTML编码。

4.9 第19关：`postMessage`跨域通信滥用

关卡场景：页面使用了window.postMessage()API进行跨域或跨iframe通信，但消息接收方未对消息来源和内容进行严格验证。

通关Payload：需要创建一个恶意页面，在其中通过postMessage向靶场页面发送包含XSS Payload的消息。

分析与实操：

靶场页面（level19.php）内可能嵌有一个<iframe>，或者它本身监听message事件：

window.addEventListener(‘message’, function(e) { // 危险！未验证origin，且直接使用e.data document.getElementById(‘content’).innerHTML = e.data; });

攻击者创建一个恶意页面，其中包含：

<iframe id="target" src="http://靶场地址/level19.php" style="display:none"></iframe> <script> var iframe = document.getElementById('target'); iframe.onload = function() { // 向靶场页面发送恶意数据 iframe.contentWindow.postMessage('<img src=x onerror=alert(19)>', '*'); // 使用'*'表示任何origin }; </script>

诱使用户访问恶意页面，恶意页面加载靶场页面后，向其发送消息，触发XSS。

核心要点：使用postMessage时，必须验证event.origin，确保消息来自可信的源。同时，对接收到的event.data也要像处理其他用户输入一样，进行严格的验证和编码。

4.10 第20关：综合挑战与源码审计

关卡场景：最后一关通常是前面所有技巧的综合，或者引入一个更隐蔽、需要多步利用的漏洞。它要求你仔细审计前端和后端源码，找到那个被忽略的输入点或过滤逻辑的盲点。

通关Payload：没有固定答案。你需要像侦探一样，分析level20.php的源代码，以及它引用的所有JS文件（特别是chk.js）。

分析与思路：

全面信息收集：查看页面所有HTML元素、JavaScript代码、网络请求。
寻找所有sink点：搜索innerHTML、outerHTML、document.write、eval、setTimeout、setInterval、Function构造函数、location赋值、jQuery的html()方法等危险的“接收器”（sink）。
回溯数据流：对于每个sink点，向上回溯，看数据来自哪里——是URL参数、Cookie、本地存储、AJAX响应，还是其他DOM属性？
分析过滤与编码：数据在到达sink之前，经过了哪些函数处理？是黑名单替换、白名单过滤，还是编码转换？尝试找出过滤逻辑的缺陷。
构造多步Payload：可能需要结合之前多关的技巧。例如，先利用一个参数进行HTML注入，但被过滤了事件处理器，然后利用另一个参数控制JavaScript字符串，通过JS字符串拼接来最终执行代码。

实操心得：真正的渗透测试和CTF比赛中，最后一关往往就是这种“源码审计”模式。养成随手查看源代码的习惯至关重要。使用浏览器的开发者工具（Sources, Debugger）设置断点，单步跟踪JavaScript执行流程，是理解复杂DOM型XSS的利器。

5. 防御策略与安全开发建议

通关了20个关卡，我们见识了攻击者的各种奇技淫巧。现在从防御者角度，总结一下究竟该如何有效防御XSS。

5.1 根本原则：输入验证与输出编码

这是防御XSS的黄金法则，但很多人理解有误。

输入验证：在数据进入应用程序时进行。目的是确保数据符合预期的格式、类型、长度和业务规则。例如，邮箱字段应该符合邮箱格式，年龄字段应该是数字。输入验证可以阻止大量畸形攻击数据，但它不能完全依赖于防御XSS，因为很多Payload看起来是“合法”的文本。
- 白名单优于黑名单：定义允许的字符集（如字母、数字、有限符号），拒绝其他所有字符。这比试图列出所有危险字符（黑名单）要可靠得多。
输出编码：在数据从应用程序输出到不同上下文时进行。这是防御XSS最核心、最有效的手段。编码的意义在于，将特殊字符转换成其在当前上下文中安全的表示形式，使其不被解释为代码。
- 针对HTML上下文：使用HTML实体编码。将<转为<，>转为>，&转为&，”转为"，’转为'。PHP的htmlspecialchars($string, ENT_QUOTES | ENT_HTML5, ‘UTF-8’)函数可以很好地完成这个工作。关键参数ENT_QUOTES确保单双引号都被编码。
- 针对HTML属性上下文：同上，使用HTML实体编码。确保属性值总是用引号括起来（单引号或双引号）。
- 针对JavaScript上下文：将数据放入JavaScript字符串时，需要进行JavaScript Unicode转义。例如，将”转为\u0022，将\转为\\。更安全的做法是，避免在JavaScript中拼接HTML，而是使用textContent或安全的DOM API。
- 针对URL上下文：在将数据作为URL的一部分输出时，使用URL编码（encodeURIComponent）。
- 针对CSS上下文：非常危险，尽量避免将用户输入放入CSS中。如果必须，需进行严格的CSS编码。

5.2 内容安全策略 (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>…</script>）和javascript:伪协议将被阻止。
object-src ‘none’：完全禁止<object>、<embed>、<applet>等插件，可以有效防御Flash XSS。

CSP能极大地缓解XSS的影响，即使攻击者成功注入了脚本，如果该脚本的来源不在白名单内，浏览器也不会执行它。

5.3 其他重要措施

使用安全的DOM API：在前端，优先使用textContent代替innerHTML，使用setAttribute代替直接操作属性字符串。如果必须使用innerHTML，务必先对动态内容进行编码。
设置Cookie的HttpOnly和Secure标志：HttpOnly可以阻止JavaScript通过document.cookie访问Cookie，这对于防止XSS攻击窃取会话Cookie至关重要。Secure确保Cookie仅通过HTTPS传输。
框架和库的安全使用：使用现代前端框架（如React, Vue, Angular）时，务必遵循其安全实践。它们通常提供了默认的编码机制（如React的JSX会自动转义），但也要警惕dangerouslySetInnerHTML（React）或v-html（Vue）这类危险API。
定期安全测试与代码审计：将XSS测试纳入开发流程。使用自动化工具（如OWASP ZAP, Burp Suite Scanner）进行扫描，同时结合手动测试和代码审查。