SSRF服务端请求伪造如何限制

wen 网络安全 2026-07-22 1

本文目录导读：

SSRF服务端请求伪造如何限制

目录导读
SSRF漏洞的本质与危害
企业级SSRF限制的六大核心原则
实战问答：SSRF限制常见误区
典型SSRF限制方案代码实现示例
构建从代码到网络的SSRF纵深防线

SSRF服务端请求伪造攻击原理与精准限制策略实践指南

目录导读

SSRF漏洞的本质与危害
企业级SSRF限制的六大核心原则
- 1 白名单策略的精确配置
- 2 协议与端口的最小化授权
- 3 内网地址的强制过滤
- 4 DNS解析的二次校验机制
- 5 响应超时与返回内容的限制
- 6 应用层安全的纵深防御
实战问答：SSRF限制常见误区
典型SSRF限制方案代码实现示例
构建从代码到网络的SSRF纵深防线

SSRF漏洞的本质与危害

SSRF（Server-Side Request Forgery，服务端请求伪造）是一种攻击者通过控制服务器端发起恶意请求的安全漏洞，其核心危害在于：攻击者可以绕过网络访问控制，直接攻击内网中的数据库、云服务元数据接口（如AWS的254.169.254）、Redis缓存或容器编排系统。

典型案例：攻击者利用SSRF漏洞向云环境元数据服务发起请求，获取云服务商的临时访问密钥，进而窃取整个云账户中的敏感数据，据云安全联盟统计，约23%的云安全事件与SSRF利用有关。

企业级SSRF限制的六大核心原则

1 白名单策略的精确配置

最佳实践：拒绝通用黑名单方案，采用严格的域名/IP白名单。

仅允许请求api.example.com、cdn.example.net等业务域名
使用精确FQDN（完全限定域名）而非通配符
定期审计白名单,删除废弃域名

反例：allow://*会导致绕过风险。

2 协议与端口的最小化授权

关键限制：

协议层面：仅允许HTTP/HTTPS，禁用file://、dict://、gopher://等非HTTP协议
端口层面：普通业务不开放21、22、3306、6379、27017等管理端口，即使使用HTTP，也应限制目标端口为80、443、8080等标准Web端口

高频风险协议：SSRF恶意利用中，gopher://协议常用于攻击Redis（默认6379端口），dict://可探测内网服务指纹。

3 内网地址的强制过滤

必须屏蔽的地址范围：

IPv4内网：0.0.0/8、16.0.0/12、168.0.0/16
特殊保留：0.0.0/8、0.0.0/8、254.0.0/16
IPv6链路本地：fe80::/10
云元数据：254.169.254（AWS/GCP/Azure通用）

进阶注意：攻击者可能使用DNS解析绕开IP过滤，例如将恶意域名解析到0.0.1，因此需要配合二次校验。

4 DNS解析的二次校验机制

核心流程：

前端校验用户输入的原始字符串是否符合格式（如纯URL）
后端解析DNS后,再次校验解析出的IP地址是否属于内网/黑名单
对于可能的多IP响应,需全部校验通过方可发起请求

代码思路（Python伪代码）：

def validate_url(raw_url):
    parsed = urlparse(raw_url)
    # 第一次：域名白名单校验
    if parsed.hostname not in ALLOWED_DOMAINS:
        return False
    # 第二次：通过socket或dns库解析IP
    ips = socket.gethostbyname_ex(parsed.hostname)[2]
    for ip in ips:
        if is_private_or_forbidden(ip):  # 检测内网IP
            return False
    return True

5 响应超时与返回内容的限制

双重防护：

超时机制：设置严格单请求超时（如2秒），防止慢速响应消耗服务器资源限制**：
- 不可返回原始响应体（尤其禁用Data URI、二进制流）
- 限制返回数据量（如100KB内），防止SSRF用于大口径数据偷窃
- 进行JSON/HTML压缩清洗，过滤内网路径信息

6 应用层安全的纵深防御

低权限运行：发起请求的服务使用最小化系统账户，避免拥有读取/proc/1/environ等敏感操作权限
网络隔离：Web服务器所在子网与核心数据库/云服务管理网段物理隔离，通过API网关中转
日志审计：记录每次SSRF请求的源IP、目标URL、耗时、返回码，并触发异常告警（如请求失败率突增）

实战问答：SSRF限制常见误区

Q1：只屏蔽0.0.1和localhost就足够了吗？
A：远远不够，攻击者可能利用IPv6地址[::1]、十进制IP（如2130706433对应0.0.1）、短域名（http://0/在许多系统解析为0.0.1）、或DNS重绑定（先返回合法IP，请求时迅速改为内网IP），因此必须屏蔽所有内网段，并实施DNS二次校验。

Q2：使用HTTP防火墙（WAF）可以完全防御SSRF吗？
A：WAF能拦截已知攻击模式，但无法防御逻辑复杂的SSRF利用，

攻击者控制目标DNS（如用户域名evil.xyz动态解析到内网IP）
利用302跳转绕过域名白名单（请求先经过trusted.com/redirect，再跳转到file:///etc/passwd）因此WAF需配合服务端严格白名单和URL重定向净化。

Q3：限制协议为http/https后是否绝对安全？
A：不一定，某些框架（如Python Flask的requests库）默认支持重定向，攻击者可能构造http://trusted.com/redirect?target=file:///etc/shadow，必须对重定向后的URL同样进行白名单校验，或直接禁止跟随重定向。

Q4：内网服务需要被请求，该怎么办？
A：采用API网关代理方案：所有内网请求通过统一网关（如internal-api.example.com），网关只暴露有限端点（如/health），且仅允许特定Token访问，这样外网服务器的SSRF请求只能访问网关而非原始内网服务。

典型SSRF限制方案代码实现示例

Java Spring Boot 示例（核心部分）

public class SSRFRequest {
    // 1. 严格白名单 + 协议限制
    private final List<String> ALLOWED_HOSTS = Arrays.asList("api.example.com","cdn.example.net");
    public String safeFetch(String targetUrl) {
        // URL标准化处理
        URL url = new URL(targetUrl);
        if (!url.getProtocol().equals("http") && !url.getProtocol().equals("https")) {
            throw new SecurityException("Only HTTP(S) allowed");
        }
        // 2. 主机名初次匹配
        if (!ALLOWED_HOSTS.contains(url.getHost())) {
            throw new SecurityException("Host not allowed");
        }
        // 3. DNS解析后IP二次校验
        InetAddress[] ips = InetAddress.getAllByName(url.getHost());
        for (InetAddress ip : ips) {
            if (ip.isSiteLocalAddress() || ip.isLoopbackAddress() || ip.isLinkLocalAddress()) {
                throw new SecurityException("Internal IP not allowed");
            }
        }
        // 4. 禁用重定向跟随 + 设置超时
        HttpClient client = HttpClient.newBuilder()
            .followRedirects(HttpClient.Redirect.NEVER)
            .connectTimeout(Duration.ofSeconds(2))
            .build();
        HttpRequest request = HttpRequest.newBuilder()
            .uri(url.toURI())
            .timeout(Duration.ofSeconds(3))
            .build();
        return client.send(request, HttpResponse.BodyHandlers.ofString(StandardCharsets.UTF_8))
            .body()
            .substring(0, Math.min(102400, .length())); // 限制返回内容大小
    }
}

Nginx 反向代理层限制（基础防护）

server {
    # 禁止访问内网段
    location /execute {
        if ($arg_url ~* "(file|gopher|dict)://") { return 403; }
        set $target_url $arg_url;
        # 需配合第三方模块解析主机名并校验IP
        proxy_pass $target_url;
        proxy_connect_timeout 2s;
        proxy_read_timeout 3s;
        # 禁止重定向跟踪
        proxy_redirect off;
    }
}

构建从代码到网络的SSRF纵深防线

限制SSRF绝非单一规则能解决,而是需要多层过滤协同工作：

输入层：URL协议、主机名白名单、端口范围限制
网络层：DNS二次校验、禁用内网IP段、云元数据屏蔽
应用层：禁止重定向、限制响应内容、设置短超时
系统层：低权限运行、iptables规则限制出站连接至具体端口

开发者应通过自动化安全测试（如融入CI/CD的SSRF扫描工具）和人工代码审计双管齐下，不断优化限制策略，攻击者永远比黑名单快一步，唯有白名单、防御纵深和最小权限原则才能为你的应用构建真正的SSRF壁垒。

参考来源：OWASP SSRF防御指南（2024版）、云安全联盟SSRF最佳实践、各大云厂商安全文档等。