什么是SSRF

1. SSRF漏洞

1.1 业务场景

在一些业务场景下，WebApp允许用户上传一个URL，后端服务器会访问加载这个URL的资源，或返回给用户或进行其他业务逻辑处理。很经典的一个例子是百度识图。

正常用户会填写一个图片URL，百度服务端接收这个url参数并访问，之后就是“识图”的业务逻辑。类似这种在服务端访问用户传入的URL的场景还有：

1.2 代码demo

我们这里自己写一个可以加载用户传入url的JavaWeb的小demo。其功能也很简单，通过GET请求获取url参数，通过Java的网络编程基础类库URL去访问url资源并响应给用户。

import jakarta.servlet.ServletException;
import jakarta.servlet.annotation.WebServlet;
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;

import java.io.IOException;
import java.io.InputStream;
import java.io.PrintWriter;
import java.net.URL;
import java.net.URLConnection;

@WebServlet("/ssrf")
public class SSRFVulnerableServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {

        //? 获取请求传入的URL
        String requestUrl = req.getParameter("url");

        //? 创建URL对象
        URL url1 = new URL(requestUrl);

        //? 获取返回包打印流对象
        PrintWriter writer = resp.getWriter();
        try {
            //? openConnection()方法会根据URL中的协议建立相应连接，返回一个连接对象
            URLConnection urlConnection = url1.openConnection();
            //? 从远程连接创建输入流，
            InputStream in = urlConnection.getInputStream();
            int readByte = 0;
            //? 读取该远程url的资源,并响应给请求
            while ((readByte = in.read()) != -1) {
                System.out.print((char)readByte);
                writer.write((char)readByte);
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

我们在浏览器访问并通过burp抓包，发现可以完成我们想要的功能。乱码只是我们读写文件时的不规范，这里我们暂且忽略。

1.3 漏洞原理

SSRF（Server-Side Request Forgery，服务端请求伪造）是一种由攻击者构造请求由Web服务端发起请求的安全漏洞。一般情况下，SSRF的攻击目标时外网无法访问的内部系统。

上面的业务场景和demo，功能点都是服务端提供了从其他服务器应用获取数据，如过没有对目标地址做过滤和限制，则会形成SSRF。可以总结出来的核心风险点就是：用户控制URL + 服务器发起请求。假如我们传入的参数是这样：url=file:///d:/1.txt，则有可能触发本地文件读取；

类似file://这样的伪协议能否被成功解析访问，依赖于后端的代码。我们的demo中使用java.net.URL类中openConnection()方法 ，该方法会根据URL中的Schema进行不同的操作，解析到file://时，底层实际是返回一个Java 的 File 对象，用于对本地的文件读取。

不同的操作系统、编程组件对URI解析支持各有差异，并不是存在SSRF漏洞就一定能通过各种URI协议进行访问。

2. URI Schema

URI协议（URI Scheme） 是 统一资源标识符（URI） 的重要组成部分，用于定义如何访问和解释某个资源。它位于URI的最开头（如 http://、file://），决定了后续部分的解析规则和访问方式。

URI协议本质上是一种 资源访问规则，它告诉应用程序（如浏览器、服务器）应该使用哪种协议或方法去定位和操作目标资源。例如：

• http://：表示通过HTTP协议访问Web资源。
• file://：表示直接读取本地文件系统中的文件。
• mailto:：表示触发邮件客户端发送邮件。

IANA注册协议：官方URI协议列表。URI Schema 只是资源访问的抽象标识，并不局限于网络协议，它包含更广泛的资源访问方式

1. 映射到网络协议

   • http/https → 使用HTTP/HTTPS协议访问Web资源。
   • ftp → 使用FTP协议传输文件。
   • gopher → 使用Gopher协议发送自定义TCP请求。

2. 不涉及网络通信

   • file → 直接读取本地文件（无网络交互）。
   • data → 内联数据（如Base64编码的文本）。
   • javascript → 在浏览器中执行脚本代码。

2.1 示例对比

1. 场景：访问一个网页

   • URI Scheme：http://example.com
     • 作用：告诉浏览器“使用HTTP协议访问该资源”。
     • 底层网络协议：HTTP协议（定义如何与服务器通信）。
   • 关系：URI Scheme http 映射到底层网络协议 HTTP。

2. 场景：读取本地文件

   • URI Scheme：file:///etc/passwd
     • 作用：告诉浏览器“直接读取本地文件，无需网络通信”。
     • 底层网络协议：无（不涉及网络传输）。
   • 关系：URI Scheme file 不依赖任何网络协议。

2.2 SSRF中常用URI schema

● http://
● file:// 从文件系统读取内容
● dict:// 字典服务协议
● sftp:// SSH文件传输协议/安全文件传输协议
● ldap:// 轻量级目录访问协议
● tftp:// 简单文件传输协议
● gopher:// 分布式文档传递服务，可使用 gopherus 生成payload

3. 漏洞利用（内网探测流程）

3.1 file://（探测内网存活主机）

• file:///etc/passwd 读取系统用户信息
• file:///etc/hosts 读取当前操作系统网卡的IP
• file:///proc/net/arp 读取arp缓存表（寻找内网其他主机）
• file:///proc/net/fib_trie 读取当前网段路由信息

3.2 dict://（探测主机开放端口/服务）

3.3 http://（目录扫描）

3.4 gopher://

4. 修复防御

1. 输入规范化与过滤
   • 解析URI时，检查协议类型、目标IP和端口（如禁止访问内网IP段）。
2. 白名单校验
   • 仅允许访问预设的域名或IP
3. 协议白名单
   • 仅允许业务必需的协议（如 http、https），禁用 file、gopher、dict 等高风险协议。
4. 网络层隔离
   • 使用防火墙或安全组规则，禁止服务器访问非必要的内部服务（如数据库、元数据接口）
5. 禁用URL重定向

5. 总结

SSRF（Server-Side Request Forgery，服务器端请求伪造）漏洞的本质是：服务器过度信任用户提供的资源标识符（如URL、IP地址等），未严格验证其合法性，导致攻击者可操纵服务器向非预期的目标发起网络请求，从而绕过安全边界，访问或攻击受限资源。

---

核心拆解

1. 信任边界失效
   • 服务器默认用户提供的目标地址是合法的，未检查其是否符合业务逻辑范围（例如是否属于内网IP、敏感协议或域名）。
   • 例如：用户上传头像时提交一个URL，服务器直接请求该URL，但未验证其是否指向外部攻击者控制的地址或内部系统。
2. 利用服务器权限
   • SSRF的独特之处在于：攻击者通过服务器发起请求，而非直接通过客户端。
   • 服务器通常拥有更高的网络权限（如访问内网、云元数据接口、file://协议读取本地文件），这些权限被攻击者间接滥用。
3. 绕过安全防护
   • 防火墙规则通常允许服务器与内网服务自由通信，但禁止外部直接访问。
   • SSRF通过服务器的“合法身份”穿透防火墙，直接与内部系统（如数据库、管理后台）交互。
4. 逻辑问题 > 技术问题
   • SSRF的根源并非代码实现漏洞（如缓冲区溢出），而是业务逻辑设计缺陷。
   • 开发者未意识到“服务器发起的请求”可能被用户操控，导致信任模型错误。
5. 攻击面扩大器
   • SSRF本身可能无法直接利用，但结合其他漏洞（如云元数据接口暴露、内网服务弱口令）会引发链式攻击，例如：
     • 通过http://169.254.169.254/latest/meta-data/获取云服务器凭据。
     • 通过gopher://协议攻击内网Redis服务，实现远程代码执行。

参考

[1] SSRF漏洞原理
[2] 小迪安全v2023
[3] SSRF漏洞挖掘
[4] deepseek
[5] 《Web安全攻防 渗透测试实战指南》