[S]假设网站 B 将标头设置Access-Control-Allow-Credentials为false, 并且Access-Control-Allow-Origin: *，这是否会对正在浏览网站 A 的用户造成任何具体的安全风险（假设网站 A 是恶意的）？

答案非常依赖于上下文，但不加选择地使用Access-Control-Allow-Origin: *，您可能会使自己暴露于某些类型的攻击。我在下面介绍其中两个：

1. 服务器绑定到无法访问的网络接口
2. 针对登录的分布式客户端暴力攻击

服务器绑定到无法访问的网络接口

特别是，考虑这样一种情况，未经身份验证的受害者只能从目标网络中的特权位置（例如，在网络防火墙后面）访问站点 B。在这种情况下，

• 因为不涉及环境权限（如 cookie），所以Access-Control-Allow-Credentials标头的存在或值是无关紧要的；和
• 攻击者在访问站点 A 时通过受害者的浏览器通过隧道进入站点 B，可以从站点 A 读取站点 B 的响应。

一个真实的例子

几年前，曾披露过一个影响多个 JetBrains IDE 的类似漏洞。这些 IDE 将启动一个绑定到localhost具有过度许可 CORS 策略的服务器，这允许外部攻击者泄露敏感数据。有问题的服务器反映了任意来源Access-Control-Allow-Origin（而不是使用通配符*），但在这种情况下，区别是无关紧要的。

一些资源

• OWASP 测试指南提到了这种风险：

  尽管 [ Access-Control-Allow-Origin: *] 不能与 theAccess-Control-Allow-Credentials: true同时使用，但如果访问控制仅由防火墙规则或源 IP 地址完成，而不是受凭据保护，则可能很危险。

• 詹姆斯水壶（又名albinowax从PortSwigger），在他的APPSEC欧盟2017年说起CORS错误配置，进一步讨论了CORS错误配置不涉及的凭证。

• 另请参阅詹姆斯对书面形式的主题的想法：

  如果没有 [ Access-Control-Allow-Credentials: true]，受害者用户的浏览器将拒绝发送他们的 cookie，这意味着攻击者将只能访问未经身份验证的内容，他们可以通过直接浏览目标网站来轻松访问这些内容。但是，在一种常见情况下，攻击者无法直接访问网站：当它是组织内部网的一部分，并且位于私有 IP 地址空间内时。内部网站的安全标准通常低于外部网站，从而使攻击者能够发现漏洞并获得进一步的访问权限。[...] 如果私有 IP 地址空间内的用户访问公共 Internet，则可以从外部站点执行基于 CORS 的攻击，该外部站点使用受害者的浏览器作为访问 Intranet 资源的代理。

针对登录的分布式客户端暴力攻击

返回易受登录 CSRFAccess-Control-Allow-Origin: *攻击的身份验证端点（该漏洞通常被认为可以忽略不计）是危险的。恶意页面可以伪造登录请求并通过 JavaScript 观察结果（成功或失败）。

攻击者甚至可以通过部署一个命令和控制服务器来对登录发起分布式客户端暴力攻击，该服务器将向不同的受害者（碰巧登陆恶意页面）提供不同的候选凭据。这种分布式攻击可能很难被阻止，因为基于 IP 或基于指纹的保护（例如速率限制）将不可行。Tim Tomes 和 Kevin Cody 在他们的 DerbyCon 2019 演讲中描述了这种攻击。