Location Research Breakthrough Possible @S-Logix pro@slogix.in

Office Address

Social List

Orchestrating Server-Side Request Forgery (SSRF) Attacks Against FastAPI URL-Fetching Services Through Outbound Request Validation and Internal Network Access Restriction

Description

Modern web applications and APIs frequently provide URL-fetching functionality for legitimate operations such as retrieving remote resources, processing external content, generating previews, or integrating with third-party services.

However, insecure server-side URL fetching can introduce Server-Side Request Forgery (SSRF) vulnerabilities. If a backend service accepts a user-supplied URL and directly performs the request without validating the destination, an attacker may manipulate the URL so that the server sends requests to unintended internal or restricted destinations.

In this use case, a FastAPI URL-fetching service is deployed as the controlled application and API environment on an Ubuntu virtual machine. The service provides an API endpoint that accepts a URL from the client and performs a server-side HTTP request to retrieve the requested resource.

A controlled SSRF security assessment is performed from Kali Linux. OWASP ZAP is used to intercept and analyze API requests and responses, while command-line HTTP testing tools are used to submit controlled URL values and validate server-side request behavior.

The security assessment focuses on determining whether the FastAPI service validates the destination of outbound requests before contacting external or internal resources.

The proposed defensive mechanism implements server-side outbound request validation and internal network access restriction. The application validates the supplied URL, resolves and evaluates the destination, restricts requests to approved destinations, and prevents access to protected internal network ranges.

After implementing the security controls, the SSRF assessment is repeated to verify that malicious or restricted destinations are rejected while legitimate external URL requests continue to function.

Existing Security Problem

Application: FastAPI URL-Fetching Service

FastAPI URL-Fetching Service is used as the controlled application and API environment for testing server-side outbound-request security weaknesses. The application provides an API endpoint that accepts a URL supplied by the client and performs a server-side request to retrieve content from the specified destination. The URL-fetching functionality therefore creates a security boundary between the client-controlled URL and the server's outbound network access.

Existing Problem:

SSRF becomes possible when the backend accepts a client-controlled URL and uses it for server-side network communication without sufficiently validating the destination.

The security problem is therefore:

FastAPI URL-Fetching API → Client-Controlled URL → Insufficient Outbound URL Validation → Server Resolves Attacker-Controlled Destination → Server-Side Request Generated → Internal / Restricted Network Destination Reached → SSRF Security Exposure

The proposed solution introduces server-side outbound request validation and internal network access restriction so that the FastAPI service can distinguish permitted destinations from restricted network destinations before establishing the outbound connection.

Attack

Specific Attack: Server-Side Request Forgery (SSRF)

A Server-Side Request Forgery attack attempts to make a server perform a network request to a destination selected or influenced by the attacker.

In this controlled assessment, the attacker identifies a URL-fetching API endpoint that accepts a URL parameter or request-body value. Controlled URLs representing legitimate external resources and restricted destinations are submitted to determine whether the FastAPI service performs server-side requests without sufficiently restricting the destination.

Attack Behavior:
URL-Fetching API Identified
→
Legitimate URL Request Established
→
Server-Side Request Behavior Analyzed
→
Controlled Destination URL Submitted
→
FastAPI Processes Client-Supplied URL
→
Server Resolves Destination
→
Server Performs Outbound HTTP Request
→
Restricted / Internal Destination Reached
→
SSRF Condition Confirmed
→
Internal Network Access Exposure

Security Concept

Server-Side Outbound Request Validation:

The primary security concept is to validate the requested destination before the backend establishes an outbound network connection.

The application must not trust a client-supplied URL simply because it is syntactically valid or appears to reference an external hostname. It validates the URL structure and scheme, resolves the hostname, evaluates the destination IP address, and applies network access policies before allowing an outbound request.

The secure processing flow is:

URL Received
→
URL Structure Validation
→
Hostname Resolution
→
Destination IP Validation
→
Network Policy Validation
→
Outbound Request Decision

Defensive Mechanism

URL Scheme Enforcement

The API accepts only explicitly permitted URL schemes for the URL-fetching functionality.

Purpose

Prevent unsupported schemes from being processed by the server-side request mechanism.

Hostname Validation

The API validates the hostname supplied by the client before initiating the outbound request.

Purpose

Prevent unrestricted client-controlled destination selection.

DNS Resolution and IP Validation

The application resolves the requested hostname and evaluates the resulting IP address before establishing the connection.

Purpose

Prevent hostnames from resolving to restricted destinations.

Private IP Range Blocking

The application rejects destinations belonging to configured private and internal IP ranges.

Purpose

Prevent server-side requests to protected internal networks.

Loopback Address Blocking

The application blocks requests targeting loopback destinations.

Purpose

Prevent access to services running on the FastAPI server itself.

Link-Local Address Blocking

The application blocks requests targeting link-local destinations.

Purpose

Prevent access to services exposed through link-local network addressing.

Outbound Allowlist Enforcement

Where applicable, the application restricts outbound requests to explicitly approved domains or destinations.

Purpose

Reduce the number of destinations that the server is permitted to contact.

Redirect Validation

The application validates destinations reached through HTTP redirects rather than automatically trusting the redirected location.

Purpose

Prevent a permitted initial URL from redirecting the server toward a restricted destination.

Outbound Request Failure Handling

The API rejects requests when destination validation fails instead of proceeding with the network connection.

Purpose

Prevent restricted outbound requests from reaching protected network resources.

Security Event Logging

Rejected SSRF-related requests and destination-validation failures are recorded by the application.

Purpose

Support security investigation and detection of repeated SSRF attempts.

Security Tools

Primary API Security Testing Tool: OWASP ZAP

OWASP ZAP is used from Kali Linux to intercept and analyze requests sent to the FastAPI URL-fetching endpoint.

Purpose
  • Capture URL-fetching API requests.
  • Identify URL parameters and request-body values.
  • Modify controlled URL values.
  • Replay SSRF test requests.
  • Analyze API responses.
  • Compare application behavior before and after remediation.

HTTP Request Testing Tool: cURL

cURL is used to submit controlled HTTP requests directly to the FastAPI API.

Purpose
  • Send legitimate URL-fetching requests.
  • Submit controlled SSRF test values.
  • Test different URL destinations.
  • Compare HTTP response behavior.
  • Validate post-remediation request rejection.

API Testing Environment: FastAPI

FastAPI provides the controlled URL-fetching API environment.

Purpose
  • Provide the controlled URL-fetching functionality.
  • Accept client-supplied URL values.
  • Perform server-side HTTP requests.
  • Implement outbound URL validation.
  • Validate SSRF remediation.

Server Environment: Ubuntu

Ubuntu hosts the FastAPI application and supporting services.

Purpose
  • Run the FastAPI service.
  • Host the URL-fetching application.
  • Implement outbound-request security controls.
  • Maintain application security logs.
  • Provide the controlled server-side network environment.

Security Testing Environment: Kali Linux

Kali Linux is used as the controlled security-testing environment.

Purpose
  • Run OWASP ZAP.
  • Run cURL.
  • Perform SSRF security testing.
  • Analyze API responses.
  • Validate post-remediation behavior.

Virtualization Platform: VirtualBox

VirtualBox provides the isolated laboratory environment for the Ubuntu and Kali Linux virtual machines.

Purpose
  • Create isolated virtual machines.
  • Provide controlled network connectivity.
  • Separate the application and security-testing environments.
  • Maintain a reproducible SSRF testing laboratory.

Process

STEP 01

Step 1: Prepare the Virtualized API Security Environment

  • Create an isolated cybersecurity laboratory using VirtualBox.
  • Configure Ubuntu as the FastAPI application and server environment.
  • Configure Kali Linux as the security-testing environment.
  • Configure the virtual network to allow controlled communication between the two virtual machines.
  • Verify connectivity between Kali Linux and Ubuntu.
  • Confirm that Kali Linux can reach the FastAPI service.
  • Ensure that the testing environment does not target external systems.
Tools: VirtualBox + Ubuntu + Kali Linux
STEP 02

Step 2: Prepare the FastAPI Application Environment

  • Install the required Python runtime and application dependencies on Ubuntu.
  • Create the controlled FastAPI application environment.
  • Configure the application to listen on the required interface and port.
  • Start the FastAPI service.
  • Verify that the API is reachable from Ubuntu.
  • Confirm that Kali Linux can access the API endpoint.
  • Verify normal API functionality before security testing.
Tools: Ubuntu + Python + FastAPI
STEP 03

Step 3: Deploy the Controlled URL-Fetching Endpoint

  • Configure the FastAPI application with a controlled URL-fetching endpoint.
  • Define the API request parameter used to supply the destination URL.
  • Configure the backend to perform a server-side HTTP request.
  • Return an appropriate response to the API client.
  • Verify that a legitimate test URL can be processed.
  • Establish the normal URL-fetching behavior.
Tools: FastAPI + Ubuntu
STEP 04

Step 4: Establish Normal URL-Fetching Behavior

  • Submit a legitimate external test URL to the FastAPI endpoint.
  • Verify that the server receives the URL.
  • Confirm that the FastAPI application performs the server-side request.
  • Observe the API response.
  • Record the expected response behavior.
  • Establish the baseline for legitimate outbound URL requests.
Tools: Kali Linux + cURL + FastAPI
STEP 05

Step 5: Capture and Analyze API Traffic

  • Configure OWASP ZAP as the interception proxy.
  • Route the FastAPI testing traffic through OWASP ZAP.
  • Capture the URL-fetching API request.
  • Identify the URL parameter or request-body value.
  • Inspect the server response.
  • Record the normal request and response structure.
Tools: Kali Linux + OWASP ZAP + FastAPI
STEP 06

Step 6: Identify the SSRF Attack Surface

  • Identify all URL-fetching parameters exposed by the FastAPI application.
  • Determine which API functionality causes the server to make outbound requests.
  • Identify whether the destination is completely controlled by the submitted URL.
  • Determine whether redirects are followed by the application.
  • Identify the server-side request library used by the application.
  • Document the URL-fetching attack surface.
Tools: OWASP ZAP + FastAPI + Ubuntu
STEP 07

Step 7: Perform Controlled External URL Testing

  • Submit controlled external test URLs through the API.
  • Verify that the FastAPI server performs the request.
  • Observe the resulting API response.
  • Compare the response with the expected legitimate behavior.
  • Confirm that the server is responsible for making the outbound request.
  • Record the normal external destination behavior before SSRF testing.
Tools: Kali Linux + cURL + OWASP ZAP
STEP 08

Step 8: Perform Controlled SSRF Destination Testing

  • Submit a controlled URL representing a restricted server-side destination.
  • Replay the request against the laboratory FastAPI endpoint.
  • Observe whether the server attempts to connect to the supplied destination.
  • Record the API response.
  • Repeat the assessment with other controlled restricted destinations.
  • Ensure all testing remains inside the authorized laboratory environment.
Tools: Kali Linux + cURL + OWASP ZAP + FastAPI
STEP 09

Step 9: Test Loopback and Internal Network Restrictions

  • Submit controlled loopback destinations to the URL-fetching endpoint.
  • Observe whether the FastAPI service attempts to access the local server.
  • Submit controlled private-network destinations within the laboratory.
  • Observe whether the server attempts to access the destination.
  • Record the response for each destination category.
  • Determine whether internal destinations are reachable through the URL-fetching functionality.
Tools: Kali Linux + cURL + FastAPI
STEP 10

Step 10: Test DNS-Based Destination Validation

  • Submit a controlled hostname through the URL-fetching API.
  • Observe how the application resolves the hostname.
  • Determine the resulting destination address within the controlled environment.
  • Evaluate whether the application validates the resolved address before connecting.
  • Test a controlled hostname that resolves to an internal laboratory destination.
  • Record whether the request is accepted or rejected.
Tools: Kali Linux + cURL + DNS Utilities + FastAPI
STEP 11

Step 11: Confirm the SSRF Security Weakness

  • Repeat the controlled SSRF assessment.
  • Compare legitimate external URL behavior with restricted destination behavior.
  • Determine whether the server performs requests to destinations that should be inaccessible.
  • Identify the affected API endpoint.
  • Document the destination categories that can be reached.
  • Record the security impact of unrestricted server-side requests.
  • Confirm the SSRF condition before remediation.
Tools: OWASP ZAP + cURL + FastAPI
STEP 12

Step 12: Implement Server-Side URL Validation

  • Identify the backend component responsible for processing the submitted URL.
  • Implement validation before the outbound network request is created.
  • Validate the URL structure.
  • Validate the permitted URL scheme.
  • Extract and validate the hostname.
  • Reject malformed or unsupported URL values.
  • Ensure validation occurs before the outbound request.
Tools: Ubuntu + FastAPI
STEP 13

Step 13: Implement Destination IP Validation and Network Restrictions

  • Resolve the requested hostname before establishing the outbound connection.
  • Inspect the resulting destination address.
  • Block loopback addresses.
  • Block private network addresses.
  • Block link-local addresses.
  • Apply the configured outbound network policy.
  • Reject restricted destinations before the HTTP request is established.
Tools: Ubuntu + FastAPI + Python Networking Libraries
STEP 14

Step 14: Implement Redirect and Outbound Request Controls

  • Configure the URL-fetching logic to validate destinations reached through redirects.
  • Prevent a permitted initial destination from automatically providing unrestricted access to another destination.
  • Revalidate redirected destinations before following them.
  • Restrict outbound connections according to the configured security policy.
  • Configure appropriate request timeouts.
  • Reject outbound requests when destination validation fails.
Tools: Ubuntu + FastAPI + Python HTTP Client
STEP 15

Step 15: Implement SSRF Failure Handling and Security Logging

  • Configure the API to reject restricted destination requests.
  • Return an appropriate API response when validation fails.
  • Avoid exposing unnecessary internal network information through the response.
  • Record SSRF-related validation failures in application security logs.
  • Record the request timestamp and affected endpoint.
  • Record the validation category responsible for rejection.
  • Avoid unnecessarily storing sensitive request information in logs.
Tools: Ubuntu + FastAPI
STEP 16

Step 16: Re-Test SSRF After Remediation

  • Submit the same controlled SSRF requests used during the initial assessment.
  • Replay the requests through OWASP ZAP.
  • Test loopback destinations.
  • Test private-network destinations.
  • Test link-local destinations.
  • Test controlled DNS-based restricted destinations.
  • Verify that restricted requests are rejected before the outbound connection occurs.
  • Compare the post-remediation results with the original assessment.
Tools: Kali Linux + OWASP ZAP + cURL + FastAPI
STEP 17

Step 17: Validate Legitimate External URL Access

  • Submit legitimate external test URLs.
  • Verify that valid destinations continue to function.
  • Confirm that the server performs permitted outbound requests.
  • Verify that legitimate API responses remain available.
  • Ensure that the new SSRF controls do not unnecessarily block approved destinations.
  • Compare legitimate behavior before and after remediation.
Tools: Kali Linux + cURL + FastAPI
STEP 18

Step 18: Perform Final SSRF Security Validation

  • Perform a final SSRF security assessment using OWASP ZAP.
  • Repeat manual URL manipulation testing.
  • Re-test loopback destination blocking.
  • Re-test private-network destination blocking.
  • Re-test link-local destination blocking.
  • Re-test hostname resolution validation.
  • Re-test redirect destination validation.
  • Verify that legitimate URLs continue to function.
  • Review application security logs for rejected SSRF attempts.
  • Document the vulnerability, remediation, and final validation results.
Tools: OWASP ZAP + cURL + FastAPI + Ubuntu
STEP 19

Step 19: Document the Final Security Assessment

  • Document the original SSRF attack behavior.
  • Record the affected FastAPI endpoint and URL-fetching functionality.
  • Document the destination-validation weakness identified during testing.
  • Record the implemented outbound request controls.
  • Document the restricted network ranges and destination categories enforced by the application.
  • Record the post-remediation testing results.
  • Confirm that restricted destinations are rejected.
  • Confirm that legitimate URL-fetching functionality remains available.
  • Maintain the final security assessment as evidence of the completed validation.
Tools: OWASP ZAP + FastAPI + Ubuntu + Kali Linux

Outcome

  1. The Server-Side Request Forgery (SSRF) vulnerability is assessed against the controlled FastAPI URL-fetching service.
  2. The assessment demonstrates the security risk created when client-controlled URLs are used for server-side outbound requests without sufficient destination validation.
  3. The FastAPI URL-fetching endpoint and server-side request behavior are identified and analyzed.
  4. Controlled SSRF destination testing is performed against loopback, private-network, link-local, and DNS-resolved destinations within the laboratory environment.
  5. Server-side outbound URL validation is implemented to prevent restricted destinations from being accessed through the URL-fetching functionality.
  6. Destination IP validation prevents requests from being established toward configured internal and restricted network ranges.
  7. Loopback and link-local destination restrictions prevent access to protected server-side network interfaces.
  8. Redirect and hostname-resolution validation strengthen the outbound request security boundary.
  9. Invalid and restricted URL requests are rejected while legitimate permitted URL requests continue to function.
  10. Application security logging records relevant SSRF validation failures, supporting investigation and security monitoring.
  11. OWASP ZAP, cURL, FastAPI, Ubuntu, and Kali Linux are used to demonstrate the complete SSRF attack assessment, defensive implementation, and post-remediation security-validation workflow.
← Previous Project
Project 6 of 7
Next Project →