如何在IIS中配置Content-Security-Policy响应头？

Question

如何在IIS中通过web.config正确配置Content-Security-Policy响应头以防止XSS攻击？常见问题包括：CSP指令语法错误、多个策略冲突、未覆盖所有资源类型（如script-src、img-src、style-src等），以及使用HTTP模块或URL重写时策略被覆盖。此外，开发人员常忽略对内联脚本和eval()的限制，导致策略失效。如何在不破坏现有功能的前提下，逐步启用严格策略并记录违规行为（通过report-uri或report-to）？

Answer 1

1. 理解Content-Security-Policy（CSP）的基本概念与作用

Content-Security-Policy（内容安全策略，简称CSP）是一种HTTP响应头，用于帮助防御跨站脚本攻击（XSS）、点击劫持和其他代码注入攻击。通过定义哪些资源可以被加载和执行，CSP能有效限制浏览器只信任指定来源的内容。

CSP通过在HTTP响应中添加Content-Security-Policy头来实现控制。例如：

Content-Security-Policy: default-src 'self'; script-src 'self'; img-src 'self'; style-src 'self';

该策略表示所有资源默认只能从同源加载，禁止内联脚本、eval()调用及动态代码执行。

在IIS环境中，CSP通常通过web.config文件中的<httpProtocol>节或URL重写模块进行配置。

2. 在IIS中通过web.config配置CSP响应头

要在IIS中设置CSP，需在应用的web.config文件中添加自定义HTTP响应头。以下是标准配置方式：

<configuration>
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Content-Security-Policy" 
             value="default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self';">
        </add>
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

上述配置设置了基本的安全策略，包括禁止外部脚本、插件对象、框架嵌套等。

注意：'none'表示不允许任何来源，'self'指同源（相同协议、域名、端口）。

3. 常见配置问题及其分析

• 语法错误：如遗漏分号、引号不匹配、使用非法关键字（如unsafe-inline拼错）。
• 多个策略冲突：若同时使用URL重写模块或其他HTTP模块设置CSP，可能导致策略叠加或覆盖。
• 未覆盖关键资源类型：仅设置script-src而忽略style-src、img-src、font-src等，导致策略不完整。
• 内联脚本与eval()未禁用：开发者常因兼容旧代码保留'unsafe-inline'或'unsafe-eval'，削弱防护能力。
• HTTP模块覆盖CSP头：某些第三方模块（如身份验证中间件）可能在管道后期修改响应头，导致CSP失效。

4. 使用report-uri与report-to记录违规行为

为避免直接启用严格策略导致功能中断，推荐先启用报告模式。可通过Content-Security-Policy-Report-Only头进行非阻断式监控：

<add name="Content-Security-Policy-Report-Only" 
     value="default-src 'self'; report-uri /csp-report-endpoint;" />

或者现代浏览器支持的report-to指令：

Content-Security-Policy: default-src 'self'; report-to csp-endpoint;

服务器需配置接收报告的端点（如/csp-report-endpoint），并记录JSON格式的违规详情，便于分析潜在风险。

5. 逐步升级策略：从宽松到严格的迁移路径

阶段	策略级别	典型配置	目的
1	报告模式	script-src 'self'; report-uri /csp	收集违规日志，识别依赖项
2	允许data:	img-src 'self' data:	兼容Base64图片
3	移除unsafe-inline	script-src 'self'	强制外部化脚本
4	完全严格	default-src 'none'; script-src 'self'; ...	最小权限原则

6. 处理内联脚本与动态代码执行的替代方案

许多遗留系统依赖内联JavaScript或eval()，直接禁用会导致页面崩溃。可行解决方案包括：

1. 将内联脚本迁移至独立.js文件；
2. 使用Nonce机制：script-src 'self' 'nonce-random123'，并在每个<script>标签添加nonce="random123"；
3. 采用Hash白名单：script-src 'self' 'sha256-...' ，对静态脚本内容生成SHA-256哈希；
4. 替换eval()为Function构造函数或预编译模板引擎。

7. 避免策略被其他模块覆盖的技术实践

当使用URL重写模块或ASP.NET HTTP模块时，CSP头可能被后续处理覆盖。可通过以下方式确保优先级：

<rewrite>
  <outboundRules>
    <rule name="Set CSP Header">
      <match serverVariable="RESPONSE_Content_Security_Policy" pattern=".*" />
      <action type="Rewrite" value="default-src 'self'; script-src 'self'" />
    </rule>
  </outboundRules>
</rewrite>

此方法利用IIS URL Rewrite模块的outboundRules显式设置响应头，避免被其他组件干扰。

8. 完整示例：生产环境推荐CSP配置

<customHeaders>
  <add name="Content-Security-Policy" 
       value="
         default-src 'none';
         script-src 'self' 'unsafe-hashes' 'nonce-{RANDOM}' sha256-abcdef...;
         style-src 'self' 'unsafe-inline';
         img-src 'self' data:;
         font-src 'self';
         connect-src 'self';
         base-uri 'self';
         form-action 'self';
         frame-ancestors 'none';
         object-src 'none';
         report-uri /csp-violation-report
       ".Replace(" ", "").Replace("\n", " ") />
</customHeaders>

注：实际部署中应动态生成nonce值，并移除'unsafe-inline'以提升安全性。

9. 监控与持续优化流程图

graph TD A[启用Report-Only模式] --> B{收集违规报告} B --> C[分析日志中的资源来源] C --> D[分类：合法需求 or 潜在攻击?] D -->|合法| E[调整CSP策略白名单] D -->|恶意| F[加强过滤规则] E --> G[切换至正式CSP策略] G --> H[定期审计与更新策略] H --> I[集成CI/CD自动化检测]

10. 最佳实践总结与扩展建议

为确保CSP长期有效运行，建议：

• 结合SRI（Subresource Integrity）验证第三方库完整性；
• 使用CSP Evaluator工具（Google提供）检查策略强度；
• 在开发、测试、生产环境分阶段部署；
• 建立自动化告警机制，当日志中出现高频违规时触发通知；
• 文档化所有例外情况，便于审计追踪；
• 培训前端团队遵循安全编码规范，减少对内联脚本的依赖；
• 定期审查第三方服务（如CDN、分析脚本）的引入必要性；
• 考虑使用CSP 3.0新特性如trusted-types防御DOM-based XSS；
• 配合X-XSS-Protection（虽已废弃但兼容旧浏览器）与X-Content-Type-Options增强纵深防御；
• 将CSP纳入DevSecOps流程，实现安全左移。