分析 `Content-Security-Policy` (CSP) 的 `nonce` 和 `hash` 机制如何提升 `XSS` 防御能力。 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位观众，各位听众，大家好！我是今天的主讲人，很高兴能和大家一起聊聊 Content-Security-Policy (CSP) 中，那些看似神秘却威力巨大的 nonce 和 hash 机制。

今天咱们的主题是：CSP 的 nonce 和 hash：XSS 防御界的“矛”与“盾”。

先别被标题吓跑，保证不讲那些让你打瞌睡的官方文档式描述，咱们用大白话，配合代码示例，把这俩哥们儿的底裤都扒下来，看看他们是如何帮我们抵御 XSS 攻击的。

XSS 攻击：Web 安全的头号公敌

在深入 nonce 和 hash 之前，咱们先快速回顾一下 XSS（Cross-Site Scripting）攻击。简单来说，XSS 就像一个潜伏在你家里的间谍，它悄悄地把恶意代码注入到你信任的网站里，当用户访问这个被污染的网站时，恶意代码就会在用户的浏览器上执行，窃取用户的信息，或者冒充用户执行某些操作。

举个栗子：

假设你的网站有个搜索功能，用户可以输入关键词进行搜索。如果你没做好安全过滤，攻击者就可以输入类似这样的恶意代码作为关键词：

<script>alert('XSS!')</script>

当你网站把这个关键词显示在页面上时，浏览器会把它当成真正的 JavaScript 代码执行，弹出一个 "XSS!" 的对话框。这只是个简单的例子，实际攻击可能远比这复杂和危险。

CSP：给你的网站穿上防弹衣

为了对抗 XSS 攻击，W3C 组织推出了 CSP（Content-Security-Policy），它可以让你明确告诉浏览器，哪些来源的内容是可信的，哪些来源的内容是应该被禁止的。就像给你的网站穿上了一件防弹衣，只有符合规则的内容才能进入，其他的一律拦截。

CSP 的配置方式有很多种，最常见的是通过 HTTP 响应头来设置。比如：

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

这条 CSP 规则的意思是：

default-src 'self': 默认情况下，只允许加载来自相同域名（’self’）的资源。
script-src 'self': 只允许加载来自相同域名的 JavaScript 代码。

有了这条规则，即使攻击者成功注入了 <script>alert('XSS!')</script>，浏览器也会因为这段代码不是来自相同域名而拒绝执行。

但是，问题来了：如果我们想要在页面中嵌入一些第三方 JavaScript 代码，比如 Google Analytics，或者 jQuery CDN，该怎么办呢？难道要把所有第三方域名都添加到 script-src 里面吗？这显然不现实，因为我们无法保证所有第三方域名都是安全的。

这时候，nonce 和 hash 就派上用场了。它们就像 CSP 防弹衣上的两个高级定制选项，可以让我们更精确地控制哪些内联脚本可以执行。

nonce：一次性密码，精确打击

nonce 的英文意思是 "number used once"，顾名思义，它是一个只能使用一次的随机字符串。我们可以给每一个允许执行的内联脚本都加上一个 nonce 属性，然后在 CSP 规则中指定这个 nonce 值。这样，浏览器就只会执行那些带有正确 nonce 值的脚本。

举个栗子：

假设你的服务器生成了一个随机的 nonce 值：abcdefg

你的 HTML 代码可能是这样的：

<script nonce="abcdefg">
  console.log("Hello from inline script!");
</script>

然后在 HTTP 响应头中设置 CSP 规则：

Content-Security-Policy: script-src 'nonce-abcdefg'

这条规则的意思是：只允许执行 nonce 值为 abcdefg 的内联脚本。

如果攻击者注入了这样的代码：

<script>
  alert("I'm an evil script!");
</script>

因为这段代码没有 nonce 属性，或者 nonce 值不正确，所以浏览器会拒绝执行。

nonce 的优势：

精确控制： 可以精确控制哪些内联脚本可以执行。
动态生成： nonce 值可以动态生成，每次请求都不同，增加了攻击的难度。

nonce 的缺点：

实现复杂： 需要服务器端生成 nonce 值，并将其插入到 HTML 代码和 CSP 规则中，实现起来比较复杂。
维护困难： 如果有很多内联脚本，每个脚本都需要添加 nonce 属性，维护起来比较麻烦。

代码示例：Python (Flask) + Jinja2 实现 nonce

import os
from flask import Flask, render_template, make_response

app = Flask(__name__)

def generate_nonce():
  return os.urandom(16).hex()

@app.route('/')
def index():
  nonce = generate_nonce()
  response = make_response(render_template('index.html', nonce=nonce))
  response.headers['Content-Security-Policy'] = f"default-src 'self'; script-src 'self' 'nonce-{nonce}'"
  return response

if __name__ == '__main__':
  app.run(debug=True)

templates/index.html:

<!DOCTYPE html>
<html>
<head>
  <title>CSP with Nonce</title>
</head>
<body>
  <h1>Hello, CSP!</h1>
  <script nonce="{{ nonce }}">
    console.log("This is an inline script with nonce!");
  </script>
  <script>
    console.log("This inline script will be blocked by CSP!");
  </script>
</body>
</html>

解释：

generate_nonce(): 生成一个随机的 nonce 值。
index() 视图函数:
- 调用 generate_nonce() 生成 nonce。
- 将 nonce 值传递给 index.html 模板。
- 设置 Content-Security-Policy 响应头，指定允许执行的 nonce 值。
index.html 模板:
- 使用 Jinja2 的模板语法 {{ nonce }} 将 nonce 值插入到 <script> 标签的 nonce 属性中。
- 包含两个内联脚本，一个带有正确的 nonce 值，另一个没有。

运行这个例子，你会发现带有 nonce 值的脚本可以正常执行，而没有 nonce 值的脚本会被浏览器拦截。

hash：指纹识别，精准定位

hash 就像是给一段代码生成一个唯一的指纹，只要代码内容发生任何改变，指纹就会发生变化。我们可以计算出内联脚本的 hash 值，然后在 CSP 规则中指定这个 hash 值。这样，浏览器就只会执行那些 hash 值与 CSP 规则中指定的 hash 值相匹配的脚本。

举个栗子：

假设你的 HTML 代码是这样的：

<script>
  console.log("Hello from inline script!");
</script>

这段代码的 SHA256 hash 值是： sha256-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (这里的 xxxxx… 只是一个占位符，你需要用实际的 SHA256 值替换)

然后在 HTTP 响应头中设置 CSP 规则：

Content-Security-Policy: script-src 'sha256-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

这条规则的意思是：只允许执行 SHA256 hash 值为 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 的内联脚本。

如果攻击者修改了脚本的内容，比如：

<script>
  console.log("Hello from inline script! I'm evil now!");
</script>

这段代码的 hash 值会发生变化，浏览器会因为 hash 值不匹配而拒绝执行。

hash 的优势：

简单易用： 只需要计算出脚本的 hash 值，然后添加到 CSP 规则中即可，实现起来比较简单。
安全可靠： 只要脚本内容不发生变化，hash 值就不会改变，可以保证脚本的安全性。

hash 的缺点：

灵活性差： 如果脚本内容发生任何改变，都需要重新计算 hash 值，并更新 CSP 规则，灵活性比较差。
维护困难： 如果有很多内联脚本，每次修改脚本都需要重新计算 hash 值，维护起来比较麻烦。
不能用于动态生成的脚本： 因为动态生成的脚本内容每次都可能不一样，所以无法提前计算出 hash 值。

代码示例：使用 openssl 计算 SHA256 hash 值

在 Linux 或 macOS 系统中，可以使用 openssl 命令来计算 SHA256 hash 值：

echo -n "console.log('Hello from inline script!');" | openssl dgst -sha256 -binary | openssl base64

解释：

echo -n "...": 输出要计算 hash 值的字符串，-n 参数表示不输出换行符。
openssl dgst -sha256 -binary: 使用 SHA256 算法计算 hash 值，-binary 参数表示输出二进制格式。
openssl base64: 将二进制格式的 hash 值转换为 Base64 编码，方便在 CSP 规则中使用。

nonce vs hash：谁更胜一筹？

nonce 和 hash 各有优缺点，适用于不同的场景。

特性	`nonce`	`hash`
灵活性	高，可以动态生成，每次请求都不同。	低，脚本内容发生任何改变，都需要重新计算 `hash` 值。
实现复杂度	高，需要服务器端生成和管理 `nonce` 值。	低，只需要计算出脚本的 `hash` 值即可。
维护难度	高，如果有很多内联脚本，维护起来比较麻烦。	低，除非脚本内容发生改变，否则不需要维护。
适用场景	适用于需要动态生成内联脚本的场景。	适用于静态的、不经常变化的内联脚本。

总结：

nonce 适用于动态生成的内联脚本，安全性更高，但实现和维护成本也更高。
hash 适用于静态的内联脚本，实现简单，但灵活性较差。

在实际应用中，你可以根据自己的需求选择合适的机制，或者将两者结合起来使用，以达到最佳的 XSS 防御效果。

最佳实践：

不要使用 unsafe-inline 和 unsafe-eval： 这两个指令会大大降低 CSP 的安全性，应该尽量避免使用。
使用严格的 CSP 规则： 尽量使用 default-src 'self' 这样的规则，只允许加载来自相同域名的资源。
定期审查 CSP 规则： 随着网站功能的更新，CSP 规则也需要定期审查和调整，以确保其仍然有效。
结合其他安全措施： CSP 只是 XSS 防御的一部分，还需要结合其他的安全措施，比如输入验证、输出编码等，才能构建一个更安全的 Web 应用。

最后，记住一点： 安全是一个持续不断的过程，没有一劳永逸的解决方案。我们需要不断学习新的安全知识，并将其应用到我们的项目中，才能有效地保护我们的网站和用户免受 XSS 攻击。

今天的讲座就到这里，谢谢大家！希望大家能从今天的分享中有所收获，并在自己的项目中应用 CSP 的 nonce 和 hash 机制，让我们的 Web 应用更加安全可靠。

如果大家还有什么问题，欢迎随时提问！

发表回复 取消回复

发表回复取消回复