在 Web 安全领域，跨站脚本（Cross-Site Scripting，简称 XSS）是最常见、危害最广的漏洞之一。攻击者通过注入恶意脚本，就能在受害者浏览器中执行任意代码，窃取数据、伪造操作甚至接管用户会话。今天，我们结合 DVWA 和 WebGoat 的实验场景，带大家直观理解反射型 XSS 的攻击原理与风险。

一、什么是反射型 XSS？

反射型 XSS 属于非持久型漏洞，恶意脚本不会存储在服务器中，而是通过 URL 参数或表单提交等方式 “反射” 回浏览器执行。这类攻击通常需要诱导用户点击特制链接，脚本仅在用户访问该页面的瞬间触发，因此也被称为 “一次性 XSS”。

就像 DVWA 的 XSS 反射型页面，输入框接收用户输入的名字，提交后页面会直接显示 “Hello + 你的输入”。当我们输入正常的 “Bob” 时，页面会正常显示Hello Bob，但当我们尝试注入脚本时，情况就完全不同了。

DVWA 反射型 XSS 初始界面，输入正常文本 “Bob”

输入 “Bob” 后的正常响应，页面直接回显用户输入

---

二、实验：DVWA 中突破 XSS 防护

在 DVWA 的低安全等级下，服务端几乎没有对用户输入做任何过滤。我们尝试输入包含特殊字符的内容，比如<和>，可以看到这些符号被直接渲染到页面中，没有被转义。

 输入含特殊字符的文本，服务端未做转义处理

接下来我们尝试输入 XSS payload：Bob<script>alert('xss')</script>，但当我们误将script写成seript时，脚本无法执行，只会被当成普通文本输出，页面显示为Hello Bobalert('xss')。这也提醒我们，XSS 攻击需要精准的语法，同时不同安全等级的过滤规则也会影响攻击效果。

错误的 XSS payload 未触发脚本执行，直接回显到页面

要进行完整的 DVWA 实验，首先需要登录系统，进入 XSS 反射型漏洞模块：

DVWA 登录界面，使用默认账号 admin/admin 登录

同时，开发者可以通过浏览器开发者工具查看页面的 HTML 结构，分析用户输入的渲染位置，判断脚本注入的可能性：

使用浏览器开发者工具查看页面 HTML 结构，寻找 XSS 注入点

---

三、为什么 XSS 能成为客户端攻击的利器？

很多人误以为 XSS 只是弹个窗，没什么危害，这是对它最大的误解。弹窗只是验证漏洞存在的方式，攻击者真正的目标远不止于此：

1. 窃取 Cookie，伪造用户身份：通过document.cookie获取用户会话 Cookie，再发送到攻击者服务器，就能冒充用户登录账号。
2. 篡改页面内容，实施钓鱼诈骗：修改页面显示的登录表单，诱导用户输入账号密码，直接窃取敏感信息。
3. 劫持浏览器，执行恶意操作：在用户不知情的情况下，自动执行转账、发帖、修改密码等操作，甚至植入恶意程序。

---

四、WebGoat 的补充：访问控制漏洞与 XSS 的联动风险

在 Web 安全实验中，XSS 常与其他漏洞结合放大危害。比如 WebGoat 的角色访问控制实验中，普通员工 Tom 本无法执行删除用户的操作，但通过绕过访问控制的漏洞，就能调用 Staff List 的删除接口。如果再结合 XSS 攻击，攻击者可以诱导管理员点击链接，以管理员身份执行这些高危操作。

WebGoat 角色访问控制实验登录界面，用户需选择对应角色登录

普通员工 Tom 登录后，只能查看自己的员工信息：

Tom 登录后的 Staff List 页面，仅能查看自身信息

Tom 的个人资料中包含薪资、社保号等敏感数据，若被 XSS 漏洞窃取，将造成严重的信息泄露：

Tom 的个人资料页面，包含敏感员工信息

其他员工如 Larry 的资料中也包含大量隐私数据，这些都是 XSS 攻击的潜在目标：

Larry 的个人资料页面，包含更多敏感信息与纪律处分记录

这种漏洞联动的场景，正是真实攻击中常见的组合拳 —— 先通过 XSS 获取用户会话，再利用访问控制缺陷越权操作，最终造成严重的数据泄露或系统破坏。

---

五、如何防御 XSS 攻击？

从实验中我们能看到，XSS 的核心问题是服务端对用户输入的信任与处理不当。防御 XSS 可以从这几个方面入手：

• 输入过滤与输出编码：对用户输入的特殊字符（<、>、"、'等）进行转义处理，避免浏览器将其解析为 HTML 或 JavaScript 代码。
• 设置安全的 HTTP 头：启用Content-Security-Policy（CSP），限制脚本的执行来源，禁止内联脚本和 eval 执行，大幅降低 XSS 的利用成功率。
• 使用 HttpOnly Cookie：给 Cookie 添加HttpOnly属性，防止恶意脚本通过document.cookie窃取会话信息。
• 避免直接使用用户输入构建 HTML：尽量使用前端框架的模板渲染功能，避免手动拼接 HTML 字符串，减少脚本注入的机会。

---

六、实验之外的思考

XSS 漏洞的本质，是 Web 应用没有区分 “用户输入数据” 和 “可执行代码”。随着 Web 应用越来越复杂，前端框架、富文本编辑器、第三方插件都可能成为 XSS 的突破口。作为开发者，要时刻保持 “用户输入不可信” 的安全意识；作为普通用户，也要警惕陌生链接和异常的网站交互，避免成为攻击的受害者。

这些实验不仅让我们直观看到了 XSS 的攻击过程，更揭示了 Web 安全的核心逻辑：任何对用户输入的疏忽，都可能成为攻击者的突破口。理解漏洞，才能更好地防御漏洞 —— 这也是安全实验的真正意义所在。