18

Experiment 6
Aim: - SQL Injection: Use DVWA to practice SQL injection attacks. Demonstrate how an
attacker can manipulate input fields to extract, modify, or delete database information.

Theory: -
SQL Injection (SQLi)

SQL injection is one of the most common attacks used by hackers to exploit any SQL database-driven web
application. It’s a technique where SQL code/statements are inserted in the execution field with an aim of
either altering the database contents, dumping useful database contents to the hacker, cause repudiation issues,
spoof identity, and much more. Let’s take a simple scenario where we have a web application with a login
form with username and password fields. If the developer used PHP for development, the code would look
like this:
If a user Karen with the password
‘12345’ wanted to log in, after
clicking the Submit or the Log in
button, the query that would be
sent to the database would look
like this:
If an attacker knew the username
and wanted to bypass the login
window, they would put
something like Karen;-- in the
username field. The resulting
SQL query would look like this:

What the attacker has done, is adding the -- (double-dash) which comments the rest of the SQL statement. The
above query will return the information entered in the password field making it easier for the attacker to bypass
the login screen.

How to Prevent SQL Injection?

The main reason that makes websites vulnerable to SQL injection attacks can be traced back to the web
development stage. Some of the techniques that can be implemented to prevent SQL injection include:

• Input validation: If the website allows user input, this input should be verified whether it’s allowed or not.
• Parametrized queries: This is a technique where the SQL statements are precompiled and all you have to do
is supply the parameters for the SQL statement to be executed.
• Use Stored procedures
• Use character-escaping functions
• Avoid administrative privileges: Don't connect your application to the database using an account with root
access.
• Implement a Web application firewall (WAF)

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

 19
Any penetration tester who wants to get started or advance their skills in SQL injection will need vulnerable
platform to practice. There are many vulnerable applications available both for offline and online use.
In this particular tutorial, we will focus on the Damn Vulnerable Web Application (DVWA).

Pre-requisites
This tutorial expects that you have an up and running DVWA setup. If you have not yet installed DVWA on
your Kali Linux system, please check out the article which gives a step-by-step guide.

Step1: Setup DVWA for SQL Injection

After successfully installing DVWA, open your browser and enter the required URL 127.0.0.1/dvwa/login.php
Log in using the username “admin” and password as “password”. These are the default DVWA login credentials.
After a successful login, set the DVWA security to LOW then click on SQL Injection on the left-side menu

DVWA SQL Injection

Step2: Basic Injection
On the User ID field, enter “1” and click Submit. That is supposed to print the ID, First_name, and Surname
on the screen as you can see below. The SQL syntax being exploited here is

DVWA Basic SQL Injection

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

 20

Interestingly, when you check the URL, you will see there is an injectable parameter which is the ID.
Currently, my URL looks like this:

Let’s change the ID

parameter of the URL to
a number like 1,2,3,4 etc.
That will also return the
First_name and Surname
of all users as follows:

If you were executing

this command directly
on the DVWA database,
the query for User ID 3
would look like this:

SQL Injection
Step3: Always True Scenario
An advanced method to extract all the First_names and Surnames from the database would be to use the input:
%' or '1'='1'.

Always True Injection

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

 21
The percentage % sign
does not equal anything
and will be false. The
'1'='1' query is registered
as True since 1 will
always equal 1. If you
were executing that on a
database, the query
would look like this:

SQL Injection

Step4: Display Database Version

To know the database version the
DVWA application is running on,
enter the text below in the User
ID field.
The database version will be
listed under surname in the last
line as shown in the image below.

Display database version

Step5: Display Database User
To display the Database user
who executed the PHP code
powering the database, enter the
text below in the USER ID field.

The Database user is listed next

to the surname field in the last
line as in the image.

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

 22
Step6: Display Database Name
To display the database name,
we will inject the SQL code
below in the User ID field.

The database name is listed next

to the surname field in the last
line.

Step7: Display all Tables in Information Schema

The Information Schema stores
information about tables, columns,
and all the other databases
maintained by MySQL. To display
all the tables, present in the
information_schema, use the text
below.

Step8: Display all the user tables in information_schema

For this step, we will print all the
tables that start with the prefix
user as stored in the
information_schema. Enter the
SQL code below in the User ID.

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

 23
Step9: Display all the columns fields in the information_schema user table
We will print all the columns
present in the users’ table. This
information will include column
information like User_ID,
first_name, last_name, user, and
password. Enter the input in the
User_ID field.

Step10: Display Column field contents

To display all the necessary
authentication information
present in the columns as stored
in the information_schema, use
the SQL syntax below:

From the image above, you can see the password was returned in its hashed format. To extract the password,
copy the MD5 hash and use applications like John the Ripper to crack it. There are also sites available on the
internet where you can paste the hash and if lucky, you will be able to extract the password.

Conclusion
SQL injection proves to be a critical vulnerability that can exist in a system. Not only can attackers exploit it
to reveal user or customer information, but it can also be used to corrupt the entire database thus bringing the
whole system down. Injection is listed as the number one vulnerability in the OWASP Top 10 Vulnerabilities
summary. The DVWA acts as a reliable resource for both penetration testers who want to improve their skills
and web developers who want to develop systems with security in mind

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

 24

Experiment 7

Aim: - Cross Site Scripting XXS: Exploit XXS vulnerability in DVWA to inject malicious
scripts into web pages, Show the potential impact of XXS attacks, such as stealing cookies or
defacing websites.

Theory: -
Cross Site Scripting XXS

Cross Site Scripting (XSS) is a vulnerability in a web application that allows a third party to execute a script in
the user’s browser on behalf of the web application. Cross-site Scripting is one of the most prevalent
vulnerabilities present on the web today. The exploitation of XSS against a user can lead to various consequences
such as account compromise, account deletion, privilege escalation, malware infection and many more.

Vulnerability

Cross-site scripting works by manipulating a vulnerable web site so that it returns malicious JavaScript to
users. When the malicious code executes inside a victim's browser, the attacker can fully compromise their
interaction with the application.

Types Of XXS

1. Stored XSS (Persistent XSS) : -

The most damaging type of XSS is Stored XSS (Persistent XSS). An attacker uses Stored XSS to inject
malicious content (referred to as the payload), most often JavaScript code, into the target application. If there
is no input validation, this malicious code is permanently stored (persisted) by the target application, for
example within a database. For example, an attacker may enter a malicious script into a user input field such
as a blog comment field or in a forum post. When a victim opens the affected web page in a browser, the XSS

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

attack payload is served to the victim’s browser as part of the HTML code (just like a legitimate comment
25
would). This means that victims will end up executing the malicious script once the page is viewed in their
browser.

2. Reflected XSS (Non-persistent XSS): -

The second and the most common type of XSS is Reflected XSS (Non-persistent XSS). In this case, the
attacker’s payload has to be a part of the request that is sent to the web server. It is then reflected back in such
a way that the HTTP response includes the payload from the HTTP request. Attackers use malicious links,
phishing emails, and other social engineering techniques to lure the victim into making a request to the server.
The reflected XSS payload is then executed in the user’s browser. Reflected XSS is not a persistent attack, so
the attacker needs to deliver the payload to each victim. These attacks are often made using social networks.

3. DOM-based XSS: -
DOM-based XSS is an advanced XSS attack. It is possible if the web application’s client-side scripts write
data provided by the user to the Document Object Model (DOM). The data is subsequently read from the
DOM by the web application and outputted to the browser. If the data is incorrectly handled, an attacker can
inject a payload, which will be stored as part of the DOM and executed when the data is read back from the
DOM. A DOM-based XSS attack is often a client-side attack and the malicious payload is never sent to the
server. This makes it even more difficult to detect for Web Application Firewalls (WAFs) and security
engineers who analyze server logs because they will never even see the attack. DOM objects that are most
often manipulated include the URL (document.URL), the anchor part of the URL (location.hash), and the
Referrer (document.referrer).

Steps to Exploit XXS Vulnerability:

To exploit a stored XSS vulnerability in a social media platform where users can post messages and comments,
follow these steps:

1. Craft a Malicious Comment: -

• Create a seemingly harmless comment that includes a malicious script to steal user cookies

2. Post the Comment: -

• Post the malicious comment on the social media platform.
3. Trigger the Malicious Script: -
• When a victim visits the page containing the malicious comment, their browser executes the embedded
JavaScript code, sending their sensitive session information in cookies to the attacker's server.
4. Exploit Stored XSS in DVWA:
• Log in to DVWA using default credentials or your own.
• Choose the "Low" security level and navigate to "XSS (Stored)".

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

 • Input a name and the payload <script>alert('stored XSS');</script> in the message field. 26
• Click "Sign Guestbook" to confirm the vulnerability

XXS pop up
• For the "Medium" security level: -
- Input the payload <img src="x" onerror="alert('stored XSS');">into the name field.
- Modify the maxlength attribute to bypass client-side restrictions.
- Submit the form to confirm the successful exploitation.

• For the "High" security level –

- Input the payload <iframe src="https://hacked.com"></iframe> into the name field.
- Submit the form to confirm the successful exploitation.

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

 27

These steps demonstrate how to exploit stored XSS vulnerabilities in different security levels of DVWA.

Prevention Of XXS Attacks

Preventing cross-site scripting is trivial in some cases but can be much harder depending on the complexity
of the application and the ways it handles user-controllable data.
In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the following
measures:
• Filter input on arrival. At the point where user input is received, filter as strictly as possible based on
what is expected or valid input.
• Encode data on output. At the point where user-controllable data is output in HTTP responses, encode
the output to prevent it from being interpreted as active content. Depending on the output context, this might
require applying combinations of HTML, URL, JavaScript, and CSS encoding.
• Use appropriate response headers. To prevent XSS in HTTP responses that aren't intended to contain
any HTML or JavaScript, you can use the Content-Type and X-Content-TypeOptions headers to ensure that
browsers interpret the responses in the way you intend.
• Content Security Policy. As a last line of defense, you can use Content Security Policy (CSP) to reduce
the severity of any XSS vulnerabilities that still occur.

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

 28

Experiment 8

Aim: - Cross-Site Request Forgery (CSRF): Set up a CSRF attack in DVWA to

demonstrate how attackers can manipulate authenticated users into performing
unintended actions.

Theory: -
Cross Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web
application in which they’re currently authenticated. With a little help of social engineering (such as sending
a link via email or chat), an attacker may trick the users of a web application into executing actions of the
attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform
state changing requests like transferring funds, changing their email address, and so forth. If the victim is an
administrative account, CSRF can compromise the entire web application.
Before going into implementation, it would be nicer to understand why and how the attacks work. To
elaborate, first, we need to know what HTTP protocol is. HTTP protocol (a.k.a Hyper Text Transfer Protocol)
is a network protocol for the web applications.

It works as following:
Clients ask for HTTP request to server, and server responds to the client by giving status code.
However, it is very important to notice that HTTP is stateless. That is, there is no record of previous
interactions and thus, users have to go through the authentication/verification process whenever they make a
new request. Think of checking email. Though you have definitely logged into google to check your email,
you have to log in again when you check your mailbox. What a big inconvenience! And this is where the
session and cookie come in.
Two things to know. The first cookie, and second session. cookie contains data in form of dictionary for
purpose of transferring data between client and server. And session is to have a state, allowing to maintain a
particular state until closing the browser. The basic idea is following:
Once accessing to web application, cookie is stored at local hard disk and session ID is generated, and session
ID is also stored in cookie. if clients try to access again, cookie with session ID is transferred to web server to
give false impression that clients have been maintaining the state.

Changing Password with CSRF using DVWA

As the default setting is set to be impossible, please change its security to be low.

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

Get method to transfer new password being used. 29

First, we need to know

how the process normally
works. Please select
CSRF from the menu bar,
and try to change the
password. Accordingly,
you can find the HTTP
request on Burp-suite as
following.

User can notice that Get method is used to transfer passwords without any encryption. What we are going to
do is that by exploiting data from HTTP request, we aim to change the password of the victim as we have
previously set.
To make it a bit realistic, I sent an e-mail claiming that I won a lottery to myself (victim) with HTML
containing a malicious request. Like this. (you can find sample HTML file(csrf.html) below is the part of the
code to make request to server.

As seen in the figure

attached above, the code
is written in JavaScript
and the very same
parameters that we
obtained from Burp-Suite
is used.

Once the receiver (me) found the e-mail and clicked the provided link, you can find that Get request is
transferred to web server and the password of the innocent receiver has been simultaneously changed. The
thing is unless specifically notified of changing password, the victim is very unlikely to notice the change.
While I have made a button to make change visible. You may try to use on load function.

On left, you can find

request has successfully
transferred / On right is the
screen of csrf.html

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

 30
In order to launch an attack
successfully, it is necessary
that the victim should be
logged in.

Try to distinguish between

normal request (left) and
malicious request(right)

The grounds for a successful attack lie on the cookie. As seen above, the same cookie has been used, meaning
that web server has no choice but to treat the malicious requests as equally as normal requests. Also, you can
notice that the parameter for changing password and referer, origin indicating where the request came from
have been changed. Next, we will try to hack medium level. In medium level, web server tries to protect itself
from being attacked by checking ‘referer’.

Changing security level to

medium — it checks
‘referer’.

You can see that an identical

attack used for low security
does not work as intended.
You can check this on Burp-
suite (click the response tab
for the request and go to
render.

Checking the response — it

fails to change password.

However, checking the referer cannot be an ultimate solution because attack can be implemented on the very
particular web server, thus avoiding the protection scheme. Moreover, if you look into the code, it can be
shown that protection will become useless if the attacker include web server address.

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

 31
Changing file name makes
attack successful!

DVWA provides one of ideal solution to protect password from CSRF attack. That is, to require users to
provide current password. It can be seen if you change security level to impossible.

If the attacker implements CSRF only attack, there is no way for him to get current password. As he cannot
extract current password, the attack is never going to happen.

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

 32

Experiment 9
Aim: - File Inclusion Vulnerabilities: Explore remote and local file inclusion vulnerabilities
in DVWA. Show how attackers can include malicious files on a server and execute arbitrary
code.

Theory: -
File Inclusion Attack
It is an attack that allows an attacker to include a file on the web server through a php script. This vulnerability
arises when a web application lets the client submit input into files or upload files to the server. A file include
vulnerability is distinct from a generic Directory Traversal Attack, in that directory traversal is a way of
gaining unauthorized file system access, and a file inclusion vulnerability subverts how an application loads
code for execution. Successful exploitation of a file include vulnerability will result in remote code execution
on the web server that runs the affected web application.

This can lead to the following attacks:

1. Code execution on the web server
2. Cross Site Scripting Attacks (XSS)
3. Denial of Service (DOS)
4. Data Manipulation Attacks

Types:
a) Local File Inclusion
b) Remote File Inclusion

LFI vulnerabilities allow an attacker to read (and sometimes execute) files on the victim machine. This can
be very dangerous because if the web server is misconfigured and running with high privileges, the attacker
may gain access to sensitive information. If the attacker is able to place code on the web server through
other means, then they may be able to execute arbitrary commands.

RFI vulnerabilities are easier to exploit but less common. Instead of accessing a file on the local machine,
the attacker is able to execute code hosted on their own machine.
Remote File inclusion (RFI) and Local File Inclusion (LFI) are vulnerabilities that are often found in poorly-
written web applications. These vulnerabilities occur when a web application allows the user to submit input
into files or upload files to the server.
a. Local File Inclusion in Action

Difficulty: LOW
Now start your machine and login to DVWA, then go to DVWA security tab and change the difficulty level
to low.

Go to file inclusion tab and change the URL from incude.php to ?page=../../../../../../etc/passwd.

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

 33

change the URL from?page=../../../../../../etc/passwd to ?page=../../../../../../proc/version.

Difficulty: MEDIUM
Now, go on and try the exploits we used in low difficulty. You will notice that you can’t read files like before
using the directory traversal method. So, as you can see in the below snapshot of source page, the server is
more secure and is filtering the ‘../’ or ‘..\’pattern. Let’s try to access the file without ‘../’ or ‘..\’.

Change include.php to /etc/passwd Now,change the URL from?page=/etc/passwd to ion.

As you can see, it worked by directly

entering the name of the file. Let’s level
up the difficulty to HIGH.

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

 34
Difficulty: HIGH
Change the difficulty to HIGH and try all exploits from medium difficulty, and you’ll notice none of them
will works because the target is more secure, as it is only accepting “include.php” or inputs starting with the
word “file”. If you try anything else, it will show “File not Found”.

In this level of security, we can still gather

sensitive info using the “File” URI scheme.
(because it starts with the word “file”)
Change the URL from include.php to
?page=file:///etc/passwd

You will get the data of /etc/passwd file.

This is how you can exploit file inclusion
vulnerability using local files on the web
server. Remote File Inclusion in Action

Now, let’s try to exploit this vulnerability

using remote files hosted on the attacker
machine.

Difficulty: LOW
Now, Let’s start with the Low difficulty.
Change the difficulty to low and go to file inclusion tab.
Let’s change include.php to http://www.google.com so the final URL will look something like this,
?page=http://www.google.com

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

Difficulty: MEDIUM 35

Change the difficulty to medium and

check as we did it in the low difficulty.
You’ll notice, it’s not working anymore.
The target is now filtering “http” and
“https” as shown in source page.

So try the attack with “HTTP” (in

CAPS) or any one word in caps like I
used as shown in snapshot (httP)and it’ll
work.

?page=httP://imdb.com

Difficulty: HIGH

We can’t exploit the high difficulty using RFI as we can see in source page, we know that the target web-
server is only accepting “include.php” or anything that’s starting with the word “file” that’s why we can’t
include anything from an outside server.

Points to Secure against File Inclusion Vulnerability:

a) Strong Input Validation.

b) A white list of acceptable inputs.
c) Reject any inputs that do not strictly conform to specifications.
d) For filenames, use stringent whitelist that limits the character set to be used.
e) Exclude directory separators such as “/”.
f) Use a white list of allowable file extensions.
g) Environment Hardening.
h) Develop and run your code in the most recent versions of PHP available.
i) Configure your PHP applications so that it does not use register globals.
j) Run your code using the lowest privileges.

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

 36

Experiment 10
Aim: - Brute-Force and Dictionary Attacks: Use DVWA to simulate login pages and
demonstrate brute-force and dictionary attacks against weak passwords. Emphasize the
importance of strong password policies.

Theory: -
Brute Force Attack
A brute force attack uses trial-and-error to guess login info, encryption keys, or find a hidden web page.
Hackers work through all possible combinations hoping to guess correctly. These attacks are done by ‘brute
force’ meaning they use excessive forceful attempts to try and ‘force’ their way into your private account(s).
This is an old attack method, but it's still effective and popular with hackers. Because depending on the length
and complexity of the password, cracking it can take anywhere from a few seconds to many years.
Burp Suite is one of the most helpful website hacking tools for conducting security testing of web applications.
It has various ethical hacking tools that work seamlessly together to support the entire penetration testing
process. It ranges from initial mapping to analysis of an application’s weakness.

a. Brute Force attack on DVWA with Burp Suite

Step 1: Inside DVWA, select the Brute Force option, which takes user to a Login page.

Step 2: Enter admin for the username and admin for the password, which is the wrong
username and password.

CYBERSECURITY WORKSHOP FILE

 37

Step 3: In the Burp Suite tool, follow the path: Target → Site map → http://localhost →
URL Containing the following:
/DVWA/vulnerabilities/brute/?username=admin&password=admin&Login=Login
HTTP/1.1

The Raw Request data is the HTTP request sent to the server during a brute-force attack. It contains all the
details required to send a request, such as the HTTP method, target URL, request headers, and request body.
As one can see, the username and password, admin & admin, user initially tried to log in with appears in line
1.

Navigated to Request → Raw tab → Right-click inside → Send to Repeater.

Step 4: Select the Repeater tab.

The Repeater in Burp Suite is a tool that allows
security testers to manually modify and re-send
HTTP requests and view the responses from a
web application. It is a handy tool for testing the
functionality and security of web applications, as
it allows testers to quickly and easily modify the
parameters and other data in a request to see how
the application responds.
In addition to modifying requests, the Repeater
displays the responses received from the
application, allowing testers to analyze and assess
the security of the application’s response
handling. Testers can also use the Repeater to
compare responses to identify differences and
inconsistencies that could indicate a vulnerability
or other security issue.

Step 5: Right-click inside the Raw data area → Send to Intruder.

The Intruder in Burp Suite performs automated
attacks on web applications and is designed to
automate sending a large number of requests with
various payloads to a target application to test for
vulnerabilities. For example, the Intruder can try
multiple input validation vulnerabilities, such as
SQL injection, cross-site scripting (XSS), buffer
overflows, and directory traversal attacks.

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

 38
Step 6: Select the Intruder tab → Positions.
Here we can Choose an attack type, Add or
Clear payload markers, and Start attack.

Clear all the payload markers, which are

highlighted in green.

All payload markers cleared.

Step 7: Insert new payload markers.

Highlighted admin after username → Selected Add.

Highlighted admin after password → Selected Add.

Both username=admin and password=admin are marked as payloads.

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

 39

Step 8: Selected Choose an attack type → Cluster bomb.

Clicked on the Payloads tab to configure and add a list of strings used as payloads.
For the first Payload set, Type a list of 17 words for the username.

Click the drop-down arrow in Payload set and select 2 for the second Payload set.

b. Start the Attacking with Kali Linux using dictionary attack for authentication login.

CYBERSECURITY WORKSHOP FILE SARTHAK GAUTAM

Step 1: The DVWA website from victim machine 40
Step 2: The website victim we will try to attack using password attack , it’s called dictionary attack.

Step 3: We will open Burp on Kali and interrupt the request and send it to the intruder to use the dictionary
attack.

Burp Proxy

Burp Intruder

We will use the most common password list in the payload to do the attack.

CYBERSECURITY WORKSHOP FILE ANSH KASAUDHAN