What Is SSRF?

Introduction

SSRF stands for Server-Side Request Forgery.

The word “Forgery” literally means “falsification.”

From the name alone, it may not be immediately clear what is being “forged.” A useful way to understand SSRF is to begin by asking who is actually making the request.

When we normally visit a website, the user’s browser connects to a Web server. But Web services can also include features in which the server communicates with another location based on information received from the user.

Examples include:

• importing an image from a specified URL
• fetching information from a linked page to generate a preview
• automatically notifying a registered destination when an event occurs (a webhook)
• converting a Web page into a PDF
• testing connectivity from the server to an integration target

None of these features is unusual in modern Web services. The features themselves are not inherently dangerous. The important question is who can determine the destination, and to what extent.

A destination is not limited to a website on the public Internet. From the server’s point of view, a service running on the same host or an API inside an organization can also be a destination.

1. The Server Goes to Fetch It on Your Behalf

Consider a link-preview feature. When you paste a URL into a social network or chat service, the page title, description, or image may appear automatically.

Depending on how the service is designed, the user’s browser may not retrieve that information directly. Instead, the Web application’s server may connect to the URL and fetch the information itself.

From the user’s point of view, this is similar to asking the service, “Go take a quick look at what is at this URL.” In practice, however, the user provides information indicating where to connect, and the server uses that information to make the connection.

Here, “user” includes not only ordinary users but also someone who deliberately tries to specify a destination outside what the service expects.

User
  ↓  provides a URL or similar information
Web application
  ↓  the server actually makes the connection
Destination resource or service

This structure itself is normal. Image importing, webhooks, document conversion, and similar features may legitimately use information received from a user to make server-side connections elsewhere.

The SSRF problem arises when information influenced by the user can cause server-side communication to be directed to a target outside the scope that should be permitted for that function.

For example, suppose the designer expects users to specify only public Web pages. In practice, however, the feature may allow the user to specify even internal services visible from the server. When there is a gap between the scope the feature is intended to allow and the scope of destinations it can actually be made to contact, that gap can lead to an SSRF problem.

2. Users and Servers May Have Different Reachability

The user’s device and the server may not have access to the same parts of the network.

Think of this in terms of a building. The user is a person standing outside the building, while the server is someone already inside. Suppose the person outside asks the person inside, “Please go and look at this room.”

The person outside may not be able to enter that room directly, while the person inside may be able to reach it. The ability of someone inside the building to move around may be completely normal for doing their job. The problem is that the person outside may be able to use that ability to send the person inside to places the outsider should not be able to request.

Server-side communication can have a similar structure. A service that the user cannot reach directly may still be reachable from the server.

Examples include:

• administrative services on the same host or an internal network
• internal APIs or backend services
• a mechanism that allows a virtual machine in a cloud environment to retrieve information about the running instance itself (an instance metadata service)

The component that actually makes the connection is not necessarily the Web server that accepted the input. Another component, such as a document converter or a background job, may perform the communication instead. In that case, what matters is what that particular component can reach.

3. A Server May Have Different Privileges or Trust Than the User

Reachability alone is not enough to explain the possible impact of SSRF. Another important factor is the server’s privileges and trust relationships.

Continuing the building analogy, a person inside the building may have more than simple physical access. They may carry an employee badge, or a security guard may recognize them as an employee.

In other words, where someone can go and what they are allowed to do once they get there are separate questions.

The same can be true for a server. A destination may treat requests from the server differently from requests made directly by a user. For example, an internal system may treat requests differently depending on the network location from which they originate. Some systems may also attach credentials to legitimate requests sent by the server.

However, SSRF communication does not necessarily include credentials. Reaching information related to credentials through SSRF is also a different issue from a configuration in which credentials are attached to the server’s legitimate outbound communication.

When evaluating the impact of SSRF, it is therefore necessary to consider separately what the server can reach and what the server is permitted to do once it reaches that destination.

4. The Basic Structure of SSRF

We can now summarize the mechanism.

The basic structure of SSRF is easier to understand as four stages:

1. The user provides information—such as a URL, destination, or document—that can affect server-side communication.
2. The server uses that information to communicate with another destination.
3. Information influenced by the user causes the communication to be directed to a target outside the scope that should be permitted for that user or function.
4. As a result, effects such as retrieving information, performing an action, or communicating with a third party may occur.

Steps 1 and 2 alone do not constitute an SSRF problem. Allowing a user to specify a URL and having the server retrieve it may be a legitimate, correctly designed feature.

The vulnerability arises when, as in Steps 1 through 3, server-side communication can be directed to a target outside the scope that should be permitted for the function. Step 4 describes the possible impact that may result from the vulnerability.

For the purposes of understanding the mechanism in this chapter, we use the following Working Definition:

SSRF is a problem in which information influenced by a user causes server-side communication to be directed to a target outside the scope that should be permitted for that user or function.

Here, “the scope that should be permitted” does not simply mean whether the designer happened to anticipate a particular destination. It means whether, in light of the purpose of the feature and its authorization model, that destination falls within the scope the user should be free to choose.

How SSRF Differs from CSRF

A similarly named term is CSRF, or Cross-Site Request Forgery.

Broadly speaking, CSRF is a problem in which the browser and authentication state of a logged-in user—the victim—are used to cause an unintended request to be sent. SSRF, by contrast, is a problem in which the server’s communication capability, reachability, or trust relationships are used to cause an unintended request to be sent.

The detailed conditions under which the two vulnerabilities occur are different, but a useful way to distinguish them is to ask whose communication capability or trust is being used.

5. What Makes SSRF Dangerous?

The existence of an SSRF vulnerability does not necessarily mean that severe damage will occur. The impact depends on what the server can connect to, what those destinations provide, and what kinds of requests the server is capable of sending.

Representative impacts can be organized into three categories.

Reaching Information That Was Not Intended to Be Public

The server may be able to reach information that was not intended to be exposed to users, such as internal status information or administrative data.

Triggering Operations on Internal Services

If a destination accepts requests that change state, and the server is capable of sending that type of request, the impact may extend beyond reading information to some kind of action on that service.

Acting as a Relay for Communication to Third Parties

The server may also be used to communicate with a third party in a way that was not intended.

In this case, the communication is sent not from the user’s own device, but from a server operated by the service provider. To the destination, it may therefore appear to originate from that server or organization.

The privileges and trust relationships discussed in §3 can amplify these impacts. If the destination trusts the server’s network location or credentials, the same communication may have a greater effect than if it had been sent directly by the user.

It is important not to reduce SSRF to “a vulnerability that only allows someone to read an internal page.”

6. Problems Can Occur Even When the Retrieved Content Is Not Visible

You might think, “If the server retrieves something but never shows the content to the user, isn’t that safe?”

Not necessarily.

Communication is not performed only to read content. Using the building analogy, even if the person inside never reports back, the action still occurred if they went to the room, opened a door, and delivered something.

Similarly, with SSRF, if a request reaches the destination, some processing may occur there. Even when the response content itself is not displayed, differences such as whether the request succeeded or how long the response took may sometimes allow someone to infer whether a service exists somewhere the user cannot see directly, or whether that location is reachable.

If the user can specify a destination they control, they may also be able to confirm on their side that the communication reached that destination.

A type of SSRF in which the response content is not directly visible is sometimes called blind SSRF.

The important point in this chapter is not the term itself, but this:

Not returning the response to the user does not prove that the system is safe.

7. Server-Side Communication May Occur Even Without a URL Input Field

SSRF is sometimes imagined as a vulnerability in which someone enters a problematic URL into a URL input field.

But even when there is no screen on which the user directly enters a URL, information supplied by the user may still affect server-side communication.

For example, suppose a service allows a user to upload a document and then converts that document into a PDF on the server.

Some document formats may contain a reference saying, in effect, “display the image located here,” rather than embedding the image data itself.

If the server-side conversion process reads that reference and retrieves the image or another resource, the user may not have directly said, “Connect to this URL,” but the content supplied by the user has nevertheless resulted in server-side communication.

In this chapter, we refer to this kind of additional retrieval—one that occurs while the application is processing the user’s initial request—as secondary server-side communication.

User
  ↓
Document or content
  ↓
Server-side conversion or processing
  ↓
Additional retrieval of a referenced resource

When looking for SSRF entry points, it is therefore not enough to ask whether there is a URL input field. You also need to consider whether information influenced by the user can lead to server-side communication somewhere during processing.

8. The URL You See and the Communication That Actually Occurs May Not Match

At this point, you might ask, “Then isn’t it enough to check the URL entered by the user and allow it only if it looks safe?”

Checking the input is important.

What makes SSRF difficult, however, is that the string examined at the beginning does not necessarily explain the communication that ultimately occurs.

In simplified form, server-side communication follows a flow like this:

Entered URL or destination
        ↓
Software interprets the input
        ↓
The actual communication destination is determined
        ↓
The server connects to that destination

In real systems, name resolution, proxies, redirects, networking libraries, and other components may be involved. Name resolution is the mechanism that looks up, from a host name, the address actually used for the connection.

The key point for Chapter 1 is that checking the input string and confirming that the actual communication remains within the intended scope are not the same check.

Chapter 2 examines the kinds of gaps that can arise between what was decided and the communication that actually occurs.

9. Chapter 1 Summary

When thinking about SSRF, it is important not to reduce the problem to “finding a dangerous URL.”

Keep these three points in mind:

1. In a feature that performs server-side communication, the user may influence the destination, but it is the server side that actually makes the connection.
2. The server may have different reachability, privileges, or trust relationships from the user.
3. When information influenced by the user causes communication to be directed to a target outside the scope that should be permitted for the function, an SSRF problem arises.

It is also important to remember that problems may occur even when the response is not displayed to the user, that secondary server-side communication can occur even without a URL input field, and that the destination inferred from an entered URL does not always match the destination that is actually contacted.

10. Moving on to Chapter 2

So, can SSRF be prevented simply by checking the destination carefully?

That is the right direction, but saying that the destination was “checked” is not enough.

At what stage was it checked?

Does that decision remain valid until the moment the communication actually occurs?

Does the communication really follow the path that was assumed?

At points like these, the initial decision and the actual communication can diverge.

Chapter 2 examines why SSRF defenses are difficult from the perspective of this gap between what was decided and the communication that actually occurs.