Skip to content

Commit

Permalink
Fixed inconsistencies in solution manuals
Browse files Browse the repository at this point in the history
  • Loading branch information
SSKale1 committed Aug 14, 2022
1 parent 57f7385 commit 6138a9a
Show file tree
Hide file tree
Showing 7 changed files with 53 additions and 55 deletions.
9 changes: 4 additions & 5 deletions solutions/module-1/01-Reflected XSS.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ Perform an XSS injection attack on a given web application.

After you launch the web application, go to the search bar and try out some basic searches.

Now we will try out the XSS attacks. Cross-Site Scripting (XSS) attacks are a type of injection, where malicious scripts are injected into websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end-user.
Now we will try out XSS attacks. Cross-Site Scripting (XSS) attacks are a type of injection, where malicious scripts are injected into websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end-user.

XSS flaws can be difficult to identify in a web application. We can perform a security review of the HTTP code and search for all places where input from an HTTP request could make its way into the HTML output.

Expand All @@ -16,15 +16,14 @@ The standard command for testing the application for XSS vulnerability is:
<script>alert('1')</script>
```

We can paste this command into any comment field( search bar in our case). An alert box pops up on our screen which confirms that our application is vulnerable to XSS injection attacks
We can paste this command into any comment field (search bar in our case). An alert box popping up on our screen would have confirmed that our application is vulnerable to XSS injection attacks, but this doesn't work here.

XSS attacks may be conducted without using the script tags. Other tags and attributes will do the same thing. In the exercise, we have gone with the onerror attribute. You need to pass the following command in the search box:
XSS attacks may be conducted without using the script tags. Other tags and attributes can also help us test it. We can try using the image tag to check for reflected XSS. The below-mentioned payload is an image tag that tries to load an image with the source ``a`` as specified which does not exist and would throw an error. We then use the onerror field to execute our script payload, in this case, alert('xss')

```
<img src='a' onerror=alert('xss')>
```

An alert will pop up proving that the application is vulnerable to XSS injection attacks. The output will look like this:

An alert pops up proving that the application is vulnerable to XSS injection attacks.

![](https://user-images.githubusercontent.com/65826354/179527017-56acbc0d-4fc1-4d86-bee9-e96efaf6f48c.png)
14 changes: 7 additions & 7 deletions solutions/module-1/02-SQL Injection.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,14 +18,14 @@ If you inspect the page after the command and look out for the request payload,

![](https://user-images.githubusercontent.com/65826354/179527872-da68220a-0fd4-4fea-b66e-48bf2ffa2691.png)

Now comes the important step. Open BurpSuite on your desktop and navigate to Proxy in the setup. From there, click on 'Open browser' to use the Burp's embedded browser. The advantage of an embedded browser is that the proxy settings are configured automatically in it. Initially, keep the intercept as 'OFF'. You will need to turn it on later.
Now comes the important step. Open BurpSuite on your desktop and navigate to Proxy in the setup. From there, click on 'Open browser' to use Burp's embedded browser. The advantage of an embedded browser is that the proxy settings are configured automatically in it. Initially, keep the intercept as 'OFF'. You will need to turn it on later.

Now, copy the lambda request URL to Burpsuite's embedded browser. Again login to the application using the credentials given above and then go to the Users tab. Then, go to the BurpSuite and now turn the intercept 'ON'. We are doing this because now we want to intercept the next request that we send to the user. Then go back to the embedded browser and in the search user field, pass any random input, e.g h. We are doing this because we just need to intercept this request for further commands.
Go back to the BurpSuite and forward the request, you will get an output that you need to send to the repeater. Take a look at the image below to understand it well:
Now, copy the lambda request URL to Burpsuite's embedded browser. Again login to the application using the credentials given above and then go to the Users tab. Then, go to BurpSuite and now turn the intercept 'ON'. We are doing this because now we want to intercept the next request that we send to the user. Then go back to the embedded browser and in the search user field, pass any random input, e.g h. We are doing this because we just need to intercept this request for further commands.
Go back to BurpSuite and forward the request, you will get an output that you need to send to the repeater. Take a look at the image below to understand it well:

![](https://user-images.githubusercontent.com/65826354/179527876-51da7139-22d7-4720-bfc3-812b3870f2f4.png)

A burp repeater is a tool that is designed to allow the user or attacker to change or resend a particular HTTP request and analyze the response generated by it, and that is exactly what we need to do here. After intercepting the request, we will send the request to the repeater so that we can manually change parameters, and request methods, and see the response.
A burp repeater is a tool that is designed to allow the user or attacker to change or resend a particular HTTP request and analyze the response generated by it, and that is exactly what we need to do here. After intercepting the request, we will send the request to the repeater so that we can manually change parameters, and request methods, to see the response.

Now all that is left to do to complete our SQLi attack is to change the parameters manually to get the desired response. We need to alter the 'value' and 'authlevel' parameters and replace their values with the following:

Expand All @@ -34,7 +34,7 @@ Now all that is left to do to complete our SQLi attack is to change the paramete
"authlevel":"hello' or '1'='1"
```

After changing the parameters, just click on 'send' to send the request.
Check the response, you will see that we have successfully managed to gain access to all the data of all the users, even sensitive data like passwords, phone, addresses, etc. This completes our SQLi attack. You can look at the image below to see the final output containing all the sensitive data as well.
After changing the parameters, click on 'send' to send the request.
Check the response, you will see that we have successfully managed to gain access to most of the data for all the users, even sensitive data like phone, address, ids, etc. This completes our SQLi attack. You can look at the image below to see the final output containing all the sensitive data as well.

![](https://user-images.githubusercontent.com/65826354/179527888-979fca64-4701-4407-8e72-abb32aa81f13.png)
![](https://user-images.githubusercontent.com/65826354/179527888-979fca64-4701-4407-8e72-abb32aa81f13.png)
12 changes: 6 additions & 6 deletions solutions/module-1/03-Insecure Direct Object Reference.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,23 +4,23 @@ Perform an IDOR attack to change the passwords of users we don't have access to

# Solutions

In any application, whenever a user generates, sends, or receives a request from a server, there are some HTTP parameters such as 'id', 'uid', 'pid' etc that have some unique values which the user has been assigned. An attacker might be able to tamper with these values and this tampering may lead to Insecure Direct Object Reference (IDOR) vulnerability and that is exactly what we will be doing in this task.
In any application, whenever a user generates, sends, or receives a request from a server, there are some HTTP parameters such as 'id', 'uid', 'pid', etc that have some unique values which the user has been assigned. An attacker might be able to tamper with these values and this tampering may lead to an Insecure Direct Object Reference (IDOR) vulnerability.

Go to the normal browser and navigate to the profile of the user we have currently logged in as. There we will change the current password to a new one. Set the new password as:
Navigate to the profile of the user you have currently logged in as. There you can change the current password to a new one. Set the new password as:

Password - jameshill@123

After changing the password, inspect the page to view the request payload that was sent in the request. You will see something like this:

![](https://user-images.githubusercontent.com/65826354/179528125-125821b5-4bd7-470c-985f-e676d0ebfcbb.png)

Now go to the Burp's embedded browser. Again, go to the user profile there and change the password again, this time set the password as:
Now go to Burp's embedded browser. Again, go to the user profile there and change the password again, this time set the password as:

Password - jameshill

Make sure that before clicking on 'Change password', you have turned the intercept ON from the BurpSuite, as we need to intercept the request that we are sending. We will again change the parameters manually to get the desired response in the following steps. Forward the request in BurpSuite and then send the request to the repeater.
Make sure that before clicking on 'Change password', you have turned the intercept ON from BurpSuite, as we need to intercept the request we are sending. We will again change the parameters manually to get the desired response in the following steps. Forward the request in BurpSuite and send the request to repeater.

Again, we are sending the request to the repeater so that we can manually change parameters, and request methods, and see the response as the burp repeater is a tool that is designed to allow the user or attacker to change or resend a particular HTTP request and analyze the response generated by it.
Again, we are sending the request to repeater so that we can manually change parameters, and request methods, and see the response as burp repeater is a tool that is designed to allow the user or attacker to change or resend a particular HTTP request and analyze the response generated by it.

The main step in an IDOR attack is to change the parameters like 'id' in our request. And that is exactly what we will do here. As we can see in the image above, the initial parameters while changing the password were:

Expand All @@ -46,7 +46,7 @@ Now try to replace the value of id with 1. After sending the request, you will s

Hence we can see that we have successfully changed the password for the user with id=1, which is a different user than the one we are currently logged in as. Therefore we have completed our IDOR attack and managed to change the password of a completely different user.

Now, just to confirm that our attack was successful, we will try to log in as the user whose password we just changed. For that, we will require the email id of that user. That is now a very easy task for us as we have already learned to do it in our previous task, SQLi attack. Here we will repeat some of the steps of the SQLi attack.
Now, just to confirm that our attack was successful, we will try to log in as the user whose password we just changed. For that, we will require the email id of that user. That is now a very easy task for us as we had already performed an SQLi attack. Here we will repeat some of the steps of the SQLi attack.

In the Burp's embedded user, we will go to the Users tab, and again search for a random character, let it be u this time. This is done just so that we can intercept the request and send it to the repeater to change the parameters manually, as you are already familiar with. Now again, we will alter the 'value' and 'authlevel' parameters and replace their values with the following:

Expand Down
14 changes: 7 additions & 7 deletions solutions/module-1/04-Sensitive Data Exposure.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,15 +4,15 @@ We will use ZAP to identify if a sensitive resource was left unprotected by deve

# Solutions

Go to the home page of the lambda request URL provided. On that page, right-click and select the 'inspect' option. This will lead you to the network view, which allows us to see and analyze the network requests that make up each individual page load within a single user's session. We can use this view to investigate the page for flaws in access control.
Go to the home page of the lambda request URL provided. On that page, right-click and select the 'inspect' option. This will lead you to the network view, which allows us to see and analyze the network requests that make up each page load within a single user's session. We can use this view to investigate the page for flaws in access control.

Reload the page after going to the network view to view all the network requests. Amongst those requests, you have to click on the network request named as 'list-posts' and we will get the request URL for it, as shown in the image below:
Reload the page after going to the network view to view all the network requests. Amongst those requests, you have to click on the network request named 'list-posts' and we will get the request URL for it, as shown in the image below:

![](https://user-images.githubusercontent.com/65826354/179528203-e6dc2171-216e-48aa-8efc-03d2c54260e0.png)

So we have acquired the request URL that we need to explore. Now we are going to use OWASP ZAP to further explore the URL.

OWASP ZAP is an open-source tool and is used to perform penetration tests. The main goal of Zap is to allow easy penetration testing to find the vulnerabilities in web applications. We will use ZAP here for the same purpose, to find the vulnerabilities in our application.
OWASP ZAP is an open-source tool and is used to perform penetration tests. The main goal of ZAP is to allow easy penetration testing to find the vulnerabilities in web applications. We will use ZAP here for the same purpose, to find the vulnerabilities in our application.

So now open up ZAP and on the home page, select the 'Manual Explore' option. Inside that, you will find a field named 'URL to explore'. In that field, insert the request URL for network request 'list-posts' that you just acquired in the above step. After entering the URL, click on the 'Launch Browser' button. We will get the following output at the site's tree structure.

Expand All @@ -24,7 +24,7 @@ Now go to:
v1 -> GET:list-posts -> Attack -> Fuzz...
```

We will be basically doing fuzzing in this task. Fuzzing is a type of testing that can be performed through ZAP, where the user sends unexpected or random data as the inputs of a website. The fuzzer doesn't actually report any issues, it just throws the text we specify at the field and tells us how the application responded to it. We need to manually examine the results and decide if they are real vulnerabilities.
We will be fuzzing the API endpoint in this task. Fuzzing is a type of testing that can be performed through ZAP, where the user sends unexpected or random data as the inputs of a website. The fuzzer doesn't report any issues, it just throws the text we specify at the field and tells us how the application responded to it. We need to manually examine the results and decide if they are real vulnerabilities.

The fuzzer window will now be open on your screen. Then select the text list-posts as shown in the image below as this is the field we want to replace with dictionary values.

Expand All @@ -38,11 +38,11 @@ The default type of the value to be added is String. But in this task, we need t
/usr/share/wordlists/dirb/common.txt
```

After finding the correct file, click on 'add' to the file as the input at the selected text. Now in the fuzzer window, go to the Options tab to change the parameter 'Concurrent Scanning threads per scan'. Its initial value would be 15, change it to 20. It basically signifies the number of threads the scanner will use per scan. Increasing the number of threads will speed up the scan but may put extra strain on the PC.
After finding the correct file, click on 'add' to the file as the input at the selected text. Now in the fuzzer window, go to the Options tab to change the parameter 'Concurrent Scanning threads per scan'. Its initial value would be 15, change it to 20. It signifies the number of threads the scanner will use per scan. Increasing the number of threads will speed up the scan but may put extra strain on the PC.

After successfully changing the parameter, click on 'start fuzzer' to start the scanning. Once the scanning starts, we will see that all of our payloads are being sent, but most of them are returning a '403 Forbidden' code, which is completely expected. We will continue our scan until we find a vulnerability.

After some time, we will see that the payload dump is returning code 200, status OK. We have finally found our vulnerability. We can click on 'Code' if we can't find it. It will look like this:
After some time, we will see that the payload dump is returning code 200, status OK. We have finally fuzzed an API endpoint. We can click on 'Code' if we can't find it. It will look like this:

![](https://user-images.githubusercontent.com/65826354/179528237-2e6394f6-16f9-4696-bfe2-c1d220e03d17.png)

Expand All @@ -52,4 +52,4 @@ Now open the browser and paste the URL of the dump payload that we just grabbed.

![](https://user-images.githubusercontent.com/65826354/179528247-75424528-75c2-40b3-b69b-9f36b6c32b28.png)

So we can see that we have completed this task successfully, found a sensitive data exposure flaw, and exploited it using ZAP's fuzzer to gain access to unauthorized data.
So we can see that we have found a sensitive data exposure flaw, and exploited it using ZAP's fuzzer to gain access to unauthorized data.
12 changes: 7 additions & 5 deletions solutions/module-1/05-Server Side Request Forgery Part 1.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Objectives

In this task, you will try to perform an SSRF attack and try to fetch the */etc/passwd/* file from the Lambda Execution Environment.
We will try to perform an SSRF attack and try to fetch the */etc/passwd/* file from the Lambda Execution Environment.

# Solution

Expand All @@ -12,20 +12,22 @@ Open the web application put in the login credentials and interact with the web

![](https://user-images.githubusercontent.com/65826354/179528330-7bf9f93e-affd-4525-88ae-57b763ecf076.png)

## Step 2: From side navigation menu select Newpost
## Step 2: From the side navigation menu select Newpost

![](https://user-images.githubusercontent.com/65826354/179528339-b0f62e1b-55e8-48a2-b3d7-90ef9ef841dc.png)

Enter any demo headline for the post like, "Sample post check for SSRF". Also, fill in the Author Name.
Enter any demo headline for the post like, "Sample post check for SSRF". Also, fill in the Author's Name.

In "Enter URL of image" field, write down the below-mentioned payload.
In the "Enter URL of image" field, write down the below-mentioned payload.

Payload:

```
file:///etc/passwd/
```

The file scheme is used to access files stored on the local system, the payload if successful will let us view the contents of file */etc/passwd*.

![](https://user-images.githubusercontent.com/65826354/179528349-06a08046-9e17-47b3-b83f-ef707563b5e8.png)

## Step 3: Go to inspect elements and click on the upload button.
Expand All @@ -48,7 +50,7 @@ After the successful download of data, you will find that the data is in .png fo

## Step 5: Open the terminal to display the data.

Open the terminal and run the below mentioned command to display the content of the */etc/passwd/* file.
Open the terminal and run the below-mentioned command to display the content of the */etc/passwd/* file.

Command:

Expand Down
Loading

0 comments on commit 6138a9a

Please sign in to comment.