通过添加与 Material UI 兼容的元标记，我是否在我的 CSP header 中留下了安全漏洞？
Am I leaving a security vulnerability in my CSP header by adding a meta tag to be compatible with Material UI?
我正在努力加强一系列网络应用程序的安全性。其中之一有一个带有 Material UI 库的 React 前端。正如您将看到的，这很重要。
首先，我创建了一个标准 CSP header 并将所有样式标签的 sha256 哈希添加到 style-src 部分。这工作得很好，但是我敢肯定您已经猜到它很脆弱，因为样式标签的差异意味着更改哈希值。此外，Material UI 将其大部分样式生成为 dynamically-created 样式标签，因此需要添加大量哈希值。重点是，这不是一种可扩展的方法。
我现在已经换成随机数了。我将此元行添加到我的 index.html:
<meta property="csp-nonce" content="**CSP_NONCE**" />
我的 nginx 服务器会在每个请求上自动生成一个随机数并将其插入到内容属性中。然后 Material UI 使用它在每个样式标签上添加随机数，从而使它们符合我的 CSP。
我的问题是：这样做会降低我的 CSP 的安全性吗？我知道 CSP 是为了防止 XSS 攻击。如果我在 HTML 中放入一个有效的随机数，是否意味着该随机数可能会被攻击者窃取并用于保护他们的攻击代码？
在我写这篇文章时，我意识到 Material UI 来自 already-trusted 脚本标签，而不是无论如何都无法执行的恶意内联脚本。所以这可能就是它安全的原因。我对 CSP 的世界还比较陌生，虽然我觉得我对它有一定的了解，但知识越多越好。
作为 this 来源的讨论。在元标记中传递 'nonce' 是否安全？能否被攻击者窃取和使用？
要从实际的角度回答这个问题，我们需要了解我们实际防御的是什么。
Third-party 脚本可以通过几种方式到达页面：
- 网页经典XSS漏洞
- 浏览器插件
- PC 或家庭路由器上的病毒
- 黑客主机
- ISP 注入
- DNS 欺骗
方式 2-5 意味着攻击者在技术上可以访问 nonce 并且可以修改 CSP header，因此这些在主题方面是不可能的。
6 攻击者无权访问 'nonce' 不在 HTTP header 中，也不在 HTML 中。所以我们把这个问题排除在讨论之外。
只剩下通过经典XSS漏洞的窃取和使用分析'nonce'
攻击者可以使用脚本获得实际的 'nonce'，但必须事先允许此脚本执行 - 具有有效的 'nonce' 或在浏览器解析页面 HTML 之前来自受信任的来源。
但是在这种情况下，攻击者总是落后1步。
在浏览器中加载页面后，'hash-value' 的“保密性”就失去了意义。 知道比赛结果后不允许下注.
鉴于上述情况，我没有看到通过以下方式降低传输随机数的安全性：
<meta property="csp-nonce" content="**CSP_NONCE**" />
也许我漏掉了某种攻击向量？
已更新
是的，我错过了一些窃取和重用攻击'nonce'，例如：重新加载页面而不触发对服务器的请求（从HTTP缓存、AppCache、浏览器B/F缓存重新加载页面）。
这样的技巧如：
victimFrame.src = "data:text/html,<script>history.back()</script>"
允许通过 CSSAR（CSS 属性读取）窃取 'nonce' 值并重新使用它。
我正在努力加强一系列网络应用程序的安全性。其中之一有一个带有 Material UI 库的 React 前端。正如您将看到的，这很重要。
首先，我创建了一个标准 CSP header 并将所有样式标签的 sha256 哈希添加到 style-src 部分。这工作得很好，但是我敢肯定您已经猜到它很脆弱，因为样式标签的差异意味着更改哈希值。此外，Material UI 将其大部分样式生成为 dynamically-created 样式标签，因此需要添加大量哈希值。重点是，这不是一种可扩展的方法。
我现在已经换成随机数了。我将此元行添加到我的 index.html:
<meta property="csp-nonce" content="**CSP_NONCE**" />
我的 nginx 服务器会在每个请求上自动生成一个随机数并将其插入到内容属性中。然后 Material UI 使用它在每个样式标签上添加随机数，从而使它们符合我的 CSP。
我的问题是：这样做会降低我的 CSP 的安全性吗？我知道 CSP 是为了防止 XSS 攻击。如果我在 HTML 中放入一个有效的随机数，是否意味着该随机数可能会被攻击者窃取并用于保护他们的攻击代码？
在我写这篇文章时，我意识到 Material UI 来自 already-trusted 脚本标签，而不是无论如何都无法执行的恶意内联脚本。所以这可能就是它安全的原因。我对 CSP 的世界还比较陌生，虽然我觉得我对它有一定的了解，但知识越多越好。
作为 this 来源的讨论。在元标记中传递 'nonce' 是否安全？能否被攻击者窃取和使用？
要从实际的角度回答这个问题，我们需要了解我们实际防御的是什么。
Third-party 脚本可以通过几种方式到达页面：
- 网页经典XSS漏洞
- 浏览器插件
- PC 或家庭路由器上的病毒
- 黑客主机
- ISP 注入
- DNS 欺骗
方式 2-5 意味着攻击者在技术上可以访问 nonce 并且可以修改 CSP header，因此这些在主题方面是不可能的。
6 攻击者无权访问 'nonce' 不在 HTTP header 中，也不在 HTML 中。所以我们把这个问题排除在讨论之外。
只剩下通过经典XSS漏洞的窃取和使用分析'nonce'
攻击者可以使用脚本获得实际的 'nonce'，但必须事先允许此脚本执行 - 具有有效的 'nonce' 或在浏览器解析页面 HTML 之前来自受信任的来源。
但是在这种情况下，攻击者总是落后1步。
在浏览器中加载页面后，'hash-value' 的“保密性”就失去了意义。 知道比赛结果后不允许下注.
鉴于上述情况，我没有看到通过以下方式降低传输随机数的安全性：
<meta property="csp-nonce" content="**CSP_NONCE**" />
也许我漏掉了某种攻击向量？
已更新
是的，我错过了一些窃取和重用攻击'nonce'，例如：重新加载页面而不触发对服务器的请求（从HTTP缓存、AppCache、浏览器B/F缓存重新加载页面）。
这样的技巧如：
victimFrame.src = "data:text/html,<script>history.back()</script>"
允许通过 CSSAR（CSS 属性读取）窃取 'nonce' 值并重新使用它。