JS `Content Security Policy (CSP)` `Strict-CSP` 与 `Nonce` / `Hash` 机制

各位观众，各位朋友，大家好！欢迎来到今天的CSP安全小课堂！我是你们的老朋友，代码界的段子手，安全领域的搬运工。今天咱们不聊八卦，只聊“防身术”——Content Security Policy (CSP)。

别看CSP这名字挺高大上，其实说白了，它就是浏览器的一道安全防线，专门用来对付那些XSS攻击，让你的网站免受恶意脚本的侵害。想象一下，你的网站就像一座城堡，CSP就是城墙上的守卫，时刻警惕着那些想偷偷溜进来的坏人。

今天，咱们要重点聊聊CSP的“升级版”——Strict-CSP，以及它背后的两大秘密武器：Nonce和Hash。准备好了吗？系好安全带，咱们发车！

一、 CSP：基础入门，了解游戏规则

在深入了解Strict-CSP之前，咱们先来回顾一下CSP的基础知识。CSP本质上是一个HTTP响应头，告诉浏览器哪些资源（脚本、样式、图片等等）可以加载，哪些不能加载。

语法结构大概长这样：

Content-Security-Policy: <指令1> <值1>; <指令2> <值2>; ...

其中，<指令> 定义了资源类型，比如 script-src（脚本来源）、style-src（样式来源）等等，<值> 则指定了允许加载资源的来源地址。

举个例子：

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline';

这段CSP策略的意思是：

default-src 'self': 默认情况下，只允许加载来自相同来源的资源。
script-src 'self' https://cdn.example.com: 允许加载来自相同来源和 https://cdn.example.com 的脚本。
style-src 'self' 'unsafe-inline': 允许加载来自相同来源的样式，并且允许使用内联样式（style 标签）。

常用指令表格：

指令	描述
`default-src`	定义了所有资源类型的默认策略。如果某个资源类型没有单独的指令，就使用 `default-src` 的策略。
`script-src`	定义了允许加载脚本的来源。
`style-src`	定义了允许加载样式的来源。
`img-src`	定义了允许加载图片的来源。
`connect-src`	定义了允许建立连接的来源（例如，XMLHttpRequest、WebSocket）。
`font-src`	定义了允许加载字体的来源。
`media-src`	定义了允许加载媒体文件的来源（例如，`<audio>`、`<video>`）。
`object-src`	定义了允许加载插件的来源（例如，`<object>`、`<embed>`、`<applet>`）。
`base-uri`	定义了允许使用的 `<base>` 标签的 URL。
`form-action`	定义了允许提交表单的 URL。
`frame-ancestors`	定义了允许嵌入当前页面的来源（例如，`<iframe>`、`<frame>`、`<object>`）。这可以防止点击劫持攻击。
`upgrade-insecure-requests`	指示浏览器将所有 HTTP URL 升级为 HTTPS。
`block-all-mixed-content`	阻止加载任何混合内容（HTTPS 页面加载 HTTP 资源）。
`report-uri`	指定一个 URL，当 CSP 策略被违反时，浏览器会向该 URL 发送报告。
`report-to`	指定一个配置对象，当 CSP 策略被违反时，浏览器会向该配置对象定义的端点发送报告。`report-to` 比 `report-uri` 更强大，可以配置多个报告端点，并支持浏览器优化报告过程。

‘unsafe-inline’ 和 ‘unsafe-eval’ 的坑：

'unsafe-inline'：允许使用内联脚本和内联样式。这非常危险，因为攻击者可以轻松地通过 XSS 注入恶意脚本或样式。
'unsafe-eval'：允许使用 eval() 函数和类似的动态代码执行机制。这也会引入安全风险，因为攻击者可以利用这些机制执行任意代码。

所以，除非万不得已，尽量避免使用 'unsafe-inline' 和 'unsafe-eval'。

二、 Strict-CSP：更严格的安全策略，杜绝后患

Strict-CSP 可以理解为 CSP 的一种最佳实践，它旨在消除 CSP 配置中的常见漏洞，提供更强大的安全保护。Strict-CSP 的核心思想是：

禁用 'unsafe-inline' 和 'unsafe-eval': 这两条指令是XSS攻击的温床，必须坚决禁用。
使用 Nonce 或 Hash: 用随机数 (Nonce) 或哈希值 (Hash) 来标记可信的内联脚本和样式。
明确声明资源来源: 避免使用通配符 *，明确指定允许加载资源的来源。

三、 Nonce：随机数，一次一密

Nonce（Number used once）是一个随机生成的字符串，每次页面加载时都会生成一个新的 Nonce 值。你需要在 CSP 策略中指定允许加载的 Nonce 值，并在 HTML 代码中为需要加载的内联脚本和样式添加对应的 Nonce 属性。

工作原理：

服务器生成 Nonce: 在服务器端生成一个随机的 Nonce 值。
设置 CSP 头: 将 Nonce 值添加到 CSP 策略中，例如 script-src 'nonce-<nonce-value>'。
添加到 HTML: 将 Nonce 值添加到 HTML 代码中的 <script> 和 <style> 标签中，例如 <script nonce="<nonce-value>">...</script>。

代码示例 (Node.js + Express):

const express = require('express');
const crypto = require('crypto');

const app = express();

app.get('/', (req, res) => {
  const nonce = crypto.randomBytes(16).toString('base64'); // 生成随机 Nonce 值

  // 设置 CSP 头部
  res.setHeader(
    'Content-Security-Policy',
    `default-src 'self'; script-src 'self' 'nonce-${nonce}'; style-src 'self' 'nonce-${nonce}';`
  );

  // 构造 HTML 内容
  const html = `
    <!DOCTYPE html>
    <html>
    <head>
      <title>CSP Example</title>
      <style nonce="${nonce}">
        body {
          background-color: #f0f0f0;
        }
      </style>
    </head>
    <body>
      <h1>Hello, CSP!</h1>
      <script nonce="${nonce}">
        console.log('This script is allowed!');
      </script>
    </body>
    </html>
  `;

  res.send(html);
});

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});

在这个例子中，我们使用 crypto.randomBytes(16).toString('base64') 生成了一个随机的 Nonce 值，然后将其添加到 CSP 头部和 HTML 代码中。只有具有正确 Nonce 值的内联脚本和样式才能被加载，其他的都会被浏览器阻止。

Nonce 的优点：

安全性高: 每次页面加载都会生成新的 Nonce 值，即使攻击者成功注入了恶意脚本，也无法轻易绕过 CSP 策略。
易于实现: Nonce 的实现相对简单，只需要在服务器端生成随机数，并将其添加到 CSP 头部和 HTML 代码中即可。

Nonce 的缺点：

动态性: Nonce 的值是动态变化的，需要在服务器端进行管理，并确保每次页面加载时都能生成新的 Nonce 值。
缓存问题: 由于 Nonce 值是动态变化的，可能会影响页面的缓存。你需要确保缓存策略能够正确处理 Nonce 值。

四、 Hash：哈希值，精确匹配

Hash 是一种基于内容的验证机制。它通过计算内联脚本和样式的哈希值，并在 CSP 策略中指定允许加载的哈希值。只有哈希值匹配的内联脚本和样式才能被加载。

工作原理：

计算哈希值: 计算内联脚本和样式的哈希值（常用的哈希算法有 SHA256、SHA384、SHA512）。
设置 CSP 头: 将哈希值添加到 CSP 策略中，例如 script-src 'sha256-<hash-value>'。
添加到 HTML: 不需要修改 HTML 代码。

代码示例：

假设我们有以下内联脚本：

<script>
  console.log('This script is allowed!');
</script>

我们需要计算这段脚本的 SHA256 哈希值。可以使用在线工具或者命令行工具（例如 openssl）来计算：

echo -n "console.log('This script is allowed!');" | openssl dgst -sha256 -binary | openssl base64

输出结果（可能不同，取决于你的环境）：

Ku5E2T892w8i/0+j1n78E5x0h2p9E1l/lX0b0zM8q8=

然后，我们可以将哈希值添加到 CSP 头部：

Content-Security-Policy: default-src 'self'; script-src 'self' 'sha256-Ku5E2T892w8i/0+j1n78E5x0h2p9E1l/lX0b0zM8q8='

Hash 的优点：

静态性: 哈希值是基于内容的，只要内容不变，哈希值就不会变。这使得 Hash 非常适合于静态资源。
无需服务器端管理: Hash 不需要服务器端生成和管理随机数，简化了部署和维护。

Hash 的缺点：

灵活性差: 如果内联脚本或样式的内容发生变化，哈希值也会发生变化，你需要重新计算哈希值并更新 CSP 策略。
计算成本: 计算哈希值需要一定的计算成本，特别是对于大型的脚本和样式。

五、 Nonce vs Hash：选择困难症？

Nonce 和 Hash 各有优缺点，那么在实际应用中，我们应该如何选择呢？

特性	Nonce	Hash
动态性	动态，每次页面加载都会生成新的值	静态，基于内容计算得出
易用性	需要服务器端生成和管理随机数	无需服务器端管理
适用场景	适用于需要动态更新的内联脚本和样式	适用于静态的内联脚本和样式
安全性	每次页面加载都会生成新的 Nonce 值，安全性高	如果攻击者能够篡改脚本内容，则可能绕过 CSP 策略
缓存	可能影响缓存，需要特殊处理	对缓存友好

我的建议是：

优先使用 Nonce: 如果你的网站需要动态更新内联脚本和样式，或者你对安全性要求很高，那么 Nonce 是一个更好的选择。
静态内容使用 Hash: 对于那些很少变化的静态内联脚本和样式，可以使用 Hash。
混合使用: 你也可以将 Nonce 和 Hash 结合起来使用。例如，对于动态生成的内联脚本，使用 Nonce；对于静态的内联脚本，使用 Hash。

六、 Strict-CSP 的最佳实践

从 Report-Only 模式开始: 在正式启用 Strict-CSP 之前，先使用 Report-Only 模式进行测试。Report-Only 模式不会阻止资源的加载，而是将违反 CSP 策略的行为报告到指定的 URL。这可以帮助你发现潜在的问题，并避免对用户体验造成影响。
```
Content-Security-Policy-Report-Only: <你的 CSP 策略>; report-uri <报告 URL>
```
逐步加强策略: 不要一开始就设置过于严格的 CSP 策略。可以先从一个宽松的策略开始，然后逐步加强，直到达到你期望的安全级别。
监控 CSP 报告: 定期查看 CSP 报告，了解哪些资源被阻止，并根据报告调整你的 CSP 策略。
使用 CSP 构建工具: 有一些工具可以帮助你生成和管理 CSP 策略，例如 Google 的 CSP Evaluator。
保持更新: CSP 规范在不断发展，你需要定期关注最新的 CSP 特性和最佳实践，并更新你的 CSP 策略。

七、常见问题解答 (FAQ)

Q: 我的 CSP 策略太严格了，导致网站无法正常工作怎么办？

A: 首先，检查你的 CSP 报告，看看哪些资源被阻止了。然后，逐步放宽你的 CSP 策略，直到网站能够正常工作。记住，安全和可用性之间需要找到一个平衡点。
*Q: 我可以使用通配符 `` 来匹配所有来源吗？**

A: 不建议使用通配符 *，因为它会降低 CSP 的安全性。尽量明确指定允许加载资源的来源。
Q: 我应该如何处理第三方脚本？

A: 如果可以，尽量避免使用第三方脚本。如果必须使用，确保你信任这些脚本的来源，并将其添加到你的 CSP 策略中。
Q: 我的网站使用了大量的内联脚本和样式，我应该如何迁移到 Strict-CSP？

A: 这是一个挑战，你需要逐步将内联脚本和样式移到外部文件中，并使用 Nonce 或 Hash 来保护那些无法避免的内联代码。

八、总结

好了，今天的CSP安全小课堂就到这里了。希望通过今天的讲解，大家对 Strict-CSP、Nonce 和 Hash 有了更深入的了解。记住，安全是一个持续的过程，我们需要不断学习和实践，才能保护我们的网站免受恶意攻击。

希望大家都能成为自己网站的“安全卫士”，让XSS攻击无处遁形！下次再见！

发表回复 取消回复

发表回复取消回复