DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

The software you build is only as secure as the code that powers it. Learn how malicious code creeps into your software supply chain.

Apache Cassandra combines the benefits of major NoSQL databases to support data management needs not covered by traditional RDBMS vendors.

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Related

  • Identifying, Exploiting, and Preventing Host Header Attacks on Web Servers
  • Penetration Testing: A Comprehensive Guide
  • C# Applications Vulnerability Cheatsheet
  • How To Build Web Service Using Spring Boot 2.x

Trending

  • Cosmos DB Disaster Recovery: Multi-Region Write Pitfalls and How to Evade Them
  • Building Resilient Identity Systems: Lessons from Securing Billions of Authentication Requests
  • The Role of AI in Identity and Access Management for Organizations
  • Monolith: The Good, The Bad and The Ugly
  1. DZone
  2. Culture and Methodologies
  3. Career Development
  4. The Server Side Request Forgery Vulnerability and How to Prevent It

The Server Side Request Forgery Vulnerability and How to Prevent It

Learn how to protect your web application from SSRF vulnerabilities by learning what exactly they are and how bad actors can use them to target your system.

By 
Sven Morgenroth user avatar
Sven Morgenroth
·
Feb. 02, 18 · Tutorial
Likes (1)
Comment
Save
Tweet
Share
51.4K Views

Join the DZone community and get the full member experience.

Join For Free

Web applications can trigger inter-server requests, which are typically used to fetch remote resources, such as software updates, or to import data from a URL or other web applications. While such inter-server requests are typically safe, unless implemented correctly, they can render the server vulnerable to Server Side Request Forgery.

Introduction to Server Side Request Forgery

A Server Side Request Forgery (SSRF) vulnerability allows an attacker to change a parameter used on the web application to create or control requests from the vulnerable server.

When information in a web application has to be retrieved from an external resource, such as an RSS feed from another website, server-side requests are used to fetch the resource and include it in the web application. For example, a developer can use a URL such as https://example.com/feed.php?url=externalsite.com/feed/ to retrieve the remote feed. If the attacker is able to change the URL parameter to localhost, then he is able to view local resources hosted on the server, making it vulnerable to Server Side Request Forgery.

If an attacker is able to control the destination of the server side requests they can potentially perform the following actions:

  • Abuse the trust relationship between the vulnerable server and others.
  • Bypass IP whitelisting.
  • Bypass host-based authentication services.
  • Read resources which are not accessible to the public, such as trace.axd in ASP.NET or metadata APIs in an AWS environment.
  • Scan the internal network to which the server is connected.
  • Read files from the web server.
  • View Status Pages and interact with APIs as the web server.
  • Retrieve sensitive information such as the IP address of a web server behind a reverse proxy.

Typical Exploitation of a Server Side Request Forgery Vulnerability

Since the attacker cannot send direct requests to the victim's server because they are blocked by a firewall, to scan an internal network the attacker has to:

  1. Send a request to the vulnerable web server that abuses the SSRF vulnerability.
  2. The web server makes a request to the victim's server which sits behind the firewall.
  3. The victim's server responds with the data.
  4. If the specific SSRF vulnerability permits it, the data is sent back to the attacker.

Repercussions of a Server Side Request Forgery Vulnerability

1. Abusing the Trust Relationship to the Affected Server

As a best practice, it is always good to keep the attack surface as small as possible, therefore access to certain ports or actions is often restricted to whitelisted machines only. In fact, servers usually have a trust relationship with other machines in order to easily share data and allow administrative tasks.

For example at a network level, this trust means a firewall only allows access to certain ports if the machine requesting access is on the same local network, or if its IP address is explicitly trusted.

At a software level, trust can be as follows: authentication is not required for some administrative tasks, as long as the IP is 127.0.0.1 or it is inside the internal network. Such trust can also be used as an additional security measure, to assure that even if an attacker knows the password, he cannot log in without access to the local network.

By exploiting an SSRF vulnerability, an attacker can circumvent the above restrictions and, for example, query other servers that trust the affected machine, or craft malicious requests to interact with certain ports that aren't accessible from the outside network. The attacker can, therefore, perform malicious actions on the server itself that would otherwise not be possible from the outside.

2. Scan Local or External Networks

By exploiting a Server Side Request Forgery vulnerability, attackers may be able to scan the local or external networks to which the vulnerable server is connected. Attackers typically use the time a page takes to load, error message, or banners of the service they are probing to determine whether the probe they are targeting is responding or not and to confirm if the tested port is open.

Example of How to Scan a Network via an Exploited SSRF Vulnerability

Imagine a service on a website that allows you to fetch remote jpeg images so it can determine their dimensions.

As a precaution, the service checks if there is a Content-Type header with the value "image/jpeg" in the response from the remote source. If there isn't, or if the content type is different, it returns the error "Please provide jpeg images only," since it assumes that the provided file is not a jpeg. If instead there is a problem connecting to the remote source, the service returns the error, "No image found!"

Let's see how attackers can use different inputs that affect the response of the service to determine if a host is up or not:

If we request https://victim.com/image.php?url=https://example.com/picture.jpg we get the height and width of the image, meaning that this is a valid picture with a correct Content-Type header.

Now let's try a different request and feed the server with an HTML file rather than an image; https://victim.com/image.php?url=https://example.com/index.html. In such cases, the response from the service is "Please provide jpeg images only," since the page loaded has the wrong Content-Type header, which is text/html.

Now let's request an invalid URL; https://victim.com/image.php?url=https://example.invalid/. The service returns the error "Image not found," meaning that there was an error fetching the remote resource.

Now that we know how the application behaves for different inputs we can try to abuse it. We know that a valid URL with a wrong or missing Content-Type header returns the error, "Please provide jpeg images only." That means that if we send the following request, https://victim.com/image.php?url=127.0.0.1:3306, and we get the error, "Image not found," then it means there is no response on 127.0.0.1 port 3306. If we get the error "Please provide jpeg images only," it means that there is a response from the server, thus a service is running on that port. Therefore we can use this method to probe different internal IP addresses and ports to make a complete scan.

3. Read Files From the Server

When the content of a remote resource is directly rendered to a page, there is a possibility that the attackers read the content of the files. As an example, consider a web service that removes all images from a given URL and formats the text. It works by first getting the response body of a given URL, then applies the formatting.

If we use the file:// URI instead of http:// or https:// we are able to read files from the local file system. For example, if we use the URI file:///etc/passwd we could print the content of the passwd file on Unix systems to the page. The same technique can be used to view the source code of the vulnerable web application.

Impacts of Server Side Request Forgery

As seen in the above examples, the impact of exploiting a Server Side Request Forgery vulnerability is almost always information disclosure, such as:

  1. It is possible to scan ports and IP addresses.
  2. Interact with some protocols such as Gopher, which allow you to make further discoveries.
  3. Discover the IP addresses of servers running behind a reverse proxy.
  4. Remote code execution.

There are several other things attackers can do when exploiting an SSRF vulnerability, some of which can have more severe consequences, but it mainly depends on how the web application uses the responses from the remote resource.

Preventing Server Side Request Forgery (SSRF)

To prevent SSRF vulnerabilities in your web applications, it is strongly advised to use a whitelist of allowed domains and protocols from where the web server can fetch remote resources.

Also, as a rule of thumb, you should avoid using user input directly in functions that can make requests on behalf of the server. You should also sanitize and filter user input, but it is typically very hard to implement mainly because it is virtually impossible to cover all the different scenarios.

An attacker can:

  • Use encoded IP addresses which will be translated to an IP in an internal network.
    • 1 -> same as localhost
    • 123.123.123 -> same as localhost
  • Supply hostnames that resolve to internal IP addresses.
  • Bypass host blacklisting by applying dots at the end of the hostname.

This is only a small portion of bypasses that attackers have in their arsenal, therefore it is recommended to avoid user input in functions that issue requests on behalf of the server.

Requests Vulnerability Web Service application Web server Network workplace Web application Database

Published at DZone with permission of Sven Morgenroth, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Identifying, Exploiting, and Preventing Host Header Attacks on Web Servers
  • Penetration Testing: A Comprehensive Guide
  • C# Applications Vulnerability Cheatsheet
  • How To Build Web Service Using Spring Boot 2.x

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: