ssrf利用

SSRF（服务端请求伪造）之所以危险，利用是利用因为它把“服务器”变成了攻击者的代理。你以为在访问自己的利用目标，实际上你的利用服务器正替黑客去内网敲门。这玩意儿比XSS更阴，利用因为受害者不是利用浏览器，而是利用那台有公网IP的机器。

拿个真实场景说。利用某云厂商的利用控制台有个“图片处理”功能，你传个URL，利用它就去抓取。利用看起来人畜无害对吧？利用但攻击者把URL换成http://169.254.169.254/latest/meta-data/，这是利用云厂商的元数据服务地址，里面躺着临时密钥。利用服务器傻乎乎地替攻击者把密钥取回来，利用再渲染到图片上——一个完整的云账号接管就这么完成了。我见过不少安全测试报告，第一页就是这玩意儿，百试百灵。

绕过手段更让人头疼。你以为过滤了127.0.0.1就安全了？人家用2130706433（十进制IP）、0x7f000001（十六进制）、甚至localtest.me这样的DNS重绑定域名。最绝的是用http://[::1]，IPv6的本地回环，很多过滤规则压根没考虑它。还有用重定向的，先给个合法URL，服务端跟随跳转后直捣内网。你封IP段？人家用http://0.0.0.0，某些系统直接解析成localhost。

检测SSRF最土的办法是搭个外部监听器，扔个URL过去看有没有回连。但内网探测才是它的价值所在——用响应时间差判断端口开放状态，用错误信息差异识别内网服务。比如请求http://192.168.1.1:22和:23，SSH返回的报错和Telnet完全不一样，攻击者靠这些蛛丝马迹画内网拓扑图。

防御这事，光靠黑名单就是自欺欺人。真正有效的是白名单+协议限制。允许访问的域名写死，禁止非HTTP协议。还有个土办法——把服务器放在独立网络区域，让SSRF即使成功也摸不到核心资产。但现实中我见过太多开发图省事，直接拿服务器本机IP当代理去抓第三方API，这等于把内网大门钥匙挂在门口。

最后说个冷门的利用点。有些SSRF能打本机的docker.sock——如果容器把Docker守护进程的Unix套接字挂载进来了，攻击者可以直接创建新容器挂载宿主机文件系统，那基本等于拿到物理机权限。这种漏洞在K8s环境里尤其致命，因为很多Pod默认就挂载了服务账号token，配合SSRF能直接操作整个集群。别问我怎么知道的，有个客户的渗透测试报告就是这么写的。