Content Security Policy (CSP) 进阶：细粒度控制资源加载与执行

Content Security Policy (CSP) 进阶：像调鸡尾酒一样玩转网页安全

想象一下，你开了一家酒吧，名叫“安全港湾”。你的目标是让客人尽情享受，但又要确保他们不会喝到假酒、被小偷盯上，或者被一些不怀好意的人忽悠。Content Security Policy (CSP)，就像你酒吧里的一套严格的安全规章制度，它能帮你控制哪些酒（资源）可以进入你的酒吧，以及谁（脚本）可以在酒吧里表演。

CSP 的基础用法，就像在酒吧门口贴个告示：“只允许卖本地啤酒！” 这当然能提高安全性，但未免过于粗暴。如果你的客人想尝尝来自异国风情的鸡尾酒呢？如果本地乐队今天嗓子哑了，你想请个外地乐队来救场呢？这时候，你就需要更精细的调酒技巧，也就是 CSP 的进阶用法。

从“一刀切”到“私人订制”：CSP 的指令王国

CSP 并非只有简单的“允许”或“禁止”，它拥有一个强大的指令王国，每个指令都负责控制不同类型的资源。熟练掌握这些指令，你就能像调酒师一样，根据不同的场景，调配出最适合你网页的安全策略。

default-src: 这是你的“默认牌”，如果其他指令没有明确指定，就默认使用这个指令的规则。就像酒吧的默认酒水，如果你没特别要求，就给你来一杯本地啤酒。
```
Content-Security-Policy: default-src 'self';
```
这表示默认情况下，只允许加载来自同源（'self'）的资源。
script-src: 控制脚本的来源。这就像酒吧里允许哪些乐队来表演。
```
Content-Security-Policy: script-src 'self' https://cdn.example.com;
```
这条指令允许加载来自同源的脚本，以及来自 https://cdn.example.com 的脚本。这意味着你可以安全地使用 CDN 上的 JavaScript 库，比如 jQuery 或 React。
style-src: 控制样式的来源。这就像酒吧里允许哪些设计师来装修。
```
Content-Security-Policy: style-src 'self' 'unsafe-inline';
```
这条指令允许加载来自同源的样式，并且允许使用内联样式（'unsafe-inline'）。注意，'unsafe-inline' 意味着你信任你的 HTML 代码，但通常不建议使用，因为它可能会引入安全风险。
img-src: 控制图片的来源。这就像酒吧里允许展示哪些画作。
```
Content-Security-Policy: img-src 'self' data:;
```
这条指令允许加载来自同源的图片，并且允许使用 Data URI 格式的图片（data:）。Data URI 允许你将图片直接嵌入到 HTML 或 CSS 中，避免额外的 HTTP 请求。
connect-src: 控制可以连接到的服务器。这就像酒吧允许客人拨打哪些电话号码。
```
Content-Security-Policy: connect-src 'self' wss://socket.example.com;
```
这条指令允许连接到同源的服务器，以及使用 WebSocket 协议连接到 wss://socket.example.com。这对于使用 AJAX 请求数据或建立实时通信的 Web 应用非常重要。
font-src: 控制字体的来源。这就像酒吧里允许使用哪些字体的招牌。
```
Content-Security-Policy: font-src 'self' https://fonts.gstatic.com;
```
这条指令允许加载来自同源的字体，以及来自 https://fonts.gstatic.com 的字体。如果你使用了 Google Fonts，就需要添加这个指令。
frame-src: 控制可以嵌入的 <iframe> 标签的来源。这就像酒吧里允许播放哪些频道的电视节目。
```
Content-Security-Policy: frame-src 'self' https://www.youtube.com;
```
这条指令允许嵌入来自同源的 <iframe> 标签，以及来自 https://www.youtube.com 的 <iframe> 标签。这对于嵌入视频或第三方内容非常有用。
media-src: 控制音视频资源的来源。这就像酒吧里允许播放哪些音乐和视频。
```
Content-Security-Policy: media-src 'self';
```
这条指令允许加载来自同源的音视频资源。
object-src: 控制 <object>, <embed>, 和 <applet> 标签的来源。这些元素已经很少使用，但仍然存在安全风险。就像酒吧里禁止使用过时的老式设备。
```
Content-Security-Policy: object-src 'none';
```
这条指令完全禁止加载上述资源。
base-uri: 限制页面上 <base> 标签可以设置的 URL。这个标签可以改变页面上所有相对 URL 的基础路径。就像酒吧里限制客人修改酒单上的默认酒品价格。
```
Content-Security-Policy: base-uri 'self';
```
这条指令只允许 <base> 标签设置为同源的 URL。
form-action: 限制表单可以提交到的 URL。这就像酒吧里限制客人把订单送到哪些厨房。
```
Content-Security-Policy: form-action 'self' https://api.example.com;
```
这条指令允许表单提交到同源的 URL 和 https://api.example.com。

“白名单”与“黑名单”：选择你的安全策略

CSP 主要使用“白名单”机制，也就是说，你必须明确允许哪些资源可以加载，其他的都禁止。这就像在酒吧门口放一个“贵宾名单”，只有名单上的人才能进入。相比之下，“黑名单”机制是允许所有资源加载，但明确禁止一些危险的资源。虽然黑名单机制可能更方便，但安全性较低，因为很容易遗漏一些潜在的威胁。

'self'、'none'、'unsafe-inline'、'unsafe-eval'、'strict-dynamic'：CSP 的特殊关键词

除了 URL 之外，CSP 还提供了一些特殊的关键词，用于更灵活地控制资源的加载。

'self': 表示同源，也就是与当前页面具有相同的协议、域名和端口。
'none': 表示禁止加载任何资源。
'unsafe-inline': 允许使用内联脚本和样式。非常不推荐使用，因为它会增加 XSS 攻击的风险。
'unsafe-eval': 允许使用 eval() 函数和 new Function() 构造函数。同样非常不推荐使用，因为它会增加代码注入攻击的风险。
'strict-dynamic': 允许信任的脚本加载的其他脚本。这是一种更安全的方式来加载动态脚本，而不是使用 'unsafe-inline' 或 'unsafe-eval'。

nonce 与 hash：为内联脚本和样式添加“通行证”

如果你必须使用内联脚本或样式，可以使用 nonce 或 hash 来提高安全性。nonce 是一个随机字符串，你需要在 CSP 指令中指定它，并在 HTML 代码中为内联脚本或样式添加相应的 nonce 属性。hash 是内联脚本或样式的 SHA 哈希值，你需要在 CSP 指令中指定它。

例如，使用 nonce：

<script nonce="r4nd0m">
  // 你的内联脚本
</script>

Content-Security-Policy: script-src 'nonce-r4nd0m';

只有具有正确 nonce 属性的脚本才能执行。这就像给特定的客人发一个“VIP 手环”，只有戴着手环的人才能享受特殊服务。

使用 hash：

<script>
  // 你的内联脚本
</script>

Content-Security-Policy: script-src 'sha256-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx';

只有哈希值与 CSP 指令中指定的哈希值匹配的脚本才能执行。

report-uri 与 report-to：监控你的安全策略

CSP 不仅可以阻止恶意代码的执行，还可以帮助你监控你的安全策略是否有效。你可以使用 report-uri 或 report-to 指令来指定一个 URL，当 CSP 阻止了某个资源的加载时，浏览器会向这个 URL 发送一个报告。

Content-Security-Policy: default-src 'self'; report-uri /csp-report;

或者，使用 report-to：

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

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

你需要配置一个名为 csp-endpoint 的 Reporting API 端点。使用 report-to 可以提供更详细的报告信息，并且允许你使用 Reporting API 的其他功能。这就像在酒吧里安装摄像头，记录下所有可疑的行为，以便及时采取措施。

“只报告”模式：先观察，再行动

在正式启用 CSP 之前，你可以先使用“只报告”模式来测试你的安全策略。在只报告模式下，CSP 不会阻止任何资源的加载，但会向你指定的 URL 发送报告。这就像在酒吧里进行一次“安全演习”，看看哪些地方可能存在漏洞，而不会真的影响到客人的体验。

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report;

CSP 的最佳实践：精益求精，持续优化

从最严格的策略开始，逐步放宽。 就像先制定一个非常严格的酒吧规章制度，然后根据实际情况，逐步进行调整。
使用“只报告”模式进行测试。 在正式启用 CSP 之前，一定要先进行充分的测试，确保不会影响到用户的正常使用。
监控 CSP 报告。 定期查看 CSP 报告，了解哪些资源被阻止了，并根据报告调整你的安全策略。
使用工具来生成 CSP 策略。 有一些在线工具可以帮助你生成 CSP 策略，比如 CSP Generator。
保持学习和更新。 CSP 是一项不断发展的技术，你需要不断学习和更新，才能保持你的安全策略的有效性。

总结：调配你的专属安全鸡尾酒

CSP 就像一个强大的安全工具箱，它可以帮助你构建更安全的 Web 应用。通过熟练掌握 CSP 的指令和技巧，你可以像调酒师一样，根据不同的场景，调配出最适合你网页的安全鸡尾酒。记住，安全是一个持续的过程，需要不断地学习、测试和优化。只有这样，你才能真正打造一个安全可靠的“安全港湾”。

Content Security Policy (CSP) 进阶： 像调鸡尾酒一样玩转网页安全

发表回复 取消回复

Content Security Policy (CSP) 进阶：像调鸡尾酒一样玩转网页安全

发表回复取消回复