（修复方案）反射型 XSS漏洞

在处理任何来自客户端的数据时，包括 URL 参数、表单数据、HTTP 头等，都必须将其视为不可信的。修复的重点不是“输入时过滤”，而是 “输出时编码”

1. 输入验证

输入验证不能替代输出编码！它主要用于业务逻辑校验（如邮箱格式、电话号码长度），因为攻击者可能找到绕过验证的方法。输出编码是最后一道，也是最可靠的防线。

在输出之前，可以进行严格的输入验证。

• 白名单原则： 例如，只允许字母、数字和特定符号，拒绝任何不符合格式的输入。

2. 输出时编码

HTML 上下文编码

当用户输入的数据需要被输出到 HTML 页面中时（例如在<div>、<span>、<p>标签内部），必须进行 HTML 编码。

例如，Java代码的修复：

StringuserName=request.getParameter("name");// 浏览器会将 <script>alert('XSS')</script> 作为纯文本显示，而不会解析为标签StringsafeUserName=Encode.forHtml(userName);// 使用ESAPI安全库

HTML 属性上下文编码

当用户输入需要被放入 HTML 属性（如 value、href、src、onclick）时，也需要特殊处理。

• 对于普通的属性值，除了 HTML 编码外，始终用引号（单引号或双引号）将属性值括起来。
• 对于 href、src 等 URL 属性，需要进行 URL 编码，并严格验证协议（白名单，只允许 http:、https:）。

JavaScript 上下文编码

当需要将用户输入插入到<script>标签中时，这是最危险的场景之一。应避免将用户输入直接放入 JavaScript 中。

如果必须这样做，必须使用 JavaScript 编码。例如：

StringuserData=request.getParameter("data");StringsafeUserData=Encode.forJavaScript(userData);

3. 内容安全策略 (CSP)

可以通过 HTTP 头Content-Security-Policy （CSP）告诉浏览器只允许加载和执行来自特定来源的脚本、样式等资源。这样，即使网站存在 XSS 漏洞，攻击者注入的内联脚本（<script>...</script>）也不会执行，CSP 默认会阻止它们。

一个通用的 CSP 配置：

Content-Security-Policy:default-src'none';script-src'self';connect-src'self';img-src'self'data:https:;style-src'self''unsafe-inline';font-src'self';base-uri'self';form-action'self';frame-ancestors'none';object-src'none'

可以通过 Web 服务器的配置来设置这个 HTTP 头：

add_headerContent-Security-Policy"default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; font-src 'self'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'; object-src 'none';"always;

4. 使用安全的框架和库

现代 Web 开发框架（如 React, Vue, Angular）和模板引擎（如 Thymeleaf）通常内置了 XSS 防护机制。