SSRF — A Practical Guide

Problem Framing

Server-Side Request Forgery (SSRF) is a critical web security vulnerability that allows an attacker to induce a server-side application to make unintended HTTP requests to an arbitrary domain of the attacker's choosing. This can manifest as the server acting as an involuntary proxy, enabling attackers to probe internal networks, access sensitive cloud metadata, exfiltrate data, or even achieve Remote Code Execution (RCE) by chaining SSRF with other vulnerabilities.

The ubiquity of interconnected systems, cloud services, and microservice architectures has significantly amplified the impact and prevalence of SSRF attacks. Modern applications often integrate with numerous external and internal services, parse user-provided URLs, or fetch external resources. Any scenario where an application constructs a network request based on user-supplied input without rigorous validation presents a potential SSRF vector. Attackers exploit this trust boundary, using the server's network position and privileges to bypass security controls like firewalls and access resources that would otherwise be unreachable.

SSRF is particularly dangerous when it grants access to cloud provider metadata endpoints, such as 169.254.169.254 in AWS, Azure, and GCP, which often contain temporary credentials or sensitive instance information ^{[1][2][3][4][5][6]}. Compromising these credentials can lead to complete cloud account takeover ^{[7][8][9][10][11][12]}. Furthermore, SSRF can be chained with other vulnerabilities like XML External Entity (XXE) injection, Cross-Site Scripting (XSS), or direct command injection to achieve more severe outcomes, including RCE ^{[13][14][15][16][17][18][19][20]}.

The complexity of modern applications, including LLM integrations, AI agents, and complex microservice architectures, introduces new attack surfaces for SSRF. For instance, AI agents might fetch external URLs or process model inputs that can be manipulated to trigger SSRF ^{[21][22][23][24]}. The exploitation of SSRF vulnerabilities is often rapid and widespread, as demonstrated by coordinated exploitation surges observed against various platforms ^{[25][26][27][28]}.

Core Mechanics

At its heart, SSRF exploitation hinges on the application's failure to properly validate and sanitize user-supplied input that is subsequently used to construct a network request. The fundamental process involves an attacker providing a malicious URL or a URL component that, when processed by the server, causes it to initiate an outbound request to a target chosen by the attacker.

The core mechanics revolve around:

• User Input as a Request Component: Applications that accept URLs, file paths, resource identifiers, or any string that can be interpreted as part of a network request are susceptible. This includes fields for webhooks, profile picture URLs, image uploads, API endpoints, external resource fetching, or even webhook delivery mechanisms ^{[29][30][15][31][32]}.
• Server-Side Request Execution: The application uses the provided input to construct and execute an HTTP request from the server's context. This request can be directed to internal IPs (e.g., 127.0.0.1, 10.0.0.0/8, 192.168.0.0/16), private cloud metadata endpoints (e.g., 169.254.169.254) ^{[1][2][3][4][5][6]}, or any publicly accessible IP address.
• Bypassing Security Controls: The server's network position often grants it access to resources that are protected by firewalls or are only accessible from within the trusted network perimeter. SSRF circumvents these controls by originating the request from within the network boundary ^[33][34].

Common vulnerable functions or patterns include:

• Functions that fetch content from a URL: file_get_contents() (PHP), requests.get() (Python), curl (command-line), fetch() (JavaScript) ^[35][36].
• PDF generation libraries that process HTML or external stylesheets ^{[37][38][39][40][41][19]}.
• Image processing utilities that fetch remote images for resizing or validation ^[9][42].
• Webhook delivery systems that make outbound requests to attacker-controlled URLs ^{[29][30][31][43][32]}.
• API endpoints that fetch data from external sources based on user input.
• Features that interact with cloud services, especially those involving fetching configuration or credentials.

Notable Techniques

Attackers employ a diverse range of techniques to discover and exploit SSRF vulnerabilities, often creatively bypassing input validation and filtering mechanisms.

Accessing Internal Resources and Cloud Metadata

A primary goal is to access internal services or cloud metadata. This is achieved by providing internal IP addresses or specially crafted URLs to the vulnerable function. Cloud metadata services, such as AWS's EC2 Instance Metadata Service (IMDS) at 169.254.169.254, are prime targets, as they often expose temporary credentials, instance identities, and sensitive configuration data ^{[1][2][3][4][5][6][9][44][10][11][12][45]}. Attackers can use these credentials to pivot within the cloud environment, gain access to S3 buckets, RDS instances, or even escalate privileges ^[4][7][9].

http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME is a common pattern used to extract credentials ^[37]. Targeting Kubernetes API servers can also reveal internal service endpoints ^[46].

Bypassing Filters and Validation

Defenses against SSRF typically involve allowlisting trusted domains, blocklisting known malicious IPs, and validating URL schemes. Attackers have developed numerous methods to circumvent these:

• IP Address Obfuscation: Using alternative representations of IP addresses like decimal (2130706433 for localhost) ^{[47][48][49][50]}, octal (017700000001) ^[51], hexadecimal, or binary formats can bypass simple IP address filtering. IPv6-mapped IPv4 addresses (e.g., http://[0:0:0:0:0:ffff:127.0.0.1] or http://[::ffff:127.0.0.1]) are also effective for targeting localhost ^[52].
• URL Parsing Discrepancies: Exploiting differences in how URLs are parsed by different libraries or components can lead to SSRF. For example, double encoding characters like '#' (%2523) can trick a validator while the fetcher resolves to localhost ^[53]. Unicode characters, such as the Ideographic Full Stop (%EF%BD%A1 or %E3%80%82), can also bypass localhost checks ^[54].
• HTTP Redirects: Attackers can chain open redirect vulnerabilities or manipulate HTTP redirect responses (301, 302, 307, 308) to point the server towards an internal resource or a controlled domain ^{[29][55][56][57][58][59][60]}. This is particularly effective if the validation occurs before the redirect handling ^[29][61].
• DNS Rebinding: This technique involves an attacker-controlled DNS server that initially resolves a domain to a safe IP (e.g., public IP), passing validation. After a short period, the DNS server is reconfigured to resolve the same domain to a private IP address (e.g., 127.0.0.1), allowing the already-made request to reach internal resources ^{[55][62][63][64][65][66]}.
• Scheme Manipulation: Beyond HTTP/HTTPS, attackers can leverage other URL schemes like file:// to read local files ^{[67][38][68][69]}, gopher:// to interact with arbitrary TCP services (e.g., Redis, Memcached) ^{[70][47][67][68][71][69][72][73]}, dict://, ldap://, sftp://, tftp://, netdoc://, and jar: ^{[67][68][71][69][72]}.
• Filename/Extension Bypasses: For features that validate file types (e.g., .yaml, .json), attackers might use tricks like ?a=example.yaml to circumvent restrictions ^[13].
• Host Header Injection: Manipulating HTTP headers like Host or X-Forwarded-Proto can trick the server into making requests to unintended internal hosts or services ^{[74][48][75][76][77][78][79][80]}.
• GraphQL and Other Protocols: Exploiting GraphQL introspection endpoints or using protocols like WebSockets with manipulated Origin headers can also lead to SSRF ^[81].

Chaining Vulnerabilities

SSRF is often a stepping stone to more critical vulnerabilities. Common chaining scenarios include:

• SSRF to RCE: By accessing internal services like Redis and sending crafted commands, attackers can achieve RCE ^{[13][14][70][82][83][84][72][18][85][73]}. This can involve writing to files, executing commands via cron jobs, or exploiting misconfigurations.
• SSRF to XXE: XXE vulnerabilities can be leveraged to trigger SSRF, allowing access to internal resources or cloud metadata ^{[16][17][86][87]}.
• SSRF to XSS: By exploiting SSRF in PDF generators or other context-aware rendering components, attackers can inject malicious scripts into generated content, leading to XSS ^[38][39][41].
• SSRF to Admin Access/Data Leakage: Accessing internal admin panels, user data, or sensitive configuration files is a common outcome ^{[88][89][43][90]}.
• SSRF via Header Injection: Manipulating headers can bypass filters and lead to SSRF or other injection attacks ^{[91][48][75][76][77][78][79][80]}.

Blind SSRF

In blind SSRF, the application does not return direct feedback to the attacker regarding the outbound request's success or failure. Attackers must rely on indirect methods to confirm exploitation:

• Out-of-Band (OAST) Methods: Using services like Burp Collaborator, Interactsh, or custom DNS/HTTP logging servers to receive callbacks when the server makes a request to the attacker-controlled domain ^{[92][93][24][94][95][12][96][97]}.
• Timing Attacks: Measuring response times to infer whether an internal service was reached or if a port was open ^[98][68][99].
• Error Messages: Analyzing error messages for clues about internal network interactions ^[99].

Specific Application Vulnerabilities

Many notable SSRF vulnerabilities have been disclosed in widely used software:

• SonicWall SMA1000: Exploited with SSRF chaining to RCE and credential extraction ^{[100][101][13][14]}.
• MLflow: SSRF exploited for cloud credential theft ^[102].
• Sentry MCP Server: SSRF allowing arbitrary endpoint calls ^[30].
• Next.js: Multiple SSRF vulnerabilities enabling middleware bypass ^[103][91].
• Azure OpenAI: Critical SSRF with CVSS 9.9 impacting RAG pipelines ^[21].
• LMDeploy: Rapidly exploited SSRF in load_image() ^[22].
• Oracle E-Business Suite: SSRF leading to RCE, exploited by ransomware ^{[82][83][84][104]}.
• Cisco Unified CM WebDialer: SSRF to root-level compromise ^[105][106].
• Node.js: Vulnerabilities in libraries like request and core modules ^[107][108].
• GitLab: SSRF via webhook headers or internal service access ^{[109][85][110]}.
• Axios: SSRF via redirect logic and header injection ^[91][111].
• Angular: SSRF via insecure header handling ^[48].
• AutoGPT: SSRF exposing sensitive information ^[112].
• ChatGPT: SSRF via pictureproxy.php or Custom GPT Actions ^[113][114].

Detection and Prevention

Effective SSRF detection and prevention require a multi-layered approach, focusing on both code-level validation and network-level controls.

Detection

• Static Application Security Testing (SAST): Analyzing source code for vulnerable functions that handle URLs or network requests without proper validation ^[115]. Tools like Snyk Code and Semgrep can identify suspicious patterns.
• Dynamic Application Security Testing (DAST): Automated scanners can probe applications for SSRF vulnerabilities by sending crafted URLs and monitoring for outbound callbacks or unexpected responses ^{[116][117][118][24][94][95][119][120]}.
• Manual Penetration Testing: Experienced testers use tools like Burp Suite to intercept requests, fuzz parameters, craft bypass payloads, and analyze application behavior to uncover SSRF flaws ^{[92][121][93][122][123][124][125][126][24]}.
• Out-of-Band Application Security Testing (OAST): Tools like Burp Collaborator or Interactsh are crucial for detecting blind SSRF by providing a unique endpoint that receives external DNS or HTTP requests when the vulnerable server makes an outbound call ^{[92][93][24][94][95][96]}.
• Code Review: Thorough review of code handling user-supplied URLs, external resource fetching, or network communication can identify potential SSRF risks.
• Log Analysis: Monitoring server logs for unusual outbound connection attempts to internal IPs or suspicious domains can indicate potential SSRF exploitation.

Prevention

Preventing SSRF requires a defense-in-depth strategy:

• Strict Input Validation: This is the most critical defense.
  • Allowlisting: Maintain a strict allowlist of trusted domains, IPs, and URL schemes. Reject any input that does not precisely match this list. This is generally more secure than blocklisting ^{[37][3][127][128][129][130][131][132][133]}.
  • URL Parsing and Sanitization: Use robust, well-tested URL parsers to validate and normalize input. Be aware of different URL formats, encoding schemes, and potential parser discrepancies ^{[29][134][58][68][65][35][135][136]}.
  • Disable Unnecessary Schemes: Explicitly disable dangerous URL schemes like file://, gopher://, dict://, ldap://, sftp://, tftp://, and netdoc:// unless absolutely required ^{[128][68][71][69][72][137]}.
• Network Segmentation and Egress Filtering:
  • Restrict Outbound Traffic: Implement strict egress filtering on servers and network devices to allow outbound connections only to necessary destinations. Deny all traffic to private IP ranges (RFC 1918) from public-facing servers ^{[74][128][138]}.
  • Least Privilege: Ensure that the server process runs with the minimum necessary network privileges.
• Cloud Security Best Practices:
  • Enforce IMDSv2: For AWS, always use IMDSv2 which requires a session token, preventing direct IMDSv1 credential access via SSRF ^{[37][5][7][139][6][45][138]}.
  • IAM Roles: Assign least-privilege IAM roles to instances and services.
  • Network Access Controls: Utilize security groups, network ACLs, and VPC endpoints to restrict access to metadata services.
• Disable Redirects: Configure HTTP clients and servers to disable or strictly limit automatic following of redirects, especially to internal networks or untrusted external domains ^[29][64][59].
• Use Secure Libraries: Employ security-vetted libraries for handling network requests and URL parsing. Consider using dedicated SSRF prevention libraries if available ^[115][140].
• Context-Aware Validation: Understand how user input is used. For example, if input is used in a PDF generation context, validate it for HTML/script injection that could lead to SSRF ^[38][39][40].
• Web Application Firewalls (WAFs): While not a foolproof solution, WAFs can help block common SSRF patterns and malicious IPs, but they are often bypassable with sophisticated techniques ^[50].

Tooling

A variety of tools are available to assist in the discovery, exploitation, and prevention of SSRF vulnerabilities:

• Burp Suite: Essential for manual testing, intercepting requests, fuzzing parameters, analyzing responses, and using extensions like Collaborator for OAST ^{[92][121][93][122][123][124][125][126][24][96][141]}.
• Burp Collaborator / Interactsh: Used for detecting blind SSRF via out-of-band interactions ^{[92][93][24][94][95][96]}.
• SSRFmap: An automated SSRF fuzzer and exploitation tool that supports various modules for port scanning, file reading, and Redis exploitation ^{[117][120][142]}.
• Nuclei: A fast and customizable vulnerability scanner that can be used with templates to discover SSRF vulnerabilities ^[143][136].
• Gopherus: Generates Gopher protocol payloads for exploiting SSRF to achieve RCE ^{[71][72][142]}.
• See-SURF: A Python-based scanner for identifying potential SSRF parameters ^[142].
• SSRF-Sheriff: A simple SSRF testing sheriff ^[142].
• surf: Returns a list of viable SSRF candidates ^[142].
• ipfuscator: A tool for generating alternative IP address representations to bypass filters ^[65][142].
• r3dir: A redirection service to bypass SSRF filters ^[144][142].
• Singularity / dref: Tools for automating DNS rebinding attacks ^[65][141].
• CNAPPgoat: A vulnerable-by-design deployment tool for practicing SSRF exploitation in cloud environments ^[145].
• autoRepeater: For automatic SSRF discovery and blind SSRF detection ^[94][95].
• HTTP/2 Smuggling Tools: Such as http2smugl, for exploiting HTTP/2 vulnerabilities ^[146].
• TryHackMe/PortSwigger Web Security Academy: Platforms for learning and practicing SSRF exploitation through hands-on labs and challenges ^[147][141].
• Microsoft AntiSSRF: An open-source library for preventing SSRF in .NET and Node.js applications ^[115].
• Drawbridge: A drop-in SSRF protection library for Python's requests or httpx ^[140].

Recent Developments

The landscape of SSRF vulnerabilities and exploitation techniques continues to evolve rapidly. Recent developments highlight several key trends:

• AI and LLM Infrastructure Attacks: SSRF is increasingly found in AI/ML frameworks, LLM applications, and AI agents. Attackers are targeting how these systems fetch external data, load models, or interact with APIs, leading to potential credential theft and internal network access ^{[21][22][23][24][112][113][148][149]}.
• Cloud-Native Exploitation: Exploitation targeting cloud metadata services (IMDSv1/v2, Google Cloud Metadata, Azure Instance Metadata) remains a significant threat, often facilitated by SSRF vulnerabilities. The move to IMDSv2 has been a crucial mitigation, but legacy systems or misconfigurations still pose risks ^{[37][5][7][139][6][45][138][145]}.
• Sophisticated Bypass Techniques: Attackers continue to refine methods for bypassing SSRF filters, including advanced URL parsing tricks, DNS rebinding, TOCTOU race conditions, and protocol smuggling via HTTP/2 ^{[29][55][150][62][64][107][65][151][60][66]}.
• Coordinated Exploitation Surges: Security researchers have observed coordinated surges in SSRF exploitation attempts, with hundreds of IPs targeting multiple CVEs simultaneously across various platforms, indicating organized threat actor activity ^{[25][26][27][28]}.
• Chaining for RCE: The trend of chaining SSRF with other vulnerabilities like XXE, command injection, and specific application flaws to achieve RCE remains prominent and highly impactful ^{[13][14][15][16][82][83][84][18][85][73][19][20]}.
• SSRF in Less Obvious Places: Vulnerabilities are being found in PDF generators, image processing functions, webhook handlers, and even in core libraries like Axios and Wget, demonstrating the widespread nature of the threat ^{[37][38][39][40][152][153][111]}.
• Tooling Advancement: The development of more sophisticated automated scanning and exploitation tools, including those leveraging OAST and AI, aids attackers in discovering and weaponizing SSRF vulnerabilities more efficiently ^{[24][94][95][120][154]}.

Where to Go Deeper

For those seeking to deepen their understanding and practical skills in Server-Side Request Forgery, the following resources and areas of focus are highly recommended:

• OWASP Resources: The OWASP Top 10 consistently features SSRF, and the OWASP Testing Guide provides methodologies for identifying these vulnerabilities ^[155][69].
• PortSwigger Web Security Academy: Offers extensive, hands-on labs and learning paths covering SSRF fundamentals, exploitation techniques, and bypasses ^{[88][136][141]}.
• Bug Bounty Platforms: Engaging with platforms like HackerOne, Bugcrowd, and Intigriti provides exposure to real-world SSRF findings, bounties, and discussions within the security community ^{[156][122][43][24][40][157][158][159][160][161][162][154][36]}.
• Security Blogs and Write-ups: Following security researchers' blogs and detailed write-ups on specific CVEs or exploitation techniques offers invaluable insights into the latest tactics ^{[100][29][102][163][103][21][61][37][164][165][15][16][3][4][22][55][82][83][84][144][150][62][38][166][167][63][5][98][168][91][169][109][170][171][172][140][173][174][48][134][175][75][176][31][121][93][177][23][116][178][179][180][17][33][128][114][181][182][183][104][184][185][186][187][51][139][76][77][78][188][122][189][56][190][57][191][123][58][46][68][64][107][71][65][192][6][193][34][69][124][117][194][125][99][72][195][129][196][197][8][108][18][89][52][43][126][85][198][39][9][73][199][200][79][80][90][24][201][202][203][40][204][205][206][44][112][94][95][10][11][12][32][207][113][26][27][28][130][131][208][132][209][210][211][212][213][157][45][49][50][214][215][216][138][152][153][42][151][81][145][158][159][160][149][217][218][120][35][110][60][219][66][135][136][161][162][154][36][220][221][111][222][223][224][225][226][141][142][97][146][41][227][228][229][19][230][20]}.
• Tooling Documentation: Explore the GitHub repositories and documentation for SSRF-related tools to understand their capabilities and usage ^{[46][117][218][120][141][142]}.
• Cloud Security Documentation: Understand the security configurations and metadata services of cloud providers (AWS, Azure, GCP) to better grasp SSRF targets and attack vectors ^{[37][3][5][6][138]}.
• Conference Talks and Presentations: Many security conferences feature talks on SSRF, providing cutting-edge research and practical demonstrations.