Ssrf Server Side in APIs

SSRF (Server-Side Request Forgery) is a critical web security vulnerability where an attacker manipulates a server to make unauthorized requests to internal or external resources. Unlike client-side attacks, SSRF exploits the server's ability to send HTTP requests on behalf of the client.

The vulnerability occurs when an API or web application accepts a user-controlled URL and fetches data from that URL without proper validation. The server becomes a proxy for the attacker's requests, potentially accessing internal systems, cloud metadata services, or other sensitive resources that would normally be inaccessible from the public internet.

Common SSRF scenarios include:

• Fetching images or content from user-provided URLs
• Webhook callbacks to attacker-controlled endpoints
• API integrations that process external URLs
• Cloud service metadata endpoint access
• Internal network reconnaissance

APIs are particularly vulnerable to SSRF because they often process external data and integrate with various services. An attacker can exploit SSRF to achieve multiple objectives:

• Data Exfiltration: Access internal APIs, databases, or configuration files
• Internal Network Mapping: Discover services running on internal networks
• Cloud Metadata Access: Retrieve AWS metadata (169.254.169.254), Azure instance metadata, or GCP metadata endpoints
• Port Scanning: Test which ports are open on internal systems
• Authentication Bypass: Access internal services that trust the application server's IP

Real-world impact includes the 2019 Capital One breach where SSRF in a WAF allowed access to AWS metadata, leading to the theft of 100 million customer records. Another example is the 2020 Verizon Media breach where SSRF in a video processing API exposed internal systems.

SSRF can also be chained with other vulnerabilities. For instance, an SSRF vulnerability might allow an attacker to access an internal Redis instance, then use a Redis RCE to execute commands on the server, creating a complete compromise chain.

Detecting SSRF requires both manual testing and automated scanning. Here are the key detection methods:

• URL Parameter Testing: Test endpoints that accept URLs with various payloads like http://localhost, http://169.254.169.254, and file:// URLs
• Protocol Variation: Try different protocols (http, https, ftp, file, gopher) to see what the server accepts
• IP Address Manipulation: Use localhost (127.0.0.1), internal IPs (10.x, 192.168.x, 172.16.x), and RFC1918 ranges
• Cloud Metadata Endpoints: Test cloud-specific metadata endpoints like 169.254.169.254 (AWS), 169.254.169.254 (Azure), or 169.254.169.254 (GCP)
• Time-Based Analysis: Monitor response times to detect internal vs external requests

middleBrick Detection Approach: middleBrick's automated scanning includes comprehensive SSRF testing across 12 security categories. The scanner tests for SSRF by attempting to access internal resources, cloud metadata endpoints, and various protocols. It analyzes responses for indicators of successful SSRF attempts, such as differences in response content, timing, or error messages that reveal internal system access.

The scanner also checks for proper input validation and rate limiting on URL parameters, as weak validation is a primary SSRF enabler. middleBrick's black-box approach means it tests the actual running API without requiring credentials or source code access, making it effective at finding SSRF vulnerabilities that might be missed by code review alone.

Preventing SSRF requires a defense-in-depth approach with multiple security controls:

Input Validation and Sanitization

Implement strict URL validation using allowlists rather than blocklists. Only allow specific, trusted domains and protocols:

function validateUrl(inputUrl) {
  const url = new URL(inputUrl);
  
  // Allowlist of permitted protocols
  const allowedProtocols = ['https'];
  if (!allowedProtocols.includes(url.protocol)) {
    throw new Error('Invalid protocol');
  }
  
  // Allowlist of permitted domains
  const allowedDomains = ['trusted-api.com', 'cdn.example.com'];
  if (!allowedDomains.includes(url.hostname)) {
    throw new Error('Invalid domain');
  }
  
  return url;
}

Network-Level Controls

Implement network segmentation and firewall rules to prevent outbound requests to internal networks:

# Block internal network access
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -j DROP
iptables -A OUTPUT -d 127.0.0.0/8 -j DROP

# Block cloud metadata endpoints
iptables -A OUTPUT -d 169.254.169.254 -j DROP

Proxy and Request Filtering

Use a proxy service that validates requests before they leave your infrastructure:

const proxy = httpProxy.createProxyServer({
  secure: true,
  rejectUnauthorized: true,
  // Custom validation
  selfHandleResponse: true,
  onProxyReq: (proxyReq, req, res) => {
    const url = new URL(req.url);
    if (isInternalNetwork(url.hostname)) {
      proxyReq.abort();
      res.status(403).send('Forbidden');
    }
  }
});

Monitoring and Logging

Implement comprehensive logging for all outbound requests and monitor for suspicious patterns:

import logging
from datetime import datetime

def log_outbound_request(url, status):
    logger = logging.getLogger('outbound_requests')
    logger.info({
        'timestamp': datetime.now().isoformat(),
        'url': url,
        'status': status,
        'source_ip': request.remote_addr
    })

    # Alert on suspicious patterns
    if is_suspicious(url):
        alert_security_team(url)

SSRF vulnerabilities have caused some of the most significant data breaches in recent years. The 2019 Capital One breach, attributed to Paige Thompson, exploited an SSRF vulnerability in a WAF to access AWS metadata, leading to the theft of 100 million customer records and costing Capital One over $190 million in fines and settlements.

In 2020, a vulnerability in the Python Package Index (PyPI) allowed attackers to exploit SSRF to access internal infrastructure. The SolarWinds supply chain attack also involved SSRF-like techniques to access internal systems.

Cloud environments are particularly susceptible to SSRF. Many cloud providers use predictable metadata endpoints (like 169.254.169.254 for AWS) that can be accessed if an application has outbound internet access. Attackers can use SSRF to retrieve temporary credentials, configuration data, and even access other cloud resources.

According to OWASP, SSRF is ranked #9 in their Top 10 API Security Risks, and the vulnerability continues to appear in modern applications due to the increasing complexity of API integrations and the difficulty of properly validating all possible input sources.