Server-Side Request Forgery (SSRF) Attack Explained: Definition, Types, Protection

A Server-Side Request Forgery attack (SSRF) is a web app vulnerability that hackers use to bypass firewall or VPN protection of internal systems.

An SSRF attack can enable malicious actors to access sensitive data or gain control of other systems. If they get the server to establish connections to random external systems, threat actors will be able to read or update internal resources.

This means they could:

• read web server configuration information like AWS metadata
• connect to internal services like HTTP-enabled databases
• send post requests to internal services that should not be exposed.

DNS security is, in this case, a critical defense layer against data leakage and authorization credentials exposure.

Key takeaways:

• SSRF attacks are a way of bypassing firewall protection
• The three types of SSRF attacks are: blind, semi-blind, and non-blind
• hackers use Server-Side Request Forgery to access data, steal authentication credentials, launch DoS attacks
• SSRF prevention measures include DNS filtering, patching, zero-trust policies, and network segmentation.

How Does a Server-Side Request Forgery (SSRF) Attack Work?

During an SSRF attack, the hacker gets the server to make HTTP requests to internal resources or other servers. They craft a custom-made URL that the server will access and then return the result to the attacker.

In the process, it exposes information or allows the hacker to access the resources. The server’s trust in the client’s request enables the threat actor to bypass security measures and access protected resources.

Here is how the Common Weakness Enumeration community describes the process:

By providing URLs to unexpected hosts or ports, attackers can make it appear that the server is sending the request, possibly bypassing access controls such as firewalls that prevent the attackers from accessing the URLs directly.

The HTTP protocol is not the only support for SSRF. Usually, hackers make the first request using HTTP. However, if it is the app that makes the second request, then they’ll use other protocols, like FTP, SMB, SMTP, etc., and schemes: file:/, phar:/, gopher:/, data:/, dict:/, etc. too.

SSRF attacks happen in two cases an depends on the application’s configuration and requirements:

• The app is allowed to send requests only to other approved applications
• The app can query any external IP address or domain name

What Are the Risks of SSRF?

• Internal network resources – SSRF attacks help threat actors obtain access to internal network resources such as databases and private IP addresses.

• Remote systems – if they succeed in gaining access to other servers, which is possible through an SSRF attack, hackers will also be able to launch further attacks.

• Local files – the attacker could access sensitive files stored on the server, such as configuration files or sensitive user data.

• Third-party services – hackers can access third-party services, such as APIs.

• Authentication credentials – SSRFs can retrieve authentication credentials, such as passwords or API keys. Hackers can use those for further attacks.

• Firewall bypass – an SSRF vulnerability can enable bypassing firewalls and other network security measures.

• DoS attack on the network’s internal servers – By using SSRF threat actors could flood the internal servers with traffic and crash the internal servers.

To better understand what could happen during this type of cyberattack, watch this video:

Server-Side Request Forgery Attack Types:

Depending on the server’s response to the initial request, there are three types of SSRF attacks.

Blind SSRF

In this instance, the original request returns no information about the target service. The adversary will give a URL, but he will not receive any data from it. He will have to use a vulnerability detection tool to check if the server is vulnerable. This can be achieved by determining it to make DNS or HTTP queries to a server he already controls.

Semi-Blind SSRF

Unlike the blind SSRF, the semi-blind instance does return some information. The adversary will gain access to some data, but not the entire lot:

• an error message
• metadata about a request, like response times, etc.

While this kind of result is enough to validate the vulnerability it doesn’t expose any sensitive data.

Non-Blind SSRF

The most harmful of all is usually the non-blind SSRF. Data from an arbitrary URL can be exfiltrated and sent to the threat actors who made the query. The non-blind SSRF enables hackers access to information that will help them launch other attacks.

Server-Side Request Forgery Attacks Prevention Measures

URL validation helps handle incoming queries safely and is the first step in preventing SSRF vulnerabilities. Use a whitelist of approved URLs and enforce DNS filtering to make sure the server cannot make external requests to arbitrary services. Don’t allow queries to endpoints with private (non-routable) IP addresses. Further on, apply these additional prevention measures:

• Restrict request protocols like ftp://, gopher://, or file://
• Validate user input properly
• Create a zero-trust architecture that enforces that all elements of the application environment frequently revalidate one another.
• Use URL encoding to properly encode and decode user inputs, reducing the risk of malicious URLs being processed by the server.
• Segment internal networks from external networks. Use a separate network segment, with restricted access, for the server so it stays isolated from sensitive internal resources. Hackers will have a harder job trying to access internal systems by launching an SSRF attack.
• Regularly scan for vulnerabilities to identify and remediate network flaws, including SSRF vulnerabilities.
• Patch and update all assets in time, including servers. Automate the patch management process to keep up with closing software vulnerabilities.

How Can Heimdal® Help Mitigate SSRF Attacks

Practicing prevention is always wiser, and more convenient, than waiting for the threat actors to make the first move. Heimdal’s innovatory solutions help organizations protect their servers and networks against SSRF vulnerabilities and other harmful actions.

With 96% accuracy in predicting future threats, Heimdal’s DNS Security spots and blocks any malicious URLs that could mess up your system.

The DarkLayer Guard 2-way traffic filtering engine included in Heimdal’s DNS Security Endpoint solution offers professional blacklisting. Blacklisting is one of the largely recommended security measures against SSRF attacks.

DarkLayer Guard helps your team block unwanted network communication to reduce Zero Hour exploits, Ransomware C&C’s, next-gen attacks, and data leakages.

By using the intelligence that it gains when blocking threats at the DNS, HTTP, and HTTPS level, DarkLayer Guard empowers you to stop active attacks and also speed up the forensic process. It tracks down and helps reinforce against potential threats any vulnerable endpoints your organization may have.

Wrapping Up

Although SSRF attacks are not that common, this type of vulnerability remains a risk factor for organizations.

Not later than last year, cyber researchers discovered four of Microsoft Azure’s Services were vulnerable to full server-side request forgery (SSRF) attacks.

Fortunately, in that instance, the security issues were patched in a timely manner, but obviously it is not always the case. Prevention remains the smartest aproach in tackling DNS server and network security.

Server-Side Request Forgery FAQs

Can hackers automate SSRF attacks?

Yes, hackers can use automated tools and scripts to scan for and exploit SSRF vulnerabilities. One of their techniques is to scan for open ports or attempt interacting with known services.

How do malicious actors use SSRF attacks?

Through SSRF attacks, malicious actors can further:

• Port scan internal servers for mapping
• Access local files like /etc/shadow or /etc/passwdin , to collect sensitive data
• Access the metadata of network stored cloud services
• Run a Remote Code Execution (RCE) attack
• Launch DoS attacks

Who can be target of a SSRF attack?

Internal network services, cloud service metadata endpoints, file systems, and databases are frequent targets of Server-Side Request Forgery attacks.

What is the difference between SSRF and CSRF?

CSRF vs SSRF are different by targets and attack vectors. In a CSRF attack, the hacker tricks the user to submit a request to a web application on which the user is authenticated. They act at a browser level. In SSRF, the threat actors manipulate the server into querying other servers or resources within the internal network to get unauthorized access to internal resources. The attack happens at a server level.

If you liked this article, follow us on LinkedIn, Twitter, Facebook, Youtube, and Instagram for more cybersecurity news and topics.