Server-Side Request Forgery Tests

Explore Pynt's documentation on security tests for server-side request forgery! Learn how Pynt protects your APIs against this critical vulnerability.

At a Glance: 🌐 SSRF (Server-Side Request Forgery) occurs when an attacker tricks a server into making requests to unintended locations, such as internal systems or external third-party services. This vulnerability allows attackers to bypass firewall restrictions, access sensitive data, or execute malicious actions on behalf of the compromised server.

---

Introduction

SSRF occurs when an attacker can manipulate the input parameters of a web application that requests resources from other servers, such as databases, web services, or other APIs.

The attacker can exploit this vulnerability to send forged requests to internal servers that are not meant to be exposed to the internet, such as backend systems or databases. This can result in unauthorized access, data theft, or other malicious activities that can compromise the security of the entire web application or the network it is hosted on.

What are the common mistakes made by developers?

SSRF vulnerabilities occur due to a lack of input validation and inadequate access controls. Specifically, when applications allow untrusted input to be used in making requests to other servers, they can be exploited by attackers to manipulate these requests and send them to unintended targets

import requests
from flask import Flask, request

app = Flask(__name__)

@app.route('/')
def index():
    url = request.args.get('url')
    response = requests.get(url)
    return response.text

if __name__ == '__main__':
    app.run(debug=True)

In this example, the Flask web application takes a URL parameter from the user and makes a GET request to that URL using the requests library. However, there is no input validation or sanitization being performed on the URL parameter, which means an attacker can pass in a malicious URL that points to an internal server or other restricted resource.

For example, an attacker could make a request like this:

http://localhost:5000/?url=http://192.168.0.1/secret

This would cause the web application to make a request to an internal server at IP address 192.168.0.1, which may contain sensitive data or be otherwise restricted. By exploiting this SSRF vulnerability, the attacker could potentially gain access to this internal resource and compromise the security of the network.

How can I fix SSRF issues?

Validate and sanitize user input before using it to make requests to external resources. One approach would be to use a whitelist of allowed URLs, or to restrict the URLs that can be accessed based on the user's permissions or role.

Test cases in this category

This test case tries to manipulate a URL to access a local file on the server

Test case	OWASP	CWE
[SSRF001] Local file access	A10 OWASP top 10	CWE-918