Server-Side Request Forgery (SSRF): Definition & Defense

During a server-side request forgery (SSRF), an attacker uses routine, everyday commands to dig into secret parts of your server or take it over altogether. 

SSRF begins with a security vulnerability. A piece of your code allows a hacker to manipulate or twist common server responses. And if hackers perform the attack successfully, the intruder will be very hard to detect. Your server will believe that the hacker is an authorized user.  

How does an SSRF attack work?

Your server has active, ongoing conversations with every website visitor. A hacker twists one part of these talks during an SSRF attack. 

In a typical SSRF attack, a hacker:

• Selects. The hacker looks for a URL or code that your server will either read or respond to.
• Begins. The hacker builds a request that seems innocent on the surface. It may seem like a normal request for a product type, for example. 
• Alters. The hacker will change this normal request to one for resources deep within your server, far behind the firewall. The hacker might also use this process to gain admin access to the server. 

SSRF attacks can originate with URL strings. Your intruder may alter where the server looks for data or how the server handles the query. But SSRF attacks can also originate with a schema that identifies how the server returns data. 

Some intruders launch SSRF server attacks. They don't visit your /admin URL directly, but after a bit of fancy footwork with coding and URL manipulation, they can access the admin section from the outside. Meanwhile, your server believes that the request comes from an inside, authenticated user. Your firewalls and intruder alarms are worthless in these situations, as the server believes the work is valid.

Intruders can also launch SSRF attacks against backend systems, even if they have private IP addresses. Again, you may never know this issue is occurring.

How could a SSRF attack hurt you?

Hackers typically use SSRF vulnerabilities to target systems you think are protected by firewalls. If they get inside, the impact could be significant. 

Your hacker could use a SSRF attack to:

• Deflect. The hacker identifies a third party and launches an attack from your server. The victim believes you're responsible for the damage. 
• Build. The hacker might connect arbitrary hosts on your internal network. 
• Loop. The hacker might connect back to services running on your application server. When this happens, your firewall restrictions are circumvented. 

Attackers have used the technique recently in devastating attacks. For example, in 2019, hackers breached security protections at Capitol One and stole data from more than 106 million people. It's widely acknowledged that SSRF techniques were used in this episode.  

SSRF attack prevention plans

During a successful SSRF attack, the intruder is typically behind your firewall. You can't rely on your routine, everyday detection devices to spot the breach. 

Talk with your ISP and security provider about detection tools. Some companies have screening tools made just for this kind of attack. Use them, and you could ensure that the problem doesn't persist.

You can also take commonsense prevention steps, including:

• Whitelisting. Identify the DNS names and IP addresses your applications can access. 
• Blocking. Don't allow schemas that you don't need for routine, everyday work. 
• Tightening. Use a zero-trust approach to security and require constant revalidation. 

At Okta, we believe in the power of the zero-trust approach. In fact, we've been recognized as a leader in Zero Trust Security. Find out more about how this approach works and how you can implement it. 

References

Server Side Request Forgery. OWASP. 

Capital One Breach: What Security Teams Can Do Now. (August 2019). Dark Reading. 

Server-Side Request Forgery (SSRF): Exploitation Technique. (October 2020). Infosec. 

SSRF 101: How Server-Side Request Forgery Sneaks Past Your Web Apps. (February 2020). Dark Reading.