反射型XSS漏洞修复，反射本质上就是型x修复一个“输入输出处理”的问题，但很多人偏偏在这上面栽跟头。漏洞上个月我审计一个后台管理系统，反射开发者把搜索关键词原样回显在页面上，型x修复payload `` 直接弹窗，漏洞连过滤都没做。反射这还不是型x修复最离谱的，最离谱的漏洞是开发跟我说“我加了htmlspecialchars了”——结果他只在输出时转义了双引号，单引号没处理，反射攻击者用`onmouseover='alert(1)'`照样绕过。型x修复

修复反射型XSS，漏洞核心就两条路：一是反射对输出做上下文感知的编码，二是型x修复对输入做严格白名单校验。但第二条路有个坑——你永远不知道数据会流向哪个上下文。漏洞同一个参数，可能出现在HTML标签内、属性值里、JavaScript代码中，甚至是CSS的url()里。每个地方的编码规则都不一样，你按HTML实体编码处理了，放进``，这时候你得用`encodeForJavaScript()`，而不是HTML编码。我见过有人把HTML实体编码后的字符串直接塞进JS里，结果`"`在JS解析时变成了引号，照样被注入。

还有个容易被忽视的细节：HTTP响应头里的`Content-Type`和`X-Content-Type-Options`。有些老系统返回`text/html`却带着用户可控的`charset`参数，攻击者可以用UTF-7编码绕过你的过滤。修复方法很简单，固定响应头为`Content-Type: text/html; charset=utf-8`，再加一句`X-Content-Type-Options: nosniff`，让浏览器别自作聪明去猜编码。

实战里我建议搞一套“三层防御”的土办法。第一层，在框架入口统一做输入长度限制和基础过滤，去掉`<>`和引号——这层防的是新手攻击者。第二层，每个输出点根据上下文选择正确的编码函数，这层防的是绕过过滤器的老手。第三层，上线前用自动化工具扫一遍所有带参数的回显点，比如用Burp的Active Scan，盯着反射型XSS的告警看。三层都过了，基本就稳了。

最后说个反直觉的操作——有时候修复XSS的最佳方案是“不输出”。有些参数只是为了服务端逻辑用的，比如分页页码、排序字段，压根没必要回显到页面上。把这些参数从URL参数改成POST提交，或者存到服务端Session里，前端只显示处理后的结果，攻击面直接砍掉一半。别总想着怎么过滤，先想想这个数据是不是非得出现在响应里。

(责任编辑：知识)