skip to Main Content
This website use cookies which are necessary to its functioning and required to achieve the purposes illustrated in the privacy policy. To learn more or withdraw consent please click on Learn More. By continued use of this website you are consenting to our use of cookies.

GLOSSARY

Server-Side Request Forgery (SSRF)

A Server-Side Request Forgery (SSRF) is a dangerous form of cyberattack initiated by application requests that flow between HTTP servers.

A Server-Side Request Forgery (SSRF) is a dangerous form of cyberattack initiated by application requests that flow between HTTP servers. These requests are often associated with accessing and retrieving software updates, or perhaps to import data or metadata from another web server. These requests are not inherently dangerous but must be done correctly. If not done correctly, then a server will be vulnerable to a Server-Side Request Forgery attack.  SSRF is a dangerous attack vector and therefore is prominently featured on the Open Web Application Security Project’s list of top ten web application security risks. 

Server-Side Request Forgery attacks involve a very specific set of procedures and execution by the threat actor. The threat actor will abuse functionality on the server to maliciously read or update internal resources. The threat actor can supply or modify a URL which will cause the server to read or submit data. Through manipulation of URLs, the threat actor may be able to read various server configurations, which create the opportunity for considerable harm. These server configurations may include connecting to internal services like HTTP-enabled databases, performing POST requests towards internal services that are not intended to be exposed, or even AWS metadata.

Ultimately, the targeted application may have a variety of functionality that can be compromised. This can include functionality for importing, publishing, tampering in some way, or reading data from a URL. The threat actor can modify the calls to this functionality by providing a completely different manipulated URL or by modifying how the URLs are built (for example, path traversal).

Once this manipulated URL arrives at the server, the server-side code tries to read the  manipulated URL. The threat actor may then access and read data from services that are not directly available on the internet. This can include:

  • Database HTTP interfaces such as MongoDB (NoSQL) provide a REST interface on HTTP ports. If authentication is disabled, then the threat actor can extract internal data using the REST interfaces.
  • The threat actor may be able to read files using file:// URLs. The threat actor may also use this functionality to import untrusted data into code that expects to only read data from trusted sources. This enables the threat actor to avoid input validation.
  • AWS cloud services, and others, provide a REST interface where important configuration and often authentication keys can be acquired.

A web application may access external resources that include internal services. If the threat actor is able to change the URL parameter to localhost, then this may allow them to view local server-hosted resources. If this is the case, then they are vulnerable to SSRF.

Viewed more aggressively, if a threat actor can control the destination of server-side requests, this might allow them to exploit and bypass many other controls and interfaces. This can include IP whitelisting, bypass host authentication services, perform port scans on the internal network connected to the server, retrieve and read files from the web server, interact with APIs as the web server, and much more.

As mentioned earlier, SSRF attacks can be quite dangerous. SSRF enables the threat actors to utilize as a target any system that passes requests to a third system. SSRF attacks can provide malicious threat actors access to internal systems never intended to be internet-accessible.

Defenders know that it is important to keep the attack surface as small as possible.it is best to restrict ports and actions on internal systems to specifically allow-listed machines. Servers often must have a trusted relationship with other servers. The exploit of an SSRF vulnerability allows the threat actor to get around these restrictions such that they can interact with other servers that trust the impacted server. 

The implications are disconcerting. Threat actors can send data queries or craft malicious requests to interact with ports that aren’t accessible from the outside network. By forging these server-side requests, an external threat actor can execute highly malicious actions on the target server, absolutely not be possible from the outside.

Threat actors can exploit an SSRF to scan local or external networks accessible from the vulnerable server. Threat actors can then use the page load time, error messages, and other extracted information to indirectly determine whether the targeted service is responding or perhaps a port is open.

The direct impact of exploiting an SSRF vulnerability is information disclosure. Threat actors obtain a lot of restricted information about systems that  should not be released. An SSRF can allow threat actors to:

  • Misdirect the exploited server as a port scanner – this can be used for both internal and external systems and devices.
  • Perform discovery of IP addresses of servers which are behind a reverse proxy.
  • Initiate remote code execution.

Because Server-Side Request Forgery is primarily an access channel for further probes and attacks, there are also many other possibilities, depending on how the vulnerable web application uses responses received from the remote resource. Combined with other vulnerabilities in suitable conditions, SSRF can have severe consequences.

Best practices to prevent SSRF 

Web applications should use an allow list of domains and protocols for remote resources accessed by the web server. Avoid using user input directly in any functions that can make requests on behalf of the server. Threat actors can use a wide variety of procedure to bypass URL filtering, such as:

  • Encoding IP addresses which will be translated to another IP resident in an internal network.
  • Use manipulated hostnames that resolve to internal IP addresses.
  • Avoid host stop listing (black listing) by applying additional dots at the end of the hostname, and more.

CSRF versus SSRF

Cross Site Request Forgery (CSRF) and SSRF are different types of attacks. CSRF attacks manipulate a user to take undesired actions on their online account. A threat actor can exploit a CSRF vulnerability successfully because the user is already authenticated properly, the cookie contains session information.

SSRF attacks exploit how a server processes external information. In some cases, web applications read information or write information to a specific URL (like a REST API). When a threat actor modifies the target URL, they generally can exfiltrate restricted information from the application. The wide use of REST APIs has made this more dangerous. Vulnerable applications could provide sensitive and restricted information to an attacker.

 

Want to learn more? Check out our FREE Bugcrowd University to sharpen your hacking skills.

Organizations the world over need your help! Join our researcher community to connect with hundreds of organization programs focused on finding their security vulnerabilities. Our vast directory includes programs for all skill levels, across many industries and from around the world.

Back To Top