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攻击。
我确定我遗漏了一些东西，因此不胜感激。
简洁版本：
攻击是：一个邪恶的网站使用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可以通过检查Origin创建答案的POST请求的标头为“ stackoverflow.com”来保护您免受此类攻击。在这种情况下，它将是“ evil-attacker.com”，并且该帖子将被拒绝。
但是，如果Stackoverflow开发人员已经休假了很多年，而stackoverflow.com不再得到维护-没有人实现这种保护，该怎么办？
幸运的是，浏览器开发人员并未休假，他们实施了另一种保护措施-同源政策。这仅意味着浏览器将不允许evil-attacker.com连接到stackoverflow.com（不同的域）进行恶意发布。
如果Stackoverflow希望允许某些网站以您的名义运行操作，例如，允许meta.stackoverflow.com从stackoverflow.com显示您的用户名，则它们必须使用CORS预检请求。
Websocket是一项新技术-没有使用Websocket的旧（未维护）网站。因此，不需要采用同源策略来保护旧网站免受此类攻击。
因此，当指定了Websocket协议时，他们决定使用上述更简单的Origin检查。
为此，Websocket服务器必须知道可以从哪个来源合法访问它。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句