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不能阻止连接卷曲或其他自定义用户代理，它将解决什么问题？它似乎只针对使用普通浏览器的普通用户，以保护他们免受错误主机托管的网站的侵害。但是中间人攻击可以轻松地代理连接并覆盖Host标头。
为防止MITM攻击，请使用https（带有浏览器信任的证书）。但是在那种情况下，该证书似乎可以单独缓解MITM攻击。
我确定我有什么遗漏，因此不胜感激。
答案 0 :(得分：1)
简短版本：
攻击是：一个邪恶的网站使用AJAX从本地webpack-dev-server读取数据。
长版：
这是与websockets一起使用的常规安全机制。
攻击的工作方式如下：您当前已在stackoverflow.com上登录。攻击者向您发送包含以下链接的电子邮件：Hey, watch these cute kittens <a href="evil-attacker.com">here</a>。当然，您可以立即单击链接。 evil-attacker.com上的页面包含一个Javascript，该Javascript连接到stackoverflow.com，并以您的名字（因为已登录）写出答案，使您看起来很糟。
Stackoverflow.com可以通过检查创建答案的POST请求的Origin头是否为“ stackoverflow.com”来保护您免受此类攻击。在这种情况下，它将是“ evil-attacker.com”，并且该帖子将被拒绝。
但是，如果Stackoverflow开发人员已经休假多年并且又不再维护stackoverflow.com了-没有人实现这种保护怎么办？
幸运的是，浏览器开发人员并未休假，他们实施了另一种保护措施-同源政策。这只是意味着浏览器将不允许evil-attacker.com连接到stackoverflow.com（不同的域）进行恶意发布。
如果Stackoverflow 想要允许某些网站以您的名字运行操作（例如，允许meta.stackoverflow.com显示来自stackoverflow.com的用户名），则它们必须使用CORS预检请求。
Websockets是一项新技术-没有使用websockets的旧（未维护）网站。因此，不需要采用同源策略来保护旧网站免受此类攻击。
因此，当指定了Websocket protocol时，他们决定使用上述更简单的Origin检查。
要使其正常工作，Websocket服务器必须知道可以合法访问其来源。