2

OWASP建议在 API 响应中使用Content-Security-Policy: frame-ancestors 'none'，以避免拖放式点击劫持攻击。

但是，CSP 规范似乎表明，在加载 HTML 页面后，相同上下文中的任何其他 CSP 规则都将被丢弃而无效。这在我关于 CSP 工作原理的心智模型中是有道理的，但如果 OWASP 推荐它，那么我肯定会遗漏一些东西。

在 HTML 页面已经加载并且“主”CSP 已经评估之后，谁能解释 XHR 请求中的 CSP 标头如何提高安全性？这在浏览器中是如何工作的？

4

3 回答 3

2

在 HTML 页面已经加载并且“主”CSP 已经评估之后，XHR 请求中的 CSP 标头如何提高安全性？

你是对的，浏览器从主页使用 CSP，而只是忽略与 XHR 请求一起发送的 CSP 标头。

但是您还没有考虑过第二种情况——API 响应在浏览器的地址栏或框架中打开。在这种情况下，cookie 将可用于响应页面，并且如果在 API 中检测到 XSS（例如，在PyPI 简单端点 API中），那么攻击者可能会使用用户的机密数据。
因此，最好使用“default-src `none”策略以及404/403/500等页面来保护 API 响应。

于 2021-08-24T16:51:48.340 回答
1

在 HTML 页面已经加载并且“主”CSP 已经评估之后，谁能解释 XHR 请求中的 CSP 标头如何提高安全性？这在浏览器中是如何工作的？

加上上面granty的正确答案，帧通常用于CSP绕过。如果页面中允许一个框架（未被 CSP 阻止），则该框架有它自己的 CSP 范围。因此，如果您为数据创建一些 API - 您不希望将其设置为框架，因为它可用于绕过原始 CSP（例如数据泄露）。

所以你可以通过设置来封堵这个漏洞Content-Security-Policy: frame-ancestors 'none';，然后你的API就会拒绝被加框。

有关更多信息，请参阅有关绕过 CSP 的文章。POC 使用了一种创造性的技巧：

frame=document.createElement(“iframe”);
frame.src=”/%2e%2e%2f”;
document.body.appendChild(frame);

这反过来会触发没有设置任何 CSP 的 NGINX 错误代码页。许多生产 CSP 容易受到此问题的影响。

由于不在框架页面上设置 CSP 基本上默认为无 CSP（一切都是打开的），因此文章建议：

CSP 标头应出现在所有页面上，Web 服务器返回的错误页面上的事件

于 2021-08-29T22:18:07.823 回答
0

该frame-ancestors 'none'指令将在页面加载时向浏览器指示它不应在框架中呈现（包括框架、iframe、嵌入、对象和小程序标签）。换句话说，该策略不允许它被任何其他页面框住。

API 或页面的 CSP 标头在加载时读取。这不是事后发生的事情。“主” CSP 不相关，因为它是帧中的 URI，它为自己发送 CSP。浏览器简单地frame-ancestor 'none'接受该 URI 的请求

frame-ancestors 指令限制可以使用 frame、iframe、object 或 embed 嵌入资源的 URL。资源可以使用此指令来避免许多 UI Redressing [UISECURITY] 攻击，方法是避免嵌入潜在的敌对上下文中的风险。

参考
CSP frame-ancestors
Clickjacking Defense Cheat Sheet
内容安全策略
Web Sec Directive Frame Ancestors

于 2021-08-23T19:40:37.660 回答