去年某电商平台被曝出一个漏洞：攻击者能通过商品详情页的漏洞图片加载功能，让服务器去访问内网数据库的危害管理接口。结果呢？漏洞几十万用户的收货地址、手机号被打包带走。危害这个漏洞就是漏洞SSRF，服务器端请求伪造。危害听起来挺技术，漏洞但它的危害破坏力远比大多数人想象的要大得多。

SSRF的漏洞核心问题是：服务器太信任用户输入的URL了。你让服务器去抓个图片，危害它就真去抓了。漏洞但你传的危害不是图片地址，而是漏洞http://169.254.169.254/latest/meta-data/，这是危害云服务器的元数据接口。AWS、漏洞阿里云、腾讯云都存在这个地址。服务器一访问，IAM凭证、临时密钥全回来了。攻击者拿到这些，就能直接操作你的云资源。这不是理论，2019年Capital One那场著名的数据泄露，就是SSRF配合云元数据接口，一亿多用户的信用信息被拖走。

内网探测是另一个重灾区。企业内网通常有大量不设防的服务——Redis、Elasticsearch、Memcached、内部管理后台。这些服务在外网访问不到，但服务器自己能访问。攻击者构造一个SSRF请求，就能让服务器当跳板，扫内网端口、读Redis里的缓存数据、甚至往Elasticsearch里写恶意数据。我见过一个案例，攻击者通过SSRF访问内网的Jenkins，直接执行了远程命令，从一台边缘Web服务器一路打到了核心数据库。

文件读取也跑不掉。很多SSRF漏洞支持file://协议。服务器上有什么？配置文件、SSH私钥、环境变量文件、源代码。一个file:///etc/passwd就能看到系统用户列表，file:///proc/self/environ能读到环境变量里的数据库密码。有些应用还会把SSRF的响应内容回显给攻击者，那就更直接了——服务器帮你把文件内容读出来，你只需要在浏览器里等着。

还有更隐蔽的玩法：用SSRF打内网服务的未授权漏洞。比如内网的Docker API默认监听2375端口且无认证，攻击者通过SSRF调用/containers/create，挂载宿主机根目录，然后启动容器，直接拿到宿主机root权限。整个过程不需要任何外部工具，一个URL请求就够了。这种攻击链在红队演练里屡试不爽。

DoS攻击也不能忽略。让服务器去请求一个超大文件，或者构造一个会无限重定向的URL，服务器的内存和连接数瞬间被吃满。如果SSRF点在一个高并发的接口上，几秒钟就能把服务打挂。这种破坏方式技术含量低，但效果立竿见影。

最麻烦的是，SSRF经常和其他漏洞组合。一个普通的URL参数，配合CRLF注入，就能构造出完整的HTTP请求，攻击内网的Gopher服务。配合DNS重绑定，还能绕过基于域名白名单的防护。很多开发者在修复时只加了黑名单，过滤了127.0.0.1，但0x7f.0.0.1、2130706433、[::1]这些变形照样能过。防护难度比SQL注入高得多，因为URL的解析规则在不同语言、不同库之间差异巨大。

说到底，SSRF把服务器变成了攻击者的代理。服务器能访问什么，攻击者就能访问什么。而服务器通常站在内网的核心位置，手里握着数据库凭证、云API密钥、内部服务的访问权限。一个看似不起眼的URL参数，可能就是整个内网沦陷的起点。