Daemon Of Hacking
  • WELCOME!
    • 👋/home/usr/KruKnight
  • METHODOLOGIES & RESOURCES
    • Passwords & Attacks
    • Post Exploitation
      • 👀Situational Awareness
      • 🖥️Privilege Escalation
        • Linux Privilege Escalation
        • Windows Privilege Escalation
  • Writeups
    • CyCtf 2024
      • Vending Machine
      • Aerospace
      • OhMyCell
    • Portswigger Labs
      • Authentication
        • Username enumeration via different responses
        • 2FA simple bypass
        • Password reset broken logic
        • Username enumeration via subtly different responses
        • Username enumeration via response timing
        • Broken Brute-Force Protection, IP Block
        • Username enumeration via account lock
        • 2FA broken logic
        • Brute-forcing a stay-logged-in cookie
        • Offline password cracking
        • Password reset poisoning via middleware
        • Password brute-force via password change
        • Broken brute-force protection, multiple credentials per request
      • Os Command Injection
        • OS command injection, simple case
        • Blind OS command injection with time delays
        • Blind OS command injection with output redirection
        • Blind OS command injection with out-of-band interaction
        • Blind OS command injection with out-of-band data exfiltration
      • Cross-Origin Resource Sharing (CORS)
        • CORS vulnerability with basic origin reflection
        • CORS vulnerability with trusted null origin
        • CORS vulnerability with trusted insecure protocols
      • Server-side template injection
        • Basic server-side template injection
        • Basic server-side template injection (code context)
      • Server-Side Request Forgery (SSRF)
        • Basic SSRF against the local server
        • Basic SSRF against another back-end
        • Blind SSRF with out-of-band detection
        • SSRF with blacklist-based input filter
        • SSRF with filter bypass via open redirection vulnerability
      • Path Traversal
  • 🟩HTB Writeups
    • Heal
Powered by GitBook
On this page
  • Lab Description
  • Step 1: Observing the Application
  • Step 2: Analyzing the Request
  • Step 3: Testing for SSRF
  • Step 4: Exploiting the Admin Functionality
  • Lessons Learned

Was this helpful?

  1. Writeups
  2. Portswigger Labs
  3. Server-Side Request Forgery (SSRF)

Basic SSRF against the local server

PreviousServer-Side Request Forgery (SSRF)NextBasic SSRF against another back-end

Last updated 20 days ago

Was this helpful?

Lab Description

Step 1: Observing the Application

Upon accessing the lab, we're presented with a simple store page listing several products.

When we select any item, we notice a "Check Stock" button.

Naturally, our first move is to intercept the request using Burp Suite.

Step 2: Analyzing the Request

Intercepting the request reveals something interesting:

We see that the application fetches stock information from a backend service using a full URL provided by the stockApi parameter. This immediately hints at a possible SSRF, since the server is fetching the data on our behalf using a URL we can control.

Step 3: Testing for SSRF

To test this, we tamper with the stockApi parameter and set it to a different internal address:

stockApi=http://localhost/admin

After sending the modified request, we receive a valid response containing the admin panel interface. This confirms that we’ve successfully triggered an SSRF, allowing us to access internal services not normally available to external users.

Step 4: Exploiting the Admin Functionality

Following the lab’s objective, we aim to delete the carlos user. Based on the structure of the admin interface, we try the following payload:

stockApi=http://localhost/admin/delete?username=carlos

Upon submitting the request, we observe a 302 Found status code in the response—indicating that the request was processed and redirected. This behavior confirms the action succeeded.

We revisit the lab page and are greeted with a "Congratulations" message, meaning the lab has been successfully completed.

Lessons Learned

This lab illustrates a basic but impactful SSRF scenario. Let’s break down the key takeaways:

  • Blind trust in user-controlled URLs (like stockApi) can lead to SSRF.

  • Internal services such as localhost should never be accessible through user input.

  • Proper input validation, URL whitelisting, and the use of metadata-based protections can help prevent SSRF.