XSS漏洞修复方法

上周帮朋友排查一个后台管理系统，洞修用户反馈“在昵称框输入，复方法保存后每次打开页面都弹窗”。洞修我一看代码，复方法直接把用户输入拼进了HTML输出，洞修连个转义都没做。复方法这种问题在中小型项目里太常见了——修起来其实不难，洞修难的复方法是开发者根本没意识到自己写了个“后门”。

XSS的洞修本质就一句话：用户输入被当成了代码执行。修复思路也简单，复方法要么让输入“无害化”，洞修要么让输出“安全化”，复方法两条路走通一条，洞修漏洞就堵死了。复方法

第一招：输出编码（最基础，洞修必须做）

拿PHP举例，很多人喜欢这样写：echo "你好，".$_GET['name'];。这等于把用户给的任何东西直接扔进HTML。正确做法是：echo "你好，".htmlspecialchars($_GET['name'], ENT_QUOTES, 'UTF-8');。htmlspecialchars会把<、>、引号这些特殊字符转成实体，浏览器渲染时只当文本，不执行。

但注意，输出编码要看“上下文”。同样一段数据，放在HTML标签里、放在JavaScript代码里、放在URL参数里，需要的编码方式完全不同。比如内联事件onclick="alert('...')"，你得用JavaScript的十六进制转义，光靠htmlspecialchars根本不够。所以别指望一个函数通吃所有场景——这是很多人栽跟头的地方。

第二招：输入过滤（别太信任，但别过度）

有的团队喜欢“黑名单”过滤，把script、onerror、javascript:这些词全ban掉。我见过最狠的，直接删掉所有“<”和“>”字符，结果用户没法输入数学公式“a

更靠谱的是“白名单”思路：明确允许什么，其他一律拒绝。比如昵称字段只允许中英文、数字和下划线，用正则一匹配，非法输入直接报错。这样既安全又不会误伤正常用户。但白名单只能处理结构化数据，对富文本内容（比如博客正文）就无能为力了——那得用专业的富文本过滤库，比如DOMPurify，用浏览器DOM解析后再移除危险节点。

第三招：CSP（内容安全策略）——最后一道防线

就算前两招都漏了，CSP还能兜底。在HTTP响应头里加一句Content-Security-Policy: default-src 'self'; script-src 'self'，浏览器就会拒绝执行任何外部加载的脚本，内联脚本也默认禁用（除非加nonce）。这相当于告诉浏览器：“这页面只信任我自己写的代码，其他的一律不跑。”

有个真实案例：某电商网站被注入了一段恶意脚本，用来窃取用户cookie。因为CSP配置了script-src 'self'，注入的脚本无法执行，攻击直接失败。事后查日志才发现，漏洞确实存在，但CSP把危害降到了零。

别忘了这些细节

修复XSS不只是改几行代码的事。Cookie设置HttpOnly属性，让JavaScript读不到document.cookie——就算XSS成功，攻击者拿不到会话凭证。还有，别把用户上传的文件名直接拼进HTML的src属性里，文件名里可能藏着“">