为什么我们应该在API的HTTP响应中包括CSP报头？

Question

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

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

有人能解释XHR请求中的CSP头在HTML页面已经加载和“主”CSP已经评估之后如何提高安全性吗？在浏览器中是如何工作的？

Answer 1

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

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

但是您还没有考虑第二种情况-- API响应是在浏览器的地址栏或帧中打开的。在这种情况下，cookies将提供给响应页面，如果在API中检测到XSS (例如，在PyPI简单端点API中)，那么攻击者可能可以使用用户的机密数据。

因此，最好使用"default-src ` the“策略以及404/403/500等页面来保护API响应。

Answer 2

有人能解释XHR请求中的CSP头在HTML页面已经加载和“主”CSP已经评估之后如何提高安全性吗？在浏览器中是如何工作的？

在以上格兰蒂的正确答案中，帧通常用于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服务器返回的错误页上。

Answer 3

frame-ancestors 'none'指令将在页面加载时向浏览器指示不应在框架中呈现它(包括框架、iframe、embed、object和applet标记)。换句话说，该政策不允许用任何其他页面来限定它。

API或页面的CSP头在加载时读取。这不是事后发生的事情。"main“CSP与此无关，因为是框架中的URI为自己发送CSP。浏览器只是通过该URI来响应frame-ancestor 'none'请求。

框架-祖先指令限制可以使用框架、iframe、object或embed嵌入资源的URL。资源可以使用这个指令来避免许多UI纠正UISECURITY攻击，避免被嵌入潜在的敌对环境的风险。

参考资料

CSP框架-祖先

点击劫持防御备忘单

内容安全策略

Web指令框架祖先