无论我如何表述这个问题，我都没有得到任何回应，所以我继续尝试。我觉得我一定错过了什么，但我一直在寻找。为什么它不明显？为什么得到答案这么难？
我们被告知，我们应该在网站上为内联脚本使用内容安全策略 (CSP) nonce。该 nonce 应该在服务器上针对每个请求随机生成，并由网站获取，然后通过脚本标记中的变量包含在内。这样，我们就可以防范黑客攻击。
很好，但我找不到办法做到这一点，并且仍然缓存网站！有办法吗？有人吗？
如果不是，为什么这些关于创建 CSP nonce 的文章中没有明确说明这一点？我们需要答案！
谢谢你让我发泄一下。但说真的，答案是什么？
答案1
总结：您可以像平常一样继续缓存带有 nonce 的响应，而 CSP 仍然能够为常见的 XSS 攻击提供强大的防御。
这是一个有趣的问题：当包含 CSP nonce 的页面被缓存（在公共/后端缓存中）时，会导致相同的 nonce 被传输给多个用户。这听起来很糟糕，因为 nonce 不应该被重复使用。然而，在实践中，这通常不是问题。
假设你作为攻击者在对 URL 的响应中获得了与受害者相同的随机数/foo/bar。现在你可以在 XSS 负载中使用此随机数。让我们考虑两种最常见的 XSS 场景：
- 基于 URL 参数的反射型 XSS：
/foo/bar?payload=...可能具有与 不同的缓存键/foo/bar，因此导致向用户发送具有新随机数的全新响应。攻击失败。 - 动态 HTML 中的存储型 XSS：现在，当用户加载时，您的有效负载就会包含在内
/foo/bar。但是，如果用户刷新并从缓存中获得响应，则不会包含您注入的 XSS 有效负载。或者，如果他们获得新的响应，他们也会获得新的随机数。无论哪种情况，攻击都会失败。
现在，这并不意味着这种情况永远不会被利用：例如，如果/foo/bar有易受攻击的 JavaScript 以某种方式修改 DOM，攻击者可以注入有效负载，则可能使用缓存的随机数。想想通过 URL 段或 AJAX 响应中的数据进行的基于 DOM 的 XSS 攻击#。
然而，对于攻击者来说，利用后一种情况会更加棘手，但这可能就足够了，因为 CSP 的目的只是提供纵深防御；它不能保证 100％ 的 XSS 攻击免疫。
如果您仍想防范这种情况：您可以禁用 HTML 响应的公共缓存。但是，私有/浏览器缓存仍然可以，并且您还可以安全地继续缓存任何非 HTML 资源。