发送“Access-Control-Allow-Origin: http://localhost:8888”危险吗?

信息安全 Web应用程序 http 科尔斯
2021-09-01 06:16:23

我最近在一个网站上发现了以下 HTTP 标头,至少可以将其描述为高价值目标:

Access-Control-Allow-Origin: http://localhost:8888
Access-Control-Allow-Methods: POST, GET, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: [some custom non-standard headers]

这对我来说看起来很奇怪,或者至少不符合CORS RFC

Access-Control-Allow-Origin 标头指示是否可以通过在响应中返回 Origin 请求标头的值“*”或“null”来共享资源。

返回的值显然不是我的 Origin 请求标头(或*null)。所以,我的问题是:

  • 发送这些标头有什么好的理由吗?对我来说,这似乎是测试中使用的东西意外泄漏到生产中。
  • 是否有可能以任何方式利用这一点?对我来说似乎不太可能,因为只有极少数用户会在该端口上运行任何东西,而且攻击者无论如何都无法控制它。但也许我忽略了一些东西。
  • 这是否值得联系相关网站以告知他们该问题?
2个回答

攻击者要使用这个 CORS 标头,他必须在 localhost:8888 上运行 Javascript。受您的问题启发,我寻找了一个在 localhost:8888 上运行并允许攻击者运行 Javascript 的服务。我找到了一个:

MAMP是一个默认在 8888 端口上运行的 webstack,并带有易受攻击的 SQLiteManager。SQLiteManager 有几个漏洞,其中一个是使用 CSRF 的 XSS,因此攻击者可以远程触发 Javascript 以在 localhost:8888 的上下文中运行。然后它将能够从您的高价值目标中读取数据。

这种攻击不太可能发生,因为它只适用于既是您网站的访问者又是 MAMP 用户的用户。此外,MAMP 还存在远程代码执行漏洞,因此攻击者无需 CORS 头即可读取 HTTP 响应。

我相信这在典型的 MiTM 场景中应该是可以利用的,特别是如果您不使用 HSTS 标头(也无需降级,因为它在 HTTP 中)——典型的 DNS 欺骗攻击可以使受害者的 IP 成为同一个本地网络作为 localhost:8888 导航导致相信是您并使用 CORS 响应进行响应。-- 我真的不明白为什么你需要一个带有这种 CORS 响应头的网站