ssrf漏洞原理

服务器请求伪造（SSRF）的漏洞核心是攻击者让一台服务器代替自己去访问本不该访问的资源。听起来有点绕？原理换个说法：你公司内网有一台数据库管理后台，外网根本连不上，漏洞但你的原理Web服务器能连。如果攻击者能控制Web服务器去请求那个后台，漏洞他就等于借了服务器的原理“手”摸到了内网。

这事怎么发生的漏洞？很多Web应用需要从外部获取资源。比如一个“给图片加水印”的原理功能，用户提交一个图片URL，漏洞服务器就去下载那张图。原理代码可能长这样：

$url = $_GET['url']; $content = file_get_contents($url); echo $content; 

问题出在file_get_contents不挑食。漏洞你传http://example.com/logo.png，原理它去下载图片。漏洞你传http://127.0.0.1:8080/admin，原理它就去访问本机的漏洞8080端口。如果内网有http://192.168.1.1/secret，它照样跑过去。攻击者不需要直接接触内网，服务器成了他的跳板。

我见过一个真实案例。某在线文档平台允许用户从URL导入文档。攻击者提交了http://169.254.169.254/latest/meta-data/。这是AWS云服务器的元数据地址，只有服务器自己才能访问。结果服务器乖乖地把IAM临时凭证返回给了攻击者。凭证泄露，攻击者直接接管了该账号下的S3存储桶。一个URL输入框，毁掉了整个云环境。

SSRF的利用方式远不止读文件。攻击者可以扫描内网端口——通过响应时间判断端口是否开放。可以攻击内网Redis，发送http://192.168.1.100:6379这样的请求，如果Redis没设密码，就能写入SSH公钥或者计划任务。还能绕过防火墙访问只允许本地访问的API，比如http://localhost/api/deleteUser?id=1。

为什么这种漏洞屡禁不止？因为开发者往往只做了表面过滤。有人写if (strpos($url, '127.0.0.1') === false)，攻击者用http://0177.0.0.1或者http://2130706433就绕过了。有人只允许http协议，攻击者用file:///etc/passwd照样读文件。还有人用DNS重绑定——第一次解析到合法IP，第二次解析到内网IP，时间差里完成攻击。

防御SSRF得从架构上动手。最有效的一招：不让服务器直接访问用户提供的URL。把下载任务丢给一个独立的代理服务，那个服务部署在DMZ区，只能访问外网。或者干脆用白名单，只允许访问预先批准的几个域名。如果非要动态获取，那就解析URL的IP，检查是否属于内网段（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、127.0.0.0/8、169.254.0.0/16），并且禁止跟随重定向。

还有个容易被忽略的点：响应内容不要原样返回给用户。有些应用会把服务器请求到的内容直接显示出来，这等于把内网信息拱手送上。哪怕只是返回“成功”或“失败”，也能减少信息泄露。

SSRF的可怕之处在于它把服务器变成了攻击者的代理。你信任自己的服务器，服务器信任内网，攻击者利用这种信任链。每次看到某个功能接受URL参数，我都习惯性地想：这个URL能不能指向内网？如果答案是肯定的，那漏洞就在那里。