xss反射型漏洞：一次点击，射型数据就没了

朋友发来一条链接，漏洞看着像某银行的射型登录页，域名也对，漏洞页面也像。射型他点了一下，漏洞输入账号密码，射型然后页面跳回首页。漏洞他没在意，射型三天后银行卡里少了八千。漏洞这不是射型钓鱼网站，是漏洞反射型XSS。

反射型XSS的射型核心就一句话：你提交的数据，被网页原样吐出来，漏洞还带着脚本执行。射型攻击者把恶意代码塞进URL参数里，服务端不校验、不转义，直接拼进HTML返回给浏览器。浏览器以为这是页面自己的脚本，乖乖执行。整个过程，服务器只是面镜子，反射的是用户自己的输入。

拿个具体例子说。某论坛搜索框，输入``，搜索结果页直接弹出你当前的Cookie。这看着无害，但攻击者会把这段代码编码后塞进短链接，发到群里。你一点，Cookie就发到了他的服务器。更狠的是，他可以用你的Cookie直接登录你的账号，改密码、看私信、发帖，你毫无察觉。

这漏洞最阴的地方在于，受害者是自己“主动”触发的。不像存储型XSS，攻击者先把代码存在服务器上，等别人来看。反射型必须诱导用户点击特定链接，所以它常和钓鱼、社工配合。攻击者会伪装成“系统升级通知”“中奖验证”，让你在打开的页面里填敏感信息，其实脚本早就在后台偷数据了。

我见过一个真实案例。某电商平台的优惠券页面，参数`couponId`直接拼进页面标题。攻击者构造了个恶意链接，把`couponId`改成`">`，发给用户。用户一点，弹窗提示“系统异常”，但后台脚本已经把用户的收货地址、手机号全传走了。更可怕的是，这种攻击不需要任何权限，普通访客就能触发。

为什么到现在还有大量网站中招？说白了，开发时图省事。很多框架默认做了转义，但总有人图方便，用`innerHTML`直接插值，或者后端用字符串拼接响应。另一个原因是，反射型XSS往往不危害服务器本身，只坑用户，所以很多公司把它当低危漏洞，修起来优先级不高。可对用户来说，账号被盗、资金损失，这能算低危吗？

防御手段其实不复杂，但执行起来要较真。前端要对所有动态插入内容做HTML实体编码，`<`变`<`，`>`变`>`，`"`变`"`。后端在返回任何用户可控数据前，统一做转义，别信输入，也别信框架的默认配置。关键位置加CSP头，限制脚本只能从白名单域名加载。还有，别用`eval`，别用`document.write`，这些是老生常谈，但每次漏洞复盘，总能翻出这些老代码。

我测试过不少站点，反射型XSS的排查其实不难。用浏览器的开发者工具，把参数改成`

最后说个反直觉的事。很多人以为HTTPS能防XSS，其实防不了。HTTPS只保证传输加密，不保证内容安全。页面里该执行脚本还是执行。真正有效的，是开发时养成“所有输出都转义”的习惯，以及定期用自动化扫描器检查每个参数点。别等到用户的钱没了，才想起来补洞——那时候，损失的不只是数据，还有信任。