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

Question

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

默认情况下，webpack-dev-server 只允许 Host header 指定本地环回地址(localhost、127.0 .0.1 等)。所有其他主机都会收到此响应:“无效的主机 header ”。但是当然 --allowed-hosts/allowedHosts 配置允许扩大这个限制。

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

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

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

为了防止 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 可以通过检查 Origin 来保护您免受此类攻击。创建答案的 POST 请求的 header 是“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 服务器必须知道可以合法访问它的来源。