webpack-dev-server 的 allowedHosts 安全机制的目的是什么？

Question

webpack-dev-server 试图通过强制执行特定的 Host 标头值来缓解什么安全风险？

默认情况下，webpack-dev-server 只允许其Host 标头指定本地环回地址（localhost、127.0.0.1 等）的连接。所有其他主机都会收到此响应：“无效的主机标头”。但当然--allowed-hosts/allowedHosts 配置允许扩大这个限制。

这似乎完全基于Host 标头。我可以用curl设置一个自定义的Host头，请求成功：

curl -X GET -H "Host: http://0.0.0.0:9001/" http://me.internal.example.com:9001/

所以我很好奇——如果allowedHosts 不阻止来自 curl 或其他自定义用户代理的连接，它解决了什么问题？它似乎只针对使用普通浏览器的普通用户，以保护他们免受在错误主机上提供的站点的影响。但是中间人攻击可以很容易地代理连接并覆盖主机标头。

为了防止 MITM 攻击，您可以使用 https（带有浏览器信任的证书）。但在这种情况下，证书本身似乎可以缓解 MITM 攻击。

我确定我遗漏了一些东西，因此感谢您提供任何进一步的解释。

Answer 1

短版：

攻击是：一个邪恶的网站使用 AJAX 从你本地的 webpack-dev-server 读取数据。

---

长版：

这是与 websockets 一起使用的正常安全机制。

攻击

攻击是这样进行的：您当前登录的是 stackoverflow.com。攻击者向您发送一封带有链接的电子邮件：Hey, watch these cute kittens <a href="evil-attacker.com">here</a>。当然，您立即单击链接。 evil-attacker.com 上的页面包含一个连接到 stackoverflow.com 的 Javascript，并以您的名义（因为您已登录）写下让您看起来很糟糕的答案。

同源策略

Stackoverflow.com 可以通过检查创建答案的 POST 请求的 Origin 标头是否为“stackoverflow.com”来保护您免受此类攻击。在这种情况下，它将是“evil-attacker.com”并且帖子将被拒绝。

但是，如果 Stackoverflow 开发人员已经休假多年并且 stackoverflow.com 不再维护 - 没有人实施过这样的保护。

幸运的是，浏览器开发人员没有休假，他们实施了一种额外的保护类型 - 同源策略。这只是意味着浏览器不会允许 evil-attacker.com 连接到 stackoverflow.com（不同的域）来发布恶意帖子。

CORS

如果 Stackoverflow想要允许某些网站以您的名义运行操作，例如允许 meta.stackoverflow.com 从 stackoverflow.com 显示您的用户名，他们必须使用 CORS 预检请求。

网络套接字

Websockets 是一项新技术 - 没有使用 websockets 的旧（未维护）网站。因此，没有必要制定同源策略来保护旧网站免受此类攻击。

因此，当指定Websocket protocol 时，他们决定使用上述更简单的Origin 检查。

为此，Websocket 服务器必须知道可以合法访问它的来源。