去年帮一个朋友看代码，漏洞他写了个图片抓取功能，易出用户传个URL，现对后端就去下载。起请求我扫了一眼，地方问他：“你这儿校验目标地址了吗？漏洞”他说加了黑名单，127.0.0.1和localhost都禁了。易出我笑了笑，现对用`http://0x7f000001`试了一下，起请求服务器直接去请求了本机的地方redis。这就是漏洞SSRF最典型的样子——任何“让服务器替你去访问某个地址”的功能，都是易出它的温床。

说白了，现对SSRF本质上是起请求服务端请求伪造，攻击者诱导服务器向内部系统或第三方发起请求。地方问题出在哪儿？出在“信任边界”上。前端传来的URL，后端拿来就用，中间没有严格的校验和限制。那哪些地方容易出这种事儿？我按自己挖洞和审代码的经验，列几个重灾区。

一、图片/文件远程加载

这个太常见了。用户头像上传支持“从URL导入”，富文本编辑器插入网络图片，PDF生成服务拉取远程模板……后端拿到URL后，通常用curl、requests、HttpClient之类的库直接请求。攻击者把URL改成`http://169.254.169.254/latest/meta-data/`，云服务器的元数据就泄露了。我在某次众测里，就是靠一个“从URL导入头像”的功能，读到了AWS的临时凭证。

二、Webhook与回调通知

现在很多系统支持配置Webhook，比如GitHub的push事件通知、支付回调、告警推送。你填一个URL，平台就会往那儿发POST请求。这个“填URL”的动作，就是SSRF的入口。攻击者填`http://internal-service:8080/admin/deleteAll`，如果内网服务没有鉴权，可能直接触发危险操作。更隐蔽的是，有些系统会返回请求结果或错误详情，攻击者能借此探测内网端口开放情况。

三、URL预览与爬虫

社交产品里发链接自动生成卡片，OA系统里粘贴URL自动抓标题，这些“预览”功能背后都是服务端去抓取目标页面。我见过一个论坛，发帖时输入URL，后台会抓取该页面的title和favicon。用`http://127.0.0.1:6379`试一下，返回的错误信息里直接暴露了redis的版本号。这种功能往往还伴随DNS重绑定问题——第一次解析到公网IP通过校验，第二次解析到内网IP发起请求。

四、文件处理与转换

在线文档转换、视频转码、图片压缩，这些服务经常需要从远程拉取源文件。比如“从URL导入PPT转PDF”，后端去下载那个PPT。如果URL指向`http://localhost:9200/_cat/indices`，Elasticsearch的索引列表就出来了。更狠的是，有些转换工具支持`file://`协议，直接读本地文件。

五、API代理与调试接口

有些开发为了方便，留了个`/proxy?url=`的接口，或者Swagger调试页面能直接发请求。这类接口往往没做鉴权，或者只做了简单的域名白名单。我曾经遇到一个`/api/fetch?target=`，把target改成`http://169.254.169.254/latest/user-data`，直接拿到了服务器的启动脚本，里面有数据库密码。

这些地方的共同点是：用户可控的输入，被服务端当成了请求目标。防御思路其实不复杂——白名单限制域名和协议，禁止跳转，解析后校验IP是否在私有网段，禁用非HTTP协议。但现实是，很多开发者只做了字符串匹配，`http://127.0.0.1`禁了，`http://0177.0.0.1`就漏了。SSRF的绕过姿势太多了，进制转换、DNS重绑定、302跳转、IPv6映射……防不胜防。

我的习惯是，看到任何“填URL”的地方，先试`http://127.0.0.1:80`，再看返回时间判断端口是否开放。如果返回很快，说明端口开着；如果超时，说明被防火墙挡了。这招在实战里屡试不爽。SSRF不像SQL注入那么直接，但它能撬开的内网入口，往往比一个注入点值钱得多。