在整个会话中重复使用 CSP 脚本随机数？答案

【问题标题】：Reuse CSP script nonce throughout the session?在整个会话中重复使用 CSP 脚本随机数？
【发布时间】：2019-09-21 17:48:46
【问题描述】：

这是https://github.com/w3c/webappsec-csp/issues/215 的后续。 arturjanc 建议将此讨论移至 stackoverflow。

我们正在尝试为 JSF 中的脚本实现 CSP，但不知道在整个会话中重用脚本 nonce 是否安全。或者，像 arturjanc 建议的那样，让原始文档将其当前的 nonce 发送到生成未来响应的服务器。

假设在整个会话中重复使用 nonce 是不安全的，是否可以像当前实现的 here 一样将初始 nonce 包含在隐藏表单输入中。（暂时忽略 CSP 标头/XSS 注入漏洞 - 这只是一个原型）

@arturjanc：你想再插话吗？

编辑：关于 arturjanc 回答的其他想法：

您能否详细说明如何在当今典型的 JSF 应用程序中实现按响应随机数，即在开始时仅加载一个完整页面，随后仅进行 XHR 通信？

如果我对您的理解正确，您的建议是在每个 XHR 请求中始终重新发送最初生成的随机数。然而，在实践中，这实际上与每个会话的随机数相同，不是吗？只是在实现方面更复杂。

严格实现每个响应的 nonce 意味着后续响应还必须包括在该会话之前创建的所有 nonce，因此我们会以某种方式跟踪会话的所有 nonce。

为每个仅包含新创建的每个响应随机数的 XHR 响应设置新的 CSP 标头可能不起作用，因为浏览器通过使用交叉策略合并它们来处理跨响应的多个 CSP 标头，即响应 1 中的Content-Security-Policy: 'nonce-1'响应 2 中的 Content-Security-Policy: 'nonce-2' 将在响应 2 之后使两个随机数都无效。

【问题讨论】：

标签： jsf content-security-policy nonce

【解决方案1】：

遗憾的是，对于您的问题，没有一个正确答案：拥有每个会话的 nonce 显然不是错误的，但它带来了风险，即只要一个 nonce 可能被攻击者泄露，它就可以在另一个页面加载时重复使用，允许攻击者利用 XSS 漏洞，否则 CSP 可以缓解该漏洞。

具体来说，当您在隐藏的输入字段中包含随机数时，它允许值被abusing CSS selectors 泄露；请注意，相同的攻击不会对script#nonce 属性起作用，因为浏览器会从 DOM 中隐藏该属性的值以防止此类攻击。

我的建议有两个：

尝试使随机数按响应而不是按会话进行。这样即使 nonce 可以被泄露，攻击者也很难重新使用它。
如果您需要重新使用 nonce 以允许从服务器异步获取标记以包含具有正确 nonce 值的脚本，请在不将 nonce 复制到 DOM 的情况下执行此操作。例如，如果您将 XHR 用于带有 nonce 参数的 URL，请执行类似 xhr.open("/my/url?nonce=" + document.currentScript.nonce) 的操作

【讨论】：

谢谢，关于您的建议，请参阅我对原始问题的补充。（很遗憾，我的回答对于stackoverflow的cmets来说太长了。让我们回到github？;-)）
不幸的是，我的回答对于 stackoverflow 的 cmets 来说太长了。让我们回到github具体讨论如何在JSF/PrimeFaces中集成CSP？ ;-)
不确定这是否仍然有效，但是当您有一个允许同时打开多个选项卡的应用程序时，是否有一种处理随机数的好方法？我使用的是 PHP，并且在每次页面加载时都会重新生成 nonce，因此旧的 nonce 将不再有效。
浏览器在文档级别强制执行 nonce 要求：如果给定页面的 CSP 带有 nonce，则该页面上的 <script> 元素将需要设置该 nonce，但其他文档您的应用程序中的 /tabs 不会受到影响。因此，默认情况下，CSP nonce 与多个选项卡兼容——您的应用程序唯一需要做的就是确保对于给定的 HTTP 响应 <script> 元素具有与传递的 CSP 标头中设置的相同的 nonce 值有了那个回应。