跨站脚本攻击如何防御？

本文目录导读：

1. 输出编码（最关键）
2. 输入验证与过滤
3. 使用HTTP头安全策略
4. 其他防御手段
5. 针对特定类型XSS的注意点
6. 防御优先级

跨站脚本攻击（XSS）是一种常见的Web安全漏洞，攻击者通过在网页中注入恶意脚本，当其他用户浏览该页面时，脚本会在用户的浏览器中执行，从而窃取信息、篡改页面或进行其他恶意操作，防御XSS的核心原则是对所有不可信数据进行严格的输入验证和输出编码,以下是具体的防御措施：

输出编码（最关键）

在将用户输入的数据输出到HTML页面时，根据不同的上下文进行编码,让浏览器将其解释为数据而非代码。

• HTML实体编码：对 <、>、、、& 等特殊字符进行转义。
  • 示例：<script> 变为 <script>
• JavaScript上下文编码：在JavaScript字符串中插入用户数据时，必须对引号、换行符等特殊字符进行转义。
• CSS上下文编码：在CSS中输出用户数据时，需转义特殊字符（如url()中的引号）。
• URL编码：在URL参数中插入用户数据时，使用 encodeURIComponent() 进行编码。

使用成熟的库：前端框架（React、Vue、Angular）默认会对模板中的变量进行转义；后端语言也有内置函数（如PHP的htmlspecialchars()、Java的StringEscapeUtils.escapeHtml4()）。

输入验证与过滤

• 白名单机制：仅允许预期格式的输入（如只允许字母数字的昵称、特定格式的日期）。
• 黑名单过滤：过滤掉危险的标签（如 <script>、<iframe>、<img> 的 onerror 属性），但黑名单容易被绕过,建议仅作为辅助措施。
• 数据类型强制：例如期望数字就强转为整数,期望邮箱就验证格式。

注意：输入验证不能完全依赖，因为某些场景下需要允许用户输入HTML标签（如富文本编辑器）,此时必须结合更严格的过滤。

使用HTTP头安全策略

• Content-Security-Policy（内容安全策略，CSP）：通过HTTP响应头 Content-Security-Policy 限制页面可以加载的资源来源。
  • 示例：Content-Security-Policy: default-src 'self'; script-src 'self' 表示只允许从同源加载脚本，禁止内联脚本和 eval()。
  • 可以有效防御即使存在注入点也无法执行恶意脚本。
• X-XSS-Protection：旧版浏览器支持（如IE），设置 1; mode=block 可启用反射型XSS过滤器（现代浏览器已逐步废弃，建议用CSP替代）。

其他防御手段

• HttpOnly Cookie：设置Cookie的 HttpOnly 属性，禁止JavaScript访问Cookie,即使存在XSS也能保护会话信息。
• 使用安全的框架/库：避免直接拼接HTML字符串，使用React、Vue等框架的模板引擎,它们自动处理输出编码。
• 开发时的代码审查：在代码上线前使用自动化工具（如ESLint、SonarQube）扫描潜在XSS风险。
• 现代前端特性：
  • 使用 innerText 代替 innerHTML（除非明确需要渲染HTML）。
  • 在jQuery中避免使用 .html() 直接插入用户数据，优先使用 .text()。

针对特定类型XSS的注意点

• 反射型XSS：通常通过URL参数注入,防御时要对请求参数进行输出编码。
• 存储型XSS：数据存储在服务器端，防御时要对数据库取出的数据进行输出编码（即使之前已经验证过）。
• DOM型XSS：前端JavaScript直接修改DOM时触发，防御时需确保不将用户输入直接传给 eval()、document.write()、innerHTML 等危险函数。

防御优先级

1. 输出编码 是底线，必须对所有输出到HTML/JS/URL/CSS的用户数据做编码。
2. CSP 作为强有力的保险,即使编码遗漏也能阻止大部分攻击。
3. 输入验证 减少攻击面,但不能完全信任。
4. HttpOnly Cookie 保护关键认证信息。
5. 使用安全框架 降低开发人员犯错概率。

没有100%安全的系统，但通过多层防御（深度防御）,可以极大降低XSS风险。