从XSS漏洞挖掘到CSP绕过：以test.ctf8为例的Web安全实战解析
1. 从一次真实的CTF解题说起：当XSS遇上“test.ctf8”
最近在复盘一些经典的Web安全挑战，偶然翻到一个名为“test.ctf8”的XSS注入题目。这个题目本身并不复杂，甚至可以说是一个典型的入门级XSS场景，但恰恰是这种“典型”，让我觉得有必要把它拿出来好好聊聊。很多刚接触CTF（Capture The Flag，夺旗赛）或者Web安全的朋友，一看到XSS（跨站脚本攻击）就觉得是弹个框、偷个Cookie，思路容易固化。实际上，即便是最简单的题目，背后也藏着对浏览器解析逻辑、JavaScript执行环境以及输入输出过滤机制的深刻理解。今天，我就以“test.ctf8”这个靶场为例，完整拆解一遍我的解题思路和操作过程，希望能帮你跳出“弹框即成功”的思维定式，真正理解XSS漏洞的利用链是如何一环扣一环构建起来的。
这个靶场的核心，就是一处存在反射型XSS漏洞的搜索接口。你的目标很明确：通过构造特殊的输入，让前端页面执行你预设的JavaScript代码，从而触发某种“动作”来获取Flag。这个“动作”可能是弹窗、可能是请求外部资源、也可能是读取页面上的特定信息。我们一步步来。
2. 环境侦察与漏洞点定位：一切从“输入”开始
面对任何Web题目，第一步永远是信息收集。对于XSS，我们最关心的是：我们的输入在哪里被输出？以及输出时，上下文环境是什么？
我首先访问了test.ctf8这个靶场地址。页面通常是一个简单的搜索框，可能附带一些说明文字。我的第一个动作永远是尝试最基础的探测。
2.1 基础探测：确认漏洞存在
我在搜索框里输入了一个最简单的测试载荷：<script>alert(1)</script>。点击搜索后，页面刷新，结果区域显示了搜索结果（通常是“未找到”之类的提示），但并没有弹窗。这并不代表没有漏洞，反而可能意味着存在基础的过滤，比如尖括号<>被转义或删除。
接下来，我尝试了纯文本和特殊字符来探测过滤规则：
- 输入
test：正常回显，说明输入输出功能正常。 - 输入
“（双引号）和‘（单引号）：观察它们是否被转义为HTML实体（如"和'）。如果被转义，说明服务端可能做了HTML编码，直接插入<script>标签会失败。 - 输入
<test>：观察<和>是否被过滤。如果<test>被原样输出，说明标签未被过滤；如果变成了<test>或<test>消失，则说明有过滤。
在test.ctf8这个场景下，我发现输入<test>后，页面上显示的就是<test>这个文本，尖括号没有被转义成实体。这是一个非常积极的信号，意味着标签的闭合符号可能没有被严格处理。
2.2 深入分析输出上下文：关键在于“落脚点”
XSS能否成功，很大程度上取决于我们的输入被“塞”到了HTML文档的哪个位置。我们需要查看页面源代码（Ctrl+U）。
在搜索test后，查看源码，我通常会搜索我的输入内容（如“test”）在HTML中的位置。假设我发现了这样的结构：
<input type="text" value="你输入的内容">或者
<div>搜索结果：你输入的内容</div>又或者
<script>var keyword = '你输入的内容';</script>这三种情况分别对应着不同的注入上下文：
- HTML标签属性内（如value）：我们需要先闭合当前的属性值，然后引入新的事件属性。例如，如果输入点在
value=""内部，我们需要构造“ onmouseover=”alert(1)，最终形成value=“” onmouseover=“alert(1)”。 - HTML标签之间（如div内部）：我们可以直接插入新的HTML标签，如
<img src=x onerror=alert(1)>。 - JavaScript字符串内（如script标签里）：我们需要先闭合字符串和语句，然后注入新的JS代码。例如，输入点在
var a=‘input’;，我们需要构造‘;alert(1);//，最终形成var a=‘’;alert(1);//’;。
在test.ctf8中，通过查看源码，我确认我的输入被直接输出在了一个<div>标签内部，类似于<div class=“result”>你的输入</div>。这属于上述第二种情况：HTML文本节点上下文。这意味着我可以尝试插入新的HTML标签来执行JavaScript。
注意：现代浏览器对直接写在HTML中的
<script>标签内容（内联脚本）有严格的限制，通过innerHTML动态插入的<script>标签默认不会执行。因此，即使我们能插入<script>alert(1)</script>，它也未必会执行。我们需要使用带有事件处理器（如onerror,onload,onmouseover）的标签，或者能触发脚本执行的属性（如<svg><script>...</script></svg>，但同样受限）。
3. 载荷构造与绕过尝试：思维不能停
既然确认了是HTML上下文，且尖括号似乎可用，我开始系统性地尝试构造有效的XSS载荷。
3.1 第一轮尝试：经典事件处理器
我首先尝试了最常用的IMG标签：
<img src=x onerror=alert(1)>输入后，页面没有弹窗。查看网络请求或控制台，发现图片加载失败（src=“x”是个无效地址），但onerror事件并没有触发。这很奇怪。我打开浏览器开发者工具（F12）的控制台（Console），看到了一个错误信息：“Refused to execute inline event handler because it violates the following Content Security Policy directive...”
CSP（内容安全策略）！这是XSS挑战中一个非常常见的防御机制。服务器通过HTTP响应头Content-Security-Policy来告诉浏览器，哪些来源的资源可以被加载和执行。常见的指令如script-src ‘self’表示只允许执行同源（本站）的脚本，unsafe-inline则禁止执行内联的事件处理器和<script>标签。
我们需要查看响应头。在开发者工具的“网络”（Network）选项卡中，找到我们搜索请求的响应，查看Response Headers。果然，发现了类似Content-Security-Policy: script-src ‘self’;的头部。这意味着，我们注入的onerror=alert(1)这种内联事件处理器是被禁止的。
3.2 第二轮尝试：绕开CSP限制
CSP的存在并不意味着XSS完全无解，它只是提高了门槛。我们需要在CSP规则允许的范围内，找到执行代码的方法。仔细分析CSP头：
script-src ‘self’：允许加载和执行与当前页面同源的JavaScript文件。- 没有
unsafe-inline：禁止内联脚本和事件处理器。 - 通常也没有
unsafe-eval：禁止eval()等动态代码执行。
那么，思路就变成了：能否将我们的恶意脚本，变成一个同源的可执行JS文件，然后让页面加载它？
这通常有两种方式：
- 利用现有的同源JS文件：如果网站本身有一个JS文件，比如
/static/js/app.js，并且我们可以控制其部分内容（例如通过参数污染、缓存投毒或上传点），我们就可以尝试修改它。但在简单的CTF题中，这种可能性较小。 - 引入一个会被当作JS解析的同源资源：有没有可能，我们输入的内容，最终被服务器存储或反射到一个路径下，并且这个路径的响应
Content-Type是application/javascript？这样浏览器就会把它当作JS文件来执行。
这时，我想到了JSONP或AngularJS这类技术可能带来的变种。但在这个简单的搜索反射题里，更常见的绕过方式是利用允许的标签加载资源。虽然script-src ‘self’限制了脚本源，但img-src（图片源）或default-src（默认源）可能配置得更宽松。如果CSP允许从任何地方加载图片（img-src *），我们可以构造一个图片标签，将其src指向一个我们控制的服务器，从而将Cookie等信息带出（但这道题的目标通常是弹窗或执行代码获取FLAG，而非外带数据）。
然而，题目要求是执行代码。另一个经典绕过是使用<link>标签配合href和onload，但onload作为内联事件处理器同样被CSP禁止。
换个角度：CSP的script-src ‘self’是否真的滴水不漏？我们能否创造一个“同源”的脚本？如果服务器对搜索内容处理不当，可能会产生一个存储型XSS的错觉。例如，搜索内容被错误地记录在某个公开访问的日志页面，而这个页面的响应类型是text/html，但其中包含了我们的脚本。不过，这需要二次触发，不符合反射型XSS的直观解题路径。
我重新审视页面。有没有可能，我忽略了输出点的其他特性？我再次查看搜索结果的页面源码，不仅看<div>，还看<head>部分。突然，我注意到一个细节：页面引入了一个同源的JS文件，像是<script src=“/js/search.js”></script>。
灵感来了：如果我能控制这个src的值呢？虽然我不能直接修改<script>标签，但有没有可能存在DOM型XSS？即，前端JS代码会读取URL中的参数（如location.search），然后通过document.write()或innerHTML等方式动态写入页面。如果这个写入过程没有经过正确的编码，就可能造成注入。
3.3 第三轮尝试：挖掘DOM型XSS可能
我检查页面中其他的<script>块。果然，在页面底部发现了一段内联脚本：
<script> function displayResult() { var kw = new URLSearchParams(window.location.search).get(‘keyword‘); if (kw) { document.getElementById(‘result‘).innerHTML = “您搜索的关键词是：” + kw; } } window.onload = displayResult; </script>破案了！这才是真正的漏洞点。之前的服务端回显（那个<div>）可能做了基础的HTML实体转义，所以直接注入标签失败。但这段前端JavaScript代码，直接从URL的keyword参数中获取值，然后未经任何过滤就直接用innerHTML赋值给了id=“result”的元素。这是一个典型的DOM型XSS。
CSP的script-src ‘self’限制的是脚本的来源，但它不限制通过innerHTML属性设置的HTML内容中的内联事件处理器！因为innerHTML属性设置的脚本，其执行是由浏览器在解析HTML时触发的，这与CSP评估的“脚本来源”是两条线。CSP主要防止的是未经授权的脚本文件加载和内联脚本块的执行，但对于通过innerHTML动态添加的、带有事件处理器（如onload,onerror）的HTML元素，只要该元素最终被插入到DOM中，其事件处理器在触发时就能执行代码。
因此，我们的绕过路径变得清晰：利用DOM型XSS，构造一个通过innerHTML插入后能自动触发事件的标签。
4. 最终载荷构造与Flag获取
现在，目标明确：让kw变量的值包含一个能通过innerHTML插入后立即执行JS的HTML片段。
由于是innerHTML插入，<script>标签仍然不会执行。我们需要一个能自动触发事件的标签。<img>的onerror需要加载失败，但我们可以让src为空或无效来确保失败。<svg>标签内的<script>在某些情况下可以通过innerHTML执行，但依赖浏览器版本和CSP细节，不是最稳妥的。
一个更可靠的、能自动触发的标签是<iframe>的onload，但需要src指向一个页面，不够直接。另一个经典向量是<body onload=alert(1)>，但我们需要注入整个<body>标签吗？不一定。
这里我使用一个非常简洁有效的Payload：
<img src=1 onerror=alert(1)>当这段字符串被document.getElementById(‘result‘).innerHTML = ...设置时，浏览器会解析它，创建一个<img>元素，并尝试加载src=“1”。这个资源显然不存在，加载失败会立即触发onerror事件，从而执行alert(1)。
我在搜索框输入这个Payload，或者直接在URL中构造：
http://test.ctf8/?keyword=<img src=1 onerror=alert(1)>访问这个URL，页面加载后，displayResult函数执行，将Payload通过innerHTML插入，图片加载失败，成功弹窗！
但这只是证明漏洞存在。CTF题目的目标通常是获取一个名为flag的变量值，或者读取页面中的特定信息。所以，我们需要将alert(1)替换为窃取信息的代码。由于CSPscript-src ‘self’的存在，我们无法直接使用fetch或XMLHttpRequest发送数据到外部服务器（除非CSP的connect-src指令允许，通常不会）。但题目环境往往是封闭的，Flag就在当前页面的某个地方，比如一个隐藏的<div>，或者前端的JavaScript变量里。
假设Flag存储在前端的一个变量里，比如window.flag = “flag{this_is_flag}”;。我们可以修改Payload来读取它：
<img src=1 onerror=alert(window.flag)>如果Flag在页面的某个元素里，比如<div id=“flag” style=“display:none”>flag{...}</div>，我们可以用：
<img src=1 onerror=alert(document.getElementById(‘flag‘).innerText)>在test.ctf8的具体场景中，我最终使用的Payload是：
<img src=1 onerror=alert(document.body.innerText)>因为有时Flag会以注释的形式藏在HTML源码里，或者直接写在页面某个角落。document.body.innerText可以获取页面所有文本内容，便于快速查找。弹窗后，在长长的文本中，我顺利找到了格式为flag{...}的字符串。
5. 复盘与延伸：不止于解题
这道“简单”的题目，实际上串联了多个关键知识点：
- 信息收集与上下文判断：不能一上来就盲打Payload，必须通过基础测试（纯文本、特殊符号）判断过滤规则和输出位置。查看页面源码和开发者工具是必修课。
- 理解CSP及其绕过：CSP是现代浏览器缓解XSS的核心机制。遇到弹窗失败，第一时间要检查Network响应头。理解
script-src、unsafe-inline等指令的含义，是绕过的基础。本例中，CSP限制了脚本来源，但未能阻止通过innerHTML插入的HTML元素事件处理器执行。 - 区分反射型、存储型与DOM型XSS：服务端反射（回显在HTML中）和前端DOM操作（
innerHTML、document.write）是两种不同的注入场景，过滤和绕过的策略也不同。本题就是典型的DOM型XSS，漏洞发生在前端JS逻辑中。 - 有效Payload的构造：在HTML上下文中，
<script>标签通过innerHTML插入不执行是常识。需要熟练使用带有onerror、onload、onmouseover等事件处理器的标签（如<img>、<iframe>、<svg>、<body>）。确保事件能被触发（如src指向不存在的资源以触发onerror）。 - 目标导向的利用：证明漏洞（弹窗）只是第一步。最终目的是获取Flag。需要根据题目环境，灵活调整Payload来读取页面中的特定数据（全局变量、DOM元素内容、Cookie等）。
一个实用的技巧：在复杂的CTF环境或真实渗透测试中，如果CSP非常严格，连
innerHTML插入的事件处理器都通过更严格的CSP策略（如使用nonce或hash）限制了，还可以考虑基于DOM的客户端原型污染或利用Trusted Types等更前沿的绕过技术，但那属于更高阶的范畴。对于大多数入门到中级的题目，掌握上述链条已经足够。
通过“test.ctf8”这道题，我们完成了一次完整的XSS漏洞挖掘、分析、绕过和利用的旅程。它提醒我们，Web安全是一个立体战场，前端、后端、浏览器策略任何一环的疏忽都可能被利用。下次遇到XSS挑战，不妨按这个流程走一遍：探环境、定上下文、查策略、构载荷、达目的。