top of page

Server-side request forgery (SSRF)

In this section we explain what server-side request forgery (SSRF) is, and describe some common examples. We also show you how to find and exploit SSRF vulnerabilities.

What is SSRF?

Server-side request forgery is a web security vulnerability that allows an attacker to cause the server-side application to make requests to an unintended location.

In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization's infrastructure. In other cases, they may be able to force the server to connect to arbitrary external systems. This could leak sensitive data, such as authorization credentials.

: Illustration showing how SSRF exploits server-side vulnerabilities to access internal resources.

Labs
If you're familiar with the basic concepts behind SSRF vulnerabilities and want to practice exploiting them on some realistic, deliberately vulnerable targets, you can access labs in this topic from the link below.

  • View all SSRF labs

What is the impact of SSRF attacks?
A successful SSRF attack can often result in unauthorized actions or access to data within the organization. This can be in the vulnerable application, or on other back-end systems that the application can communicate with. In some situations, the SSRF vulnerability might allow an attacker to perform arbitrary command execution.
An SSRF exploit that causes connections to external third-party systems might result in malicious onward attacks. these can appear to originate from the organization hosting the vulnerable application.
Common SSRF attacks
SSRF attacks often exploit trust relationships to escalate an attack from the vulnerable application and perform unauthorized actions. These trust relationships might exist in relation to the server, or in relation to other back-end systems within the same organization.
SSRF attacks against the server
In an SSRF attack against the server, the attacker causes the application to make an HTTP request back to the server that is hosting the application, via its loopback network interface. This typically involves supplying a URL with a hostname like 127.0.0.1 (a reserved IP address that points to the loopback adapter) or localhost (a commonly used name for the same adapter).
For example, imagine a shopping application that lets the user view whether an item is in stock in a particular store. To provide the stock information, the application must query various back-end REST APIs. It does this by passing the URL to the relevant back-end API endpoint via a front-end HTTP request. When a user views the stock status for an item, their browser makes the following request:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118 stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

This causes the server to make a request to the specified URL, retrieve the stock status, and return this to the user.

In this example, an attacker can modify the request to specify a URL local to the server:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://localhost/admin

The server fetches the contents of the /admin URL and returns it to the user.

An attacker can visit the /admin URL, but the administrative functionality is normally only accessible to authenticated users. This means an attacker won't see anything of interest. However, if the request to the /admin URL comes from the local machine, the normal access controls are bypassed. The application grants full access to the administrative functionality, because the request appears to originate from a trusted location.

Why do applications behave in this way, and implicitly trust requests that come from the local machine? This can arise for various reasons:

  • The access control check might be implemented in a different component that sits in front of the application server. When a connection is made back to the server, the check is bypassed.

  • For disaster recovery purposes, the application might allow administrative access without logging in, to any user coming from the local machine. This provides a way for an administrator to recover the system if they lose their credentials. This assumes that only a fully trusted user would come directly from the server.

  • The administrative interface might listen on a different port number to the main application, and might not be reachable directly by users.

These kind of trust relationships, where requests originating from the local machine are handled differently than ordinary requests, often make SSRF into a critical vulnerability.

SSRF attacks against other back-end systems

In some cases, the application server is able to interact with back-end systems that are not directly reachable by users. These systems often have non-routable private IP addresses. The back-end systems are normally protected by the network topology, so they often have a weaker security posture. In many cases, internal back-end systems contain sensitive functionality that can be accessed without authentication by anyone who is able to interact with the systems.

In the previous example, imagine there is an administrative interface at the back-end URL https://192.168.0.68/admin. An attacker can submit the following request to exploit the SSRF vulnerability, and access the administrative interface:

POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118 stockApi=http://192.168.0.68/admin

Circumventing common SSRF defenses

It is common to see applications containing SSRF behavior together with defenses aimed at preventing malicious exploitation. Often, these defenses can be circumvented.

SSRF with blacklist-based input filters

Some applications block input containing hostnames like 127.0.0.1 and localhost, or sensitive URLs like /admin. In this situation, you can often circumvent the filter using the following techniques:

  • Use an alternative IP representation of 127.0.0.1, such as 2130706433, 017700000001, or 127.1.

  • Register your own domain name that resolves to 127.0.0.1. You can use spoofed.burpcollaborator.net for this purpose.

  • Obfuscate blocked strings using URL encoding or case variation.

  • Provide a URL that you control, which redirects to the target URL. Try using different redirect codes, as well as different protocols for the target URL. For example, switching from an http: to https: URL during the redirect has been shown to bypass some anti-SSRF filters.

SSRF with whitelist-based input filters

Some applications only allow inputs that match, a whitelist of permitted values. The filter may look for a match at the beginning of the input, or contained within in it. You may be able to bypass this filter by exploiting inconsistencies in URL parsing.

The URL specification contains a number of features that are likely to be overlooked when URLs implement ad-hoc parsing and validation using this method:

  • You can embed credentials in a URL before the hostname, using the @ character. For example:

    https://expected-host:fakepassword@evil-host

  • You can use the # character to indicate a URL fragment. For example:

    https://evil-host#expected-host

  • You can leverage the DNS naming hierarchy to place required input into a fully-qualified DNS name that you control. For example:

    https://expected-host.evil-host

  • You can URL-encode characters to confuse the URL-parsing code. This is particularly useful if the code that implements the filter handles URL-encoded characters differently than the code that performs the back-end HTTP request. You can also try double-encoding characters; some servers recursively URL-decode the input they receive, which can lead to further discrepancies.

  • You can use combinations of these techniques together.

Read more

  • A new era of SSRF

Bypassing SSRF filters via open redirection

It is sometimes possible to bypass filter-based defenses by exploiting an open redirection vulnerability.

In the previous example, imagine the user-submitted URL is strictly validated to prevent malicious exploitation of the SSRF behavior. However, the application whose URLs are allowed contains an open redirection vulnerability. Provided the API used to make the back-end HTTP request supports redirections, you can construct a URL that satisfies the filter and results in a redirected request to the desired back-end target.

For example, the application contains an open redirection vulnerability in which the following URL:

/product/nextProduct?currentProductId=6&path=http://evil-user.net

returns a redirection to:

You can leverage the open redirection vulnerability to bypass the URL filter, and exploit the SSRF vulnerability as follows:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin

This SSRF exploit works because the application first validates that the supplied stockAPI URL is on an allowed domain, which it is. The application then requests the supplied URL, which triggers the open redirection. It follows the redirection, and makes a request to the internal URL of the attacker's choosing.

Blind SSRF vulnerabilities
Blind SSRF vulnerabilities occur if you can cause an application to issue a back-end HTTP request to a supplied URL, but the response from the back-end request is not returned in the application's front-end response.
Blind SSRF is harder to exploit but sometimes leads to full remote code execution on the server or other back-end components.
Read more

  • Finding and exploiting blind SSRF vulnerabilities

Finding hidden attack surface for SSRF vulnerabilities
Many server-side request forgery vulnerabilities are easy to find, because the application's normal traffic involves request parameters containing full URLs. Other examples of SSRF are harder to locate.
Partial URLs in requests
Sometimes, an application places only a hostname or part of a URL path into request parameters. The value submitted is then incorporated server-side into a full URL that is requested. If the value is readily recognized as a hostname or URL path, the potential attack surface might be obvious. However, exploitability as full SSRF might be limited because you do not control the entire URL that gets requested.
URLs within data formats
Some applications transmit data in formats with a specification that allows the inclusion of URLs that might get requested by the data parser for the format. An obvious example of this is the XML data format, which has been widely used in web applications to transmit structured data from the client to the server. When an application accepts data in XML format and parses it, it might be vulnerable to XXE injection. It might also be vulnerable to SSRF via XXE. We'll cover this in more detail when we look at XXE injection vulnerabilities.
SSRF via the Referer header
Some applications use server-side analytics software to tracks visitors. This software often logs the Referer header in requests, so it can track incoming links. Often the analytics software visits any third-party URLs that appear in the Referer header. This is typically done to analyze the contents of referring sites, including the anchor text that is used in the incoming links. As a result, the Referer header is often a useful attack surface for SSRF vulnerabilities. See Blind SSRF vulnerabilities for examples of vulnerabilities involving the Referer header.

Visual representation of an attacker manipulating HTTP requests to exploit SSRF vulnerabilities.
Image depicting SSRF bypassing firewall restrictions to access sensitive internal systems.
Graphic showing unauthorized server communication initiated by exploiting SSRF.

Server-Side Request Forgery (SSRF) Explained

Server-Side Request Forgery (SSRF) is a security vulnerability that occurs when an attacker can make the server perform unintended requests. This can happen when a web application accepts a user-supplied URL or other input and uses it to make server-side HTTP requests without proper validation or sanitization.

How SSRF Works

In an SSRF attack, the attacker tricks the server into sending HTTP requests to a domain of their choice. This can lead to various malicious outcomes, such as:

  1. Accessing Internal Systems: The attacker can probe and access internal systems that are not directly exposed to the internet.

  2. Exfiltrating Data: Sensitive information can be extracted from internal services.

  3. Bypassing Firewalls: The server, which might be behind a firewall, can be used as a proxy to bypass network restrictions.

  4. Scanning for Vulnerabilities: The attacker can scan for internal vulnerabilities that would otherwise be unreachable.

  5. Leveraging Trusted Relationships: If the server communicates with other services using a trusted network, the attacker can exploit this trust.

Example of SSRF Attack

Consider a web application feature that fetches content from a URL provided by the user. The application sends a request to the URL and displays the content on the page. If the URL is not properly validated, an attacker can supply a URL pointing to an internal service:

http

Copy code

http://example.com/fetch?url=http://internal-service.local/admin

If the server blindly requests this URL, it might expose sensitive internal information or allow the attacker to perform administrative actions on the internal service.

Types of SSRF

  1. Basic SSRF: The attacker directly controls the URL or endpoint the server requests.

  2. Blind SSRF: The attacker can make the server perform requests but cannot directly see the response. However, they can infer information based on server behavior or side-channel information.

  3. CSRF to SSRF: Cross-Site Request Forgery (CSRF) is used to exploit SSRF, where a user’s browser is tricked into making a request on behalf of the attacker, leveraging the user's authentication.

Impact of SSRF

  • Data Leakage: Access to internal services can lead to exposure of sensitive data, including configuration files, metadata services, and internal APIs.

  • Remote Code Execution (RCE): In some cases, SSRF can be used to execute arbitrary code on internal services.

  • Denial of Service (DoS): Repeated or crafted requests can overwhelm internal services, leading to denial of service.

  • Internal Network Scanning: Attackers can map internal networks and identify vulnerable services.

Mitigation Strategies

  1. Input Validation:

    • Strictly validate and sanitize user input to ensure only allowed URLs can be used. Use whitelisting to permit only specific, safe domains.

  2. Access Controls:

    • Implement network segmentation and strict access controls to limit the server's ability to communicate with internal systems or sensitive endpoints.

  3. Outbound Request Filtering:

    • Configure the server to restrict or deny outgoing requests to internal or untrusted networks. Use firewalls or similar mechanisms.

  4. Use of Safe Libraries and Functions:

    • When possible, use libraries or functions that handle URLs and network requests securely, avoiding direct inclusion of user input in requests.

  5. Metadata Services Protection:

    • Block access to cloud provider metadata services from web-accessible servers, as these can often be targeted in SSRF attacks.

  6. Regular Security Testing:

    • Conduct security assessments, including penetration testing and code reviews, to identify and remediate SSRF vulnerabilities.

Conclusion

Server-Side Request Forgery is a powerful and dangerous attack vector that can have severe implications for an organization's security. By understanding how SSRF works and implementing robust mitigation strategies, organizations can protect their systems from being exploited through such vulnerabilities. Regular security practices, including input validation, access control, and ongoing testing, are essential to safeguarding against SSRF attacks.



Advantages and Disadvantages of SSRF in Ethical Hacking

Advantages of SSRF (from an ethical hacker's perspective)

  1. Identifying Internal Network Vulnerabilities: Ethical hackers can use SSRF to discover hidden internal services and infrastructure that are not exposed to the public internet. This helps organizations understand their internal attack surface and identify weak points that could be exploited by malicious actors.

  2. Testing Internal Service Security: SSRF allows ethical hackers to test the security of internal services, APIs, and microservices. This can help identify misconfigurations, weak authentication mechanisms, and other vulnerabilities that need to be addressed.

  3. Bypassing Network Segmentation: Ethical hackers can use SSRF to test the effectiveness of network segmentation and firewall rules. By demonstrating how an attacker could bypass these defenses, organizations can improve their network security architecture.

  4. Comprehensive Security Assessment: Incorporating SSRF testing in security assessments provides a more thorough evaluation of an organization's security posture. It ensures that both external and internal threats are considered and mitigated.

  5. Raising Awareness: Demonstrating the impact of SSRF vulnerabilities can raise awareness among developers and system administrators about the importance of securing internal services and validating user inputs.

Disadvantages of SSRF (from an ethical hacker's perspective)

  1. Complexity of Exploitation: SSRF vulnerabilities can be complex to exploit, especially in blind SSRF scenarios where the attacker does not receive direct feedback. This requires a high level of skill and understanding of the target environment.

  2. Potential for Collateral Damage: If not carefully controlled, SSRF attacks during testing can cause unintended disruptions or damage to internal services. Ethical hackers must exercise caution to avoid negatively impacting the organization's operations.

  3. Limited Scope Without Context: The effectiveness of SSRF testing depends on the context and the specific environment. Without detailed knowledge of the internal network and services, it may be challenging to demonstrate the full impact of SSRF vulnerabilities.

  4. Legal and Ethical Considerations: Ethical hackers must obtain explicit permission and operate within the agreed scope when testing for SSRF vulnerabilities. Unauthorized or out-of-scope testing can lead to legal issues and damage the trust relationship with the client.

Conclusion

SSRF is a valuable tool in the arsenal of ethical hackers for uncovering and mitigating vulnerabilities that could be exploited by malicious attackers. By leveraging SSRF, ethical hackers can provide organizations with a deeper understanding of their internal security posture and help them strengthen their defenses against sophisticated attacks. However, ethical hackers must navigate the complexities and risks associated with SSRF testing carefully, ensuring that their activities are conducted legally, ethically, and with minimal disruption to the target environment.



Function of SSRF (Server-Side Request Forgery)

Server-Side Request Forgery (SSRF) is a security vulnerability where an attacker tricks a server into making unintended requests to internal or external resources. This is achieved by exploiting the server's capability to send HTTP requests, typically by manipulating URL input parameters or other request components that are insufficiently validated.

Key Functions of SSRF:

  1. Internal Network Access:

    • Purpose: Access internal systems not exposed to the public internet.

    • Example: An attacker supplies a URL that points to an internal service, such as http://internal-service.local/admin.

  2. Data Exfiltration:

    • Purpose: Retrieve sensitive data from internal servers.

    • Example: An attacker uses SSRF to read configuration files or sensitive endpoints, such as http://localhost:8080/config.

  3. Scanning Internal Networks:

    • Purpose: Identify internal services, open ports, and other potential attack vectors.

    • Example: An attacker makes requests to a range of IP addresses and ports to map the internal network.

  4. Bypassing Security Controls:

    • Purpose: Circumvent firewalls and access controls that restrict direct access.

    • Example: Using the server as a proxy to reach otherwise inaccessible services.

  5. Exploiting Trust Relationships:

    • Purpose: Exploit the trust the server has with other internal services.

    • Example: Accessing a metadata service in a cloud environment, such as AWS EC2 instance metadata, via http://169.254.169.254/latest/meta-data.

  6. Remote Code Execution (RCE):

    • Purpose: Execute arbitrary commands on the server or other systems.

    • Example: Crafting a request that triggers command execution through vulnerable internal services.

Scope of SSRF

Scope refers to the extent and impact of SSRF vulnerabilities within an application or system. It encompasses the range of potential targets, the severity of exploitation, and the overall consequences for the affected organization.

Key Aspects of SSRF Scope:

  1. Internal vs. External Targets:

    • Internal Targets: SSRF can be used to access internal services that are not exposed to the public internet, such as databases, internal APIs, or administrative interfaces.

    • External Targets: In some cases, SSRF can be used to target external services, potentially leveraging the server’s network position or trust relationships.

  2. Blind SSRF:

    • Nature: The attacker does not receive direct feedback from the server’s response.

    • Scope: The scope is limited to inferential actions, such as observing changes in server behavior, response times, or side-channel data.

  3. Full SSRF:

    • Nature: The attacker receives the full response from the server’s request.

    • Scope: The scope is broader, allowing the attacker to gather detailed information, extract data, and perform more complex interactions.

  4. Severity Levels:

    • Low Severity: Limited to probing and information gathering without direct data extraction or control.

    • Medium Severity: Allows access to sensitive internal data or services but does not directly compromise critical systems.

    • High Severity: Enables control over internal systems, potential data exfiltration, or significant disruption.

    • Critical Severity: Full system compromise, remote code execution, and the ability to propagate further attacks within the network.

  5. Business Impact:

    • Financial Loss: Potential theft of sensitive financial data or disruption of financial services.

    • Reputational Damage: Loss of customer trust due to data breaches or service disruptions.

    • Operational Disruption: Impact on business operations due to compromised internal services or system downtime.

    • Legal and Regulatory Consequences: Breaches can lead to regulatory fines and legal actions, especially when sensitive customer data is involved.

Mitigation Strategies for SSRF

  1. Input Validation and Sanitization:

    • Ensure user inputs are strictly validated and sanitized. Avoid using user-supplied data directly in server-side requests.

  2. Allowlisting and Denylisting:

    • Implement allowlists for permissible URLs and denylists for known malicious or internal addresses.

  3. Network Segmentation:

    • Use network segmentation to isolate critical internal services and reduce the potential impact of SSRF attacks.

  4. Restricting Outbound Requests:

    • Configure firewalls and server settings to restrict outbound HTTP requests to trusted domains only.

  5. Using Safe Request Libraries:

    • Employ libraries and functions that handle URLs securely and prevent SSRF vulnerabilities.

  6. Monitoring and Logging:

    • Implement robust monitoring and logging to detect and respond to suspicious request patterns indicative of SSRF attempts.

Understanding the function and scope of SSRF is crucial for developing effective defenses against this type of vulnerability, ensuring the security of both internal and external network resources.

bottom of page