🧠 ज्ञान उद्यान

Server Side Request Forgery

7 min read

What is SSRF?

Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker’s choosing.

In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization’s infrastructure. In other cases, they may be able to force the server to connect to arbitrary external systems, potentially leaking sensitive data such as authorization credentials.

In simple words, Server-Side Request Forgery (SSRF) refers to an attack, wherein an attacker can send a crafted request from a vulnerable web application. SSRF is mainly used to target internal systems behind WAF (web application firewall), that are unreachable to an attacker from the external network. Additionally, it’s also possible for an attacker to mark SSRF, for accessing services from the same server that is listening on the loopback interface address known as (127.0.0.1).

Burp Collaborator and Alternatives!

Burp Collaborator is a network service that Burp Suite uses to help discover many kinds of vulnerabilities. In simple words it basically creates a server for you which you can use to redirect requests. Services provided by Burp Collaborator are as follows:

  • It uses its own dedicated domain name, and the server is registered as the authoritative DNS server for this domain.
  • It provides a DNS service that answers any lookup on its registered domain (or subdomains) with its own IP address.
  • It provides an HTTP/HTTPS service, and uses a valid, CA-signed, wildcard TLS certificate for its domain name.
  • It provides an SMTP/SMTPS service.

Note: Burp Collaborator comes with the Pro Version of Burp Suite!

Steps to set up Burp Collaborator

  1. Click on Burp
  2. Click on Burp Collaborator Client
  3. The various options over here are:
    • In Number to generate enter the number of servers you want to create.
    • You can copy the address of your server using the Copy to Clipboard button
    • Poll every will basically check for the requests on the specified time
    • Poll Now will check for request whenever that button is hit

Alternatives to Burp Collaborator

Following are some of the alternatives you can use for Burp Collaborator:

  1. Webhook.site (https://webhook.site/) Webhook.site is an external alternative one can use. It allows you to create your own server as well as provides you with your unique email address and a mail client for it. It allows you up to 500 requests which is more than enough. Although you don’t need an account to create you own server but having an account will let you save your work.

  2. Request Bin (https://requestbin.com/) Request Bin allows you to create a trigger from variety of sources. The only disadvantage over here is that you compulsory need an account in order to generate a server address.

  3. Request Catcher (https://requestcatcher.com/) Another beautiful tool is Request Catcher. It allows you to create your own custom subdomain. The best part is you do not require any Sign Up!

Exploiting SSRF vulnerability

SSRF attacks often exploit trust relationships to escalate an attack from the vulnerable application and perform unauthorized actions. These trust relationships might exist in relation to the server itself, or in relation to other back-end systems within the same organization.

The steps to exploit this vulnerability are:

  • Exploit a web application to induce requests to attackers controlled server
  • Configure Burp Collaborator as third party server
  • Wait for interaction
  • Attack Successful (kinda)

The actual working scenario can be something like this:

  • Intercept the Request
  • Send the request to Repeater
  • Right Click → Engagement Tools → Discover Content
  • Discover and identify URLS
  • Choose the URL with the parameter you want
  • Set Up Burp Collaborator
  • Copy the payload and replace it with the value of the parameter you have taken
  • Hit Send
  • In the Burp Collaborator you will be able to see the logs.

SSRF Attacks against the server itself

Many times administrative functionality is available only to the authenticated users. When any attacker makes a request through a local machine, he gets access to administrative functionality. A request to local machine can be made using payloads such as localhost , 127.0.0.1 etc.

SSRF Attacks with black list based input filters

Developers often blacklist filters to block certain characters as input. Many times applications block hostnames like localhost and 127.0.0.1. Certain sensitive URLS like /admin are also blocked. A good alternative can be different types of SSRF Payloads. A list of SSRF Payloads can be found here.

In certain cases converting the IP address also works. This can be done using https://www.vultr.com/resources/ipv4-converter/

SSRF Attacks with white list based input filters

Some applications only allow input that matches, begins with, or contains, a whitelist of permitted values. In this situation, you can sometimes circumvent the filter by exploiting inconsistencies in URL parsing. In such a case

  • You can embed credentials in a URL before the hostname, using the @ character. For example: https://expected-host@evil-host.

  • You can use the # character to indicate a URL fragment. For example: https://evil-host#expected-host.

  • You can leverage the DNS naming hierarchy to place required input into a fully-qualified DNS name that you control. For example: https://expected-host.evil-host.

Severity

The severity of SSRF varies and depends on case to case basis.

Impact of SSRF

A successful SSRF attack can often result in unauthorized actions or access to data within the organization, either in the vulnerable application itself or on other back-end systems that the application can communicate with. In some situations, the SSRF vulnerability might allow an attacker to perform arbitrary command execution.

An SSRF exploit that causes connections to external third-party systems might result in malicious onward attacks that appear to originate from the organization hosting the vulnerable application.

In simple words, By this attack, an attacker can gather information about ports, IP addresses, Remote Code Execution (RCE), and can also discover the IP addresses of servers running behind a reverse proxy, etc.

Prevention of SSRF

  1. Whitelist Domains in DNS : The easiest way to remediate SSRF is to whitelist any domain or address that your application accesses. Blacklisting and regex have the same issue, someone will eventually find a way to exploit them.
  2. Do Not Send Raw Responses : Never send a raw response body from the server to the client. Responses that the client receives need to be expected.
  3. Enforce URL Schemas : Allow only URL schemas that your application uses. There is no need to have ftp://, file:/// or even http:// enabled if you only use https://. And if you do use other schemas make sure that they’re only accessible from the part that needs to access them and not from anywhere else.
  4. Enable Authentication on All Services : Make sure that authentication is enabled on any service that is running inside your network even if they don’t require it. Services like memcached, redis, mongo and others don’t require authentication for normal operations, but this means they can be exploited.
  5. Sanitize and Validate Inputs : Never trust user input. Always sanitize any input that the user sends to your application. Remove bad characters, standardize input (double quotes instead of single quotes for example). After sanitization make sure to validate sanitized input to make sure nothing bad passed through.

References

Graph View

Backlinks