0% found this document useful (0 votes)
2 views7 pages

Module 2 Experiment 2

The document outlines an experiment on Cross-Site Scripting (XSS) vulnerabilities using DVWA, focusing on exploiting these vulnerabilities to inject malicious scripts into web pages. It explains the types of XSS attacks, including Reflected and Persistent XSS, and demonstrates how these attacks can steal session cookies and execute harmful scripts. The experiment highlights the potential impact of XSS attacks on web applications and users.

Uploaded by

Movies 4 U khan
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views7 pages

Module 2 Experiment 2

The document outlines an experiment on Cross-Site Scripting (XSS) vulnerabilities using DVWA, focusing on exploiting these vulnerabilities to inject malicious scripts into web pages. It explains the types of XSS attacks, including Reflected and Persistent XSS, and demonstrates how these attacks can steal session cookies and execute harmful scripts. The experiment highlights the potential impact of XSS attacks on web applications and users.

Uploaded by

Movies 4 U khan
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Experiment – 7

Cross – Site Scripting (XSS)


Objectives:

a. Exploit XSS vulnerabilities in DVWA to inject malicious scripts into web pages.
b. Show the potential impact of XSS attacks, such as stealing cookies or defacing
websites

Introduction: Cross Site Scripting (XSS):

Cross Site Scripting or XSS is the most critical vulnerabilities in web applications. XSS allows
the attacker to send malicious scripts or code to the victim's computer system. With that code
injection can come numerous malicious activities.
If an application is vulnerable to XSS, the hacker can develop a URL that includes malicious
code and pass the code to the app as a legitimate user. When the user clicks on the link sent by
the hacker, the request is sent to the app. The code or script is generated on the server, sent to
the user's browser and is executed.

The classic Proof of Concept (POC) for XSS is to use JavaScript to trigger an alert box when
the script is run in the user's browser. This in itself is not malicious, but only indicates that the
application is vulnerable to injecting code.

XSS Payloads:

XSS can deliver multiple types of payloads. Javascript is powerful and flexible and therefore
is capable of delivering a wide range of malicious payloads. Some of the payloads include;
1. Pop up alerts
2. Hijacking session identifiers
3. Downloading and installing software
4. Redirecting to a different URL
5. Installing a keylogger
4. Invoking a reverse shell such as the Metasploit meterpreter
5. Launching client side attacks

Types of XSS

XSS is often divided into at least two types;


1. Reflective or Non Persistent
2. Persistent or Stored
Reflective XSS usually involves code that is "reflected" back to the web page and does
not persist after one use. Persistent or Stored XSS, as the name implies, is stored within
the application and can be run multiple times by multiple users.

In the following section, we will be using the DVWA to demonstrate such attacks and
vulnerabilities.
Step 1: Connect to the DVWA

To start, boot up a system running DVWA. Then, connect to the DVWA with your browser
from your Kali system.

Step 2: Set Security to Low

Using some simple XSS that is usually sanitized by modern secure web applications. For
demonstration purposes we are disabling that sanitizing process. For that reason, we need to
set the security level on our DVWA to "low".

Step 3: Reflected XSS Attacks

To perform a Reflected XSS, the victim must perform some action such as clicking on a link,
doing a search or some other functionality. The victim must also be logged into the application
when they click on the link.
To start, navigate to the Reflected XSS page in DVWA as seen below.

Now, go ahead and enter your name. I entered my name in the form "Occupytheweb".

As one can see above, the application comes back and greets me "Hello Occupytheweb" after
hitting Submit.

This time we will enter some script and see whether we can get the application to execute it.
The script to enter is;

<script>alert("Hello Hackers-Arise ") </script)

A cursory examination of this script reveals that we are triggering an alert box and having the
alert box say "Hello Hackers Arise"

So, instead of entering our name into the form, let's enter this [Link], hit Submit.
As you can see, the script was executed and an alert box was triggered with the message "Hello
Hackers-Arise". Clearly, this application is vulnerable to a Reflected XSS attack!
Reflected XSS is a one-time attack. Whoever clicks on the link will have the script executed in
their browser.

Step 4: URL Address Bar Attack

When we ran the Reflected XSS, you can see that the URL created by the attack changed. We
could use this URL that was created to execute the attack. The attacker could send this link to
the victim to execute the attack. To demonstrate, simply copy and paste the URL and enter it
into another tab in your browser.

As you can see, it works equally well to trigger the Reflected XSS attack.

Step5: Attacking Session Cookies

Although generating a pop-up alert box is interesting and proves the concept, it really does not
provide the attacker anything of value. What if we could have the alert box grab the session
cookie of the victim? In this way, the attacker could then use the cookie to authenticate against
the app as the legitimate user.
In this case, we will create a script that generates an alert, grabs the session cookie and displays
it.
The following script should do just that.
<script>alert([Link])</script>
As you can see, when we run this script, the application grabs and displays the users session
ID that then could be used to authenticate the attacker to the application!

Step 6: Persistent or Stored XSS Attacks

The persistent or stored XSS is very different from the Reflected XSS attack. Most importantly,
the attacker does not need to social engineer the victim to click on a URL, but rather stores the
malicious code into the application. In this way, every one who visits the malicious web page
will fall victim to this attack.

Persistent XSS attacks are far more malicious and damaging than reflected attacks. They are
capable of attacking numerous victims and implanting malware or other payloads into the target
system.
Let's start by clicking on the DVWA Stored Cross Site Scripting app.
This app represents a "Guest Book" of a web app where each user can enter their name and
comments. Obviously, a Guest Book will store the information entered into a back-end
database (MySQL in this case). If we can send a script to that back-end database, our script
will be stored there and run time and time again as people visit and use the Guest book.

Let's begin by entering our name, OTW. Then let's enter a bit of Javascript.

<script>alert("Hackers-Arise is BEST")</script>

If this script runs, it will open an alert box stating the obvious "Hackers-Arise is BEST".

When we click "Sign Guestbook", an alert box opens stating what we all know to be true.
As the application stores this information into the back-end database, we may be able to get
that script to run whenever anyone logs into the Guestbook.

Let's test that by entering as a different Guest and enter a different message. In this case, I will
enter as "John Doe" and leave a message "I'm so happy to be here".

When John Doe clicks to "Sign Guestbook" they get the same message that "Hackers-Arise is
BEST". Our XSS has persisted in the database and every guest will now be greeted with our
message!

Cross Site Scripting (XSS) is one of the most important and malicious vulnerabilities in web
applications. These attacks are capable of injecting any number of malicious payloads into the
victim's browser and ultimately into their computer system.

You might also like