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

Question

webpack-dev-server通过强制执行特定标头值试图减轻哪些安全风险Host？

\n\n

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

\n\n

这似乎仅基于标题Host。我可以使用curl设置自定义Host标头，并且请求成功：

\n\n

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

\n\n

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

\n\n

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

\n\n

我确信我遗漏了一些东西，所以任何进一步的解释都是值得赞赏的。

\n

Answer 1

简洁版本：

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

长版：

这是与 Websocket 一起使用的常规安全机制。

攻击

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

同源策略

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

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

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

跨域资源共享

如果 Stackoverflow希望允许某些网站以您的名义运行操作，例如允许 meta.stackoverflow.com 显示您来自 stackoverflow.com 的用户名，则它们必须使用 CORS 预检请求。

网络套接字

Websockets 是一项新技术 - 不存在使用 Websockets 的旧（未维护）网站。因此，不需要同源策略来保护旧网站免受此类攻击。

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

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