Zaid Website Hacking Course Notes
07/09/2023 Broken Access Control
lab link - https://portswigger.net/web-security/access-control/lab-insecure-direct-object-references
IDOR - Insecure Direct Object Reference
Objects are accessed directly based on user input.
Objects can be defined as
Docs, images, database records etc.
07/09/2023 Modifying User Roles from User Profile, Broken Access Control
lab link - https://portswigger.net/web-security/access-control/lab-user-role-can-be-modified-in-user-profile
Burp Suite Repeater - the Burp Suite repeater allows you to modify a web request multiple times in different ways to try to manipulate data on the web server.
In this example I am modifying my "roleid" so that it is set to 2 not 1. I do this by modifying the payload of the request.
07/09/2023 Authentication bypass via information disclosure
The first step we need to take is to use the cli tool feroxbuster. This tool will show us all hidden pages of the website. Documentation site - https://epi052.github.io/feroxbuster-docs/docs/
This command will attempt to append the base url with a bunch of common hidden pages that developers use. The one we want to check out is the /Admin page. However when feroxbuster tried to access this page it returned a 401 error.
A 401 error is caused by the client request not being completed due to improper authentication with the requested resource. We must somehow gain access to this resource for this lab.
To achieve this we are going to use the TRACE method.
The trace method allows you to see if your request to the webserver was modified in any way before reaching the server. Intercepting the get request of this site does not show us much in burp suite, however using trace can provide more insight.
Sending the trace request returned a file with extra headers, these headers show that the webserver is using IP authorization to determine if the user trying to access the web server is an admin or not.
Knowing this we can now go to the find a replace section of burp suite, and add a rule to send an extra header to the web server so it looks like we are connecting from the localhost address.
Know when we reload the admin page, it let's us access the resource allowing us to delete the user Carlos and complete the lab !
07/09/2023 Path traversal and basic discovery
lab link - https://portswigger.net/web-security/file-path-traversal/lab-simple
These vulnerabilities allow you to access directories or paths that aren't supposed to be accusable from the normal user.
In this lab we are going to manipulate the get request that pulls the image from the web server for each product displayed on the web page.
To do this we will try to access the file /etc/passwd but we have to add some extra stuff before the directory of the file we want to access so that we can traverse to the etc directory on the web server.
As you can see in the above image we modify the get request to return the /etc/passwd file and it's contents which shows all passwords for the webserver and their associated users. Now we can just copy that get request to the interceptor to complete the lab !
07/17/2023 Bypassing Hard-coded extensions
Null byte - This is a byte that has a value of zero.
The web server will read this get request and pass it because it has the .jpg ending however, when it is executed and processed it will pull the passwd file. It is ignoring everything after the %.
07/17/2023 File path traversal, traversal sequences stripped non-recursively
Lab link - https://portswigger.net/web-security/file-path-traversal/lab-sequences-stripped-non-recursively
One way the developers of the web application can try to stop path traversal vulnerabilities is to remove any ../ in the request being sent to the web server. Doing this prevents you from going to repositories outside where the normal use case images are stored. However, if you double every ../ then when they are removed by the web application, it will still send one ../.
07/17/2023 File path traversal, validation of start of path
lab link - https://portswigger.net/web-security/file-path-traversal/lab-validate-start-of-path
Developers can also use hard coded paths to render files. In order to exploit this we need to go from where the image is being stored back to the root directory, and then to our target directory. We can do this by appending the given directory with three ../ and then our target directory like so.
07/18/2023 File path traversal, traversal sequences stripped with superfluous URL-decode
lab link - https://portswigger.net/web-security/file-path-traversal/lab-superfluous-url-decode
One way you can get around the web server looking for / in the get request is by url encoding the /. This turns every / in the file directory to %2f. However, what the web server could be doing is decoding these %2f and then checking the path which would still find the /s in the url. To get around this we can double encode our /s.
We want to right click --> select convert selection --> url --> url encode all characters. We want to encode it one more time by putting 25 before the 2f so the path would look like this ..%252f..%252f..%252f..%252fetc%252fpasswd.
07/18/2023 Bypassing extreme filtering
lab link - https://portswigger.net/web-security/file-path-traversal/lab-absolute-path-bypass
Using tools can help us automate the process which tries many different path traversal payloads to the webserver.
Here is a list of payloads you can pass into burp using the intruder tool.
After sending the request to the intruder tool, we want to highlight the vulnerable section of the get request which is the file name/path. Then we want to click add S. This tells burp what we want to replace with every entry in the payload list.
After starting the attack the intruder will send 180 payloads (all the payloads on the list). Here are the results, we can see all the payloads that returned a 200 status which means the get request resolved succesfully.
Discovering & Exploiting CSRF Vulnerabilities
CSRF - Client-side request forgery. The server does not properly check if the user generated the request. Requests can be forged and sent to users to make them take actions they don't intend to do such as change email, change password, or submit a payment.
The goal of the lab is to try to change another users email information while logged into your own account. This is done by forging a request to the web server.
To do this we will first copy the form source code and save it to an HTML file on our machine.
h
OAUTH 2.0 Basic Exploitation
lab link - https://portswigger.net/web-security/oauth/lab-oauth-authentication-bypass-via-oauth-implicit-flow
You need two accounts for this lab. In this example they provide you two accounts to use.
You first need to log in through the SSO portal.
Log in as wiener peter
Log out of your account.
Log in again, this time you will be automatically authenticated because of the session.
Next, go to the history tab on burp suite.
Look through the requests between the host. Pay attention to url, status code, method, and title. Click on the post request sent to the host.
Try editing this information to carlos's email and username.
Instead of sending this through the intercept or repeater we want to right click the request and request in browser with the current session. When we load the webpage we will now be logged in as Carlos!
Last updated
