具有动态 cors 标头的 API 漏洞

Posted 2023-02-22

【中文标题】具有动态 cors 标头的 API 漏洞

【英文标题】：API vulnerabilities with dynamic cors headers

【发布时间】：2017-08-28 20:26:32

【问题描述】：

我一直在阅读如何正确保护支持动态 cors 标头的 API。不确定我是否完全理解通配任何子域的问题。

if (preg_match('|\.?my-site.com$|', $_SERVER['SERVER_NAME'])) 
   header('Access-Control-Allow-Origin: *');
   header('Vary: Origin,Accept-Encoding');

（我的API同时支持HTTP和HTTPS，前面是Varnish）

问题

与发出请求的实际来源相比，使用 Access-Control-Allow-Origin: * 是否有缺点？ 添加Vary: Origin, Accept-Encoding 可以获得哪些安全优势？我在阅读有关缓存中毒的内容时了解到对它们的需求，但不能说我理解这里的含义。

【参考方案1】：

使用Access-Control-Allow-Origin: * 与发出请求的实际来源相比有什么缺点吗？

问题中所述情况的唯一缺点是，如果您想在请求中包含凭据，则如果 Access-Control-Allow-Origin 值为 *，则不能。请参阅 MDN HTTP 访问控制 (CORS) 文章中的 Credentialed requests and wildcards。

所以看起来您可能想要做的是，让您的 php 代码获取 Origin 请求标头的值并将其回显到 Access-Control-Allow-Origin 值中：

if (preg_match('|\.?my-site.com$|', $_SERVER['SERVER_NAME'])) 
   header("Access-Control-Allow-Origin: $_SERVER['HTTP_ORIGIN']");
   header('Vary: Origin,Accept-Encoding');

不确定我是否完全理解通配任何子域的问题。

允许来自任何来源的请求存在问题的唯一情况是您的服务在 Intranet 内或防火墙后面运行。

在Is it safe to enable CORS to * for a public and readonly webservice?查看相关答案

【参考方案2】：

你会在这里找到一个很酷的答案：What are the security risks of setting Access-Control-Allow-Origin? :

假设您拥有一个银行网站，该网站使用基于 cookie 的会话。编写Access-Control-Allow-Origin: * 将允许任何网站使用您的用户 cookie 运行从他们的网站到您的银行网站的Ajax 请求，从而使用您用户的会话。所以他们可以访问用户在连接时可以访问的任何内容:-)

我认为这与安全性无关，但这里有一个来自this page 的有趣回答：

Vary: Accept-Encoding 基本上告诉服务器在编码相同时从缓存中加载页面，并重新生成它以进行另一种编码。这是上面页面的引述，它解释了一个有用的案例：

想象一下两个客户端：一个没有压缩的旧浏览器，一个有压缩的现代浏览器。如果他们都请求同一个页面，那么根据谁先发送请求，压缩或未压缩版本将存储在 CDN 中。现在问题开始了：旧浏览器可能会要求常规的“index.html”并获取缓存的压缩版本（随机垃圾数据），或者新浏览器可能会获取缓存的未压缩版本并尝试“解压缩”它。坏消息，不管怎样。

【讨论】：

但在我的情况下，我只为我自己域的子域设置Allow-Origin: *。这也可以被利用吗？

写Allow-Origin: * 允许任何网站访问您服务器的响应。如果您想将其限制在您的域和子域中，请查看此页面：***.com/questions/14003332/…

我明白了，但是只有当 xhr 请求来自我自己的域时才设置通配符，对吧（根据我发布的示例）？

不，通配符允许任何网站:-)

谁先上？我要问的是，如果请求来自 my-site.com 以外的网站，则不会设置 cors 标头，并且浏览器不会将响应传递给请求的应用程序。没有？