简述什么是反射XSS漏洞

一个用户在某论坛发帖，简述帖子内容里藏着一小段JavaScript代码。什反射另一个用户点开这个帖子，漏洞浏览器弹出一个伪造的简述登录框，输入密码后，什反射密码被悄悄发送到攻击者的漏洞服务器。整个过程，简述论坛服务器本身没有被攻破，什反射数据库没有被拖走，漏洞漏洞出在“输出”环节——这就是简述反射型XSS。

反射XSS的什反射触发路径很直白：攻击者构造一个包含恶意脚本的URL，诱导受害者点击。漏洞服务器接收到这个URL参数后，简述没有经过严格过滤，什反射直接把它拼进HTML页面返回给浏览器。漏洞浏览器解析HTML时，脚本跟着执行。因为脚本来自“当前页面”，浏览器完全信任它，可以读取cookie、篡改页面内容、劫持会话。

一个典型的例子是搜索功能。你搜索“<script>alert(1)</script>”，如果网站直接把搜索关键词回显在结果页里且不转义，脚本就会执行。攻击者会把这种链接缩短伪装，发到群里：“快看这个搜索结果，太搞笑了”。点开的人，cookie就被偷了。

关键差异在于“反射”二字。它不像存储型XSS那样把恶意代码持久化存在服务器上，而是“反射”在单次请求响应里。攻击者必须诱骗受害者点击精心构造的链接，没法被动等用户自己上钩。这决定了它的利用场景多为钓鱼、社工，配合短链接和跳转绕过，受害者很难察觉URL里的猫腻。

有人觉得，现在主流框架都自带转义，反射XSS应该快绝迹了。现实没那么乐观。我见过某银行网银的转账备注字段，后端用Java的String.replace只替换了<script>标签，没处理事件属性，结果<img src=x onerror=alert(1)>照样执行。还有一次，某政府网站JSONP接口把callback参数直接输出，连引号都不加，构造个callback=alert(1)//就能弹窗。这类问题往往藏在老系统、边缘业务、或者开发图省事手拼HTML的角落。

检测反射XSS有个土办法：把提交参数改成'';!--"<XSS>=&{ ()}，看响应里哪些字符原样返回。但真正的难点不在找，而在修——输出编码必须根据上下文区分：HTML标签里、属性里、JavaScript字符串里、CSS里，编码规则完全不同。一个通用转义函数打天下，迟早出漏子。

最让人头疼的是DOM型反射XSS，它不经过服务器，纯前端JavaScript读取URL参数后直接操作DOM。这类漏洞在扫描器里经常是盲区，因为服务器响应是干净的，恶意代码只在浏览器端动态生成。比如某个单页应用用location.hash做路由，再把hash值插进页面标题，没做任何校验。

说句实话，反射XSS在漏洞圈子里有点“低端”标签，但它的实际危害不低。结合BeEF这类工具，一个反射XSS就能控制受害者浏览器做内网探测、键盘记录、钓鱼页面替换。尤其在企业内网，只要有人点了带有反射XSS的OA系统链接，攻击者就能在内部网络里站稳脚跟。

修复思路其实很朴素：第一，对所有输出到HTML的内容做上下文感知编码；第二，设置CSP（内容安全策略）禁止内联脚本执行；第三，给cookie加HttpOnly属性，就算脚本注入也拿不到会话凭证。三条都做到，反射XSS基本就废了。可现实是，很多开发连第一条都懒得做，总觉得自己写的代码不会被用户拿来做输入。

这玩意儿本质上是个信任问题——服务器不该信任用户输入，浏览器不该信任服务器输出。可惜，这两个环节总有一个偷懒。