Finding SSRF In Modern Web Apps

You think Modern Web Apps are like Labs out there. C'mon. That's not how Modern Web Apps work. The beginners that say that they know the whole concept of a specific vulnerability but when they try to find it in a real web app, everything looks different. This Article can give you a little push in that situation. Its not that Perfect, but it can help you a little if you are stuck.

Finding a Server-Side Request Forgery (SSRF) vulnerability in modern web applications requires a shift in mindset. Many beginners spend hours looking for simple input fields where they can type http://localhost, only to find that modern applications rarely work that way anymore. Today, applications are complex, deeply integrated with cloud services, and heavily reliant on external APIs.

To find SSRF in the real world, you need a systematic approach that moves from controlled learning environments to sophisticated, live testing.

Here is your complete, step-by-step blueprint to uncovering SSRF in modern web applications.

Phase 1: Establish Your Foundation in the Labs

I am not saying don't solve labs. Not at all.

Before you attempt to find SSRF in a live, production environment, you must understand how the vulnerability behaves in a controlled setting. Trying to hack a real-world application without practicing in a lab is like trying to drive a race car without ever taking a driving lesson.

1. Complete Free Lab Platforms

Start with structured environments that mimic real-world flaws.

• PortSwigger Web Security Academy: Navigate to their specific SSRF module. Complete every lab, starting from "Basic SSRF against the local server" and moving up to "SSRF with filter-by-string-based bypass."
• TryHackMe & Hack The Box: Search for rooms dedicated entirely to SSRF to practice mapping internal networks.

2. What to Focus on During Lab Practice

Do not just follow the walkthroughs blindly. Focus on these three elements:

• The Request/Response Cycle: Use a proxy tool like Burp Suite to observe exactly what happens when a server fetches a URL on your behalf.
• Error Messages: Pay close attention to how the application responds when a request fails. Does it leak internal IP addresses? Does it reveal the name of the backend software?
• Success Indicators: Learn what a successful internal connection looks like. Sometimes, the response time changes slightly, or the size of the returned content drops by a few bytes.

Once you can comfortably solve advanced lab challenges without looking at the hints, you are ready to transition to real-world applications.

Phase 2: Map the Attack Surface and Hunt for "Features"

In the real world, developers do not label inputs as ?url=. Like you see in the Labs. Instead, you have to look for specific application features that inherently require the server to talk to the outside world. When you onboard a target, ignore the standard login forms and look specifically for the following functionalities.

1. File Uploads via URL

Look for features where a user can upload a profile picture, a document, or an avatar by pasting a link instead of uploading a file from their local computer.

• The Logic: The web server must take that link, make a request to it, download the image, and save it. This is a primary target for SSRF.

2. Webhooks and Integrations

Modern business applications constantly talk to other tools (like Slack, Discord, or Jira). Look for settings panels labeled "Webhooks," "Integrations," or "API Sync."

• The Logic: These features are explicitly designed to let users tell the application server: "Hey, send a notification to this URL whenever a new event happens."

3. Document Generators and Exporters

Look for buttons that allow you to "Export to PDF," "Download Invoice," or "Print Receipt."

• The Logic: Backend servers often use HTML-to-PDF rendering engines (like headless Chrome or Wkhtmltopdf) to generate these documents. If you can inject HTML or a URL into the document field, the PDF generator might fetch it.

4. Import/Export Data Utilities

Look for features that import data from external platforms. Examples include importing a blog feed via RSS, importing contacts from a CSV hosted online, or syncing a calendar via an iCal URL.

Phase 3: Set Up Your External Interception Infrastructure

When testing for SSRF in the wild, you cannot simply look at the application's response to see if your attack worked. Modern architectures use Blind SSRF, meaning the server executes your request in the background but never shows you the result on the screen.

To catch these hidden requests, you must set up an external server that logs whenever something connects to it.

1. Choose Your Listener Tool

• Burp Collaborator: If you use Burp Suite Professional, this is the easiest option. It generates unique subdomains and records every DNS lookup or HTTP request made to them.
• Interactsh: A fantastic, free, open-source alternative by ProjectDiscovery. You can use their public servers or host your own.
• RequestBin or Webhook.site: Good for quick visual checks, though less optimized for automated scanning.
• Your Own VPS: A cheap Linux virtual private server (like a DigitalOcean droplet) where you can run tcpdump or Python's http.server to log traffic.

2. Verify Your Infrastructure

Before testing the target, open your browser and visit your unique listener URL. Ensure your tool registers the hit. If your listener is working, you are ready to start injecting payloads into the target app.

Phase 4: Systematically Inject Payloads

Now that you have identified the target features and set up your listener, it is time to test. Do not start by throwing complex bypass payloads at the application. Start simple and progress logically.

Step 1: The Outbound Ping Test

First, test if the application can talk to the public internet at all.

• Paste your unique listener URL (e.g., http://oast.fun) into the target feature (like the profile picture upload via URL).
• Trigger the feature.
• Check your listener logs.
• The Outcome: If you see an HTTP request or a DNS lookup from an IP address belonging to the application's cloud provider (AWS, Google Cloud, Azure), you have confirmed an Outbound SSRF.

Step 2: The Internal Network Probe

If the server talks to the internet, see if it will talk to its own internal neighborhood. Many modern apps block external connections but forget to block internal ones.

• Replace your listener URL with standard internal addresses:

http://127.0.0.1 (Localhost)

http://localhost

http://192.168.0.1 or http://10.0.0.1 (Internal network routers)

• What to look for: Look for changes in application behavior. Does a request to http://localhost:80 return a 200 OK or a faster response time than a request to http://localhost:8999? If yes, you can map open ports on the server.

Step 3: Cloud Metadata Endpoint Testing

Modern applications almost always run on cloud infrastructure. Cloud providers have special, unauthenticated internal API endpoints accessible only to machines running inside their network.

If you find an SSRF, try to query these specific IP addresses to see if the server returns highly sensitive cloud credentials:

Amazon Web Services (AWS) & Google Cloud Platform (GCP):

Target IP: http://169.254.169

AWS specific path: http://169.254.169

GCP specific path: http://169.254.169 (Requires a special header like Metadata-Flavor: Google, which you can try to inject if the app allows header modification).

Microsoft Azure:

Target IP: http://169.254.169

DigitalOcean:

Target IP: http://169.254.169

If the application returns JSON data or directory listings from any of these URLs, you have found a critical, high-impact SSRF.

Phase 5: Bypassing Modern Filters and Protections

Developers know about SSRF, so they often implement basic blocklists. If you type http://127.0.0.1 or http://169.254.169.254 and get an "Invalid URL" or "Access Denied" error, the application is using a filter.

Do not give up. Here is how to bypass those restrictions systematically.

1. Alternative IP Representations

Filters often look strictly for the literal string 127.0.0.1. You can represent the exact same IP address using different mathematical formats that code libraries still understand, but simple filters miss.

• Decimal Format: http://2130706433 (This translates to 127.0.0.1)
• Octal Format: http://0177.0000.0000.0001
• Hexadecimal Format: http://0x7f000001
• Shortened Localhost: http://127.1 or http://0.0.0

2. Utilize DNS Rebinding

If a developer writes a code block that checks your URL, resolves it to an IP, checks if that IP is public, and then fetches it, you can bypass it using DNS Rebinding.

• You register a domain name and configure its nameserver to respond with a very short Time-To-Live (TTL) of 0 or 1 second.
• When the server checks the domain the first time to validate it, your nameserver returns a safe, public IP (e.g., 8.8.8.8). The application says, "Great, this URL is safe."
• A fraction of a second later, when the application actually makes the HTTP request to fetch the content, the TTL has expired. The server asks your nameserver for the IP again. This time, your nameserver responds with 127.0.0.1 or 169.254.169.254.
• The Result: The application fetches the internal resource, thinking it is still looking at the public website.

3. Exploit URL Parsing Inconsistencies

Different programming languages and libraries parse URLs differently. If an application uses one library to validate your URL and a completely different library to actually download it, you can confuse them by using symbols like @, #, or [:].

• The Credentials Trick: http://expected-domain.com@127.0.0.1

The validator might think: This URL goes to expected-domain.com.

The downloader might think: The username is expected-domain.com, and the actual destination server is 127.0.0.1.

• The Path Confusion: http://127.0.0.1#expected-domain.com

Summary of Your Daily Bug Hunting Workflow

To find SSRF consistently, turn this knowledge into a repeatable checklist whenever you audit a modern web application:

[Look for Features] ──> [Set Up Listener] ──> [Send Outbound Ping]
       │                                             │
       ▼                                             ▼
(PDFs, Webhooks, Uploads)                    (Check for Hit)
                                                     │
                                                     ▼
                                            [Try Internal IPs]
                                                     │
                                                     ▼
                                            [Apply Bypasses]
                                         (Decimal, Rebinding, etc.)

[Look for Features] ──> [Set Up Listener] ──> [Send Outbound Ping]
       │                                             │
       ▼                                             ▼
(PDFs, Webhooks, Uploads)                    (Check for Hit)
                                                     │
                                                     ▼
                                            [Try Internal IPs]
                                                     │
                                                     ▼
                                            [Apply Bypasses]
                                         (Decimal, Rebinding, etc.)

By following this progressive workflow — starting with deep lab familiarity, hunting features rather than raw parameters, using proper out-of-band infrastructure, and testing filters intelligently — you will systematically uncover SSRF vulnerabilities in even the most modern web applications.

If you have any questions, just DM me on LinkedIn, I'll try my best to help you. My LinkedIn: https://www.linkedin.com/in/haroon-shahid33/

Thanks for Reading.