使用到的工具
-
Burp site
wireshark
tcpdump
fiddler
漏洞描述
为了方便的获得网站域名，开发人员一般依赖于HTTP Host header。例如，在php里用_SERVER["HTTP_HOST"]。但是这个header是不可信赖的，如果应用程序没有对host header值进行处理，就有可能造成恶意代码的传入。
漏洞参数
请求方式: GET
URL: https://xxxxxx/img
问题参数: Host
参考（验证）: https://xxxxxx/img(HOST)www.swmnhx.com
修复建议
web应用程序应该使用SERVER_NAME而不是host header。
在Apache和Nginx里可以通过设置一个虚拟机来记录所有的非法host header。在Nginx里还可以通过指定一个SERVER_NAME名单，Apache也可以通过指定一个SERVER_NAME名单并开启UseCanonicalName选项。
动手～～～
根据漏洞修复建议，开始修复
- 直接修改nginx
server {
listen 443 ssl default_server;
server_name _;
return 404;
# ssl_certificate /etc/nginx/cert/xxxx.pem;
# ssl_certificate_key /etc/nginx/cert/xxx.key;
# ssl_session_timeout 5m;
# ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4; #使用此加密套件。
# ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #使用该协议进行配置。
# ssl_prefer_server_ciphers on;
}
- 发现问题，nginx压根没有配置ssl证书，想起来了，在不久前添加了一层clb负载均衡，所以这里就不需要配置了,再次修改
server {
listen 80 default_server;
server_name _;
return 404;
这次信心十足，:wq保存，nginx - reload 刷新nginx，开始进行测试
首先正常请求如下：
修改Host请求：
发现依然可以成功，蒙圈了
准备抓包看看请求
ip addr查看网卡名称
开始抓包tcpdump -w request.cap -i eth0 'port 80'
抓包成功后，下载request.cap文件，用wireshark打开
发现正常的请求数据过来，能看到抓包数据，但是并没有看到修改Host的请求进来，但是明明返回的是200查看nginx日志
cat /var/log/nginx/access.log | grep 'xxxx'查看日志
发现所有的请求都进来了
调转方向，去查看阿里云clb 配置
研究了半天，没发现clb有哪里可以配置的地方，反复测试，依旧发现部分可以抓包，部分不可以-
查看443
在已经卡住没发进行，再联系阿里云客服的时候，想了下，请求到clb的是https
查看服务器的443端口
netstat -anp | grep 443
果然发现有很多建立的连接
抓包443tcpdump -w request443.cap -i eth0 'port 443'
用wireshark打开，果然看到了修改Host的请求
至此猜测 clb 如果是正常的请求，host对上了就会正常的通过80访问服务器的nginx，对不上的时候，会想服务器发送443的http请求，不知道为什么会这样，clb的坑后面再去踩踩 调整nginx
server {
listen 80 default_server;
listen 443 default_server;
server_name _;
return 404;
-
验证
修改Host，发送请求，返回预期结果状态，在这里踩了一个不小的坑，就是中间加了一层clb负载之后，这种小的修改都有可能踩大坑～～～
