面试题有Host头攻

面试题有Host头攻击？我差点在技术面当场社死！😱

开头碎碎念：这道题真的把我问懵了

姐妹们兄弟们，我上周去面了一家做安全产品的公司，结果面试官冷不丁甩给我一道关于Host头攻击的题目，我当时心里咯噔一下——这玩意儿我平时写代码的时候压根没注意过啊！😅 说实话，要不是我平时刷网络安全面试题的时候瞟过一眼,我可能当场就要用脚趾抠出三室一厅了。

那种感觉你们懂吗？就是明明觉得这东西似曾相识，但真要让你说出个一二三来，脑子里就一片空白，我甚至能感觉到自己额头上冒出了细密的汗珠，手心也开始发潮……唉,说起来都是泪啊！

什么是Host头攻击？别慌，我用大白话跟你唠

其实吧，Host头攻击（Host Header Attack）说白了就是攻击者偷偷篡改HTTP请求里的Host字段，咱们平时访问网站的时候，浏览器会自动带上这个Host头，告诉服务器“嘿，我要访问的是你家的哪个网站”，服务器呢,就靠着这个头来决定该把请求转发给哪个后端应用。

重点来了！如果服务器没有好好验证这个Host头，攻击者就可以随便改成自己想要的地址，比如把目标网站的Host改成恶意IP，或者直接塞点乱七八糟的东西进去，这就像你寄快递，收件人地址被坏人涂改了，结果包裹就被送到了别人的手里，是不是细思极恐？！😨

我当时在面试现场，脑子飞速运转，突然灵光一闪想起来Host头攻击常见的几种危害场景：

密码重置投毒：攻击者伪造Host头，让受害者点击链接时，密码重置链接被发送到攻击者控制的服务器上，好家伙,这波操作直接盗号。
缓存污染：如果能控制Host头，把恶意内容“种”到缓存服务器里，那么其他用户访问时就会看到被篡改的页面,这危害范围可就大了去了。
绕WAF防护：有些WAF规则没检查Host头，攻击者就利用这一点直接绕过防护,直捣黄龙！

我当时说到这儿，面试官的眼睛明显亮了一下,我心里暗暗松了一口气。

为什么这道面试题会成为“必考题”？

说真的，面试题有Host头攻击出现在越来越多的技术面试里，真不是没道理的，你想啊，现在很多公司都在搞前后端分离、微服务架构，网关和负载均衡器全靠Host头来路由请求，一旦这个环节出问题,那真是牵一发而动全身。

而且最要命的是，很多开发小哥哥小姐姐（包括以前的我自己）在写业务代码的时候，压根就不检查Host头，觉得这是中间件的事儿，哎哟喂，这种“甩手掌柜”的想法，恰恰就给了攻击者可乘之机！🤯

我记得我当时跟面试官说：“这个攻击利用的是信任链中的默认信任关系，开发者和运维都以为对方做了验证，结果都没做，漏洞就这么诞生了。”面试官听完连连点头，虽然我心里其实还有点虚,但表面上还是要装得很稳呀！

怎么防御？这事儿真不能偷懒

既然Host头攻击这么狡猾，那咱们该咋办呢？我当时用拇指掐着掌心，尽量保持冷静,然后跟面试官说：

白名单验证：在服务器或者网关上配置一个Host白名单，只有匹配的域名才放行，其他一律拒绝访问，这个方法最简单粗暴,也最有效。
在代码层面强制校验：后端框架里写个中间件，获取请求的Host头后跟配置的域名比对，不一致就返回403，我当时还特意提了一句“别用Java的getRequestURL()，因为有些代理会重写URL，应该用原始头”。
不信任任何外部传入的Host：设置默认的Host值，如果没匹配上，就重定向到一个默认地址或者直接报错,而不是用请求里的Host动态生成链接。

讲完这些，我明显感觉到面试官的表情从“这小子是不是撞大运”变成了“嗯，有点东西”，虽然我表现得云淡风轻，其实心里已经乐开花了哈哈！😂

我的切身教训：刷面试题真的要全面

这次面试给我最大的触动，就是面试题有Host头攻击这种情况，绝不是个例，现在网络安全类的面试题越来越刁钻，光靠死记硬背几个SQL注入、XSS根本不够，像Host头攻击这种平时开发中容易忽略的点,恰恰是面试官最爱挖的坑。

所以兄弟姐妹们，如果你们也想走安全方向，或者开发想转安全岗，真的得把眼界放宽点，什么中间人攻击啊、DNS rebinding啊、请求走私啊，都得有点概念，不然到面试现场,真的会被打个措手不及！

顺便说一句，我面试结束后赶紧跑去补了几个实战复现，把自己搭的DVWA靶场翻出来重新折腾了一遍，才感觉自己心里踏实了些，你们要是也跟我一样有“考前焦虑”，最好的办法就是多动手实操,别光看理论。

最后说点掏心窝子的话

其实面试中遇到不会的题不可怕，可怕的是你连个思路都没有，我当时能答上来Host头攻击，全靠平时看漏洞报告时多留了个心眼，万一你真卡壳了，也别慌，可以跟面试官说：“虽然我不太了解这个攻击的具体细节，但我知道它属于HTTP请求走私/注入类的问题，如果是我的话，我会从输入验证和访问控制两个方面去排查。”——这样一来，就算你答得不够深,面试官也会觉得你有分析问题的能力。

面试题有Host头攻