Abstract

Today network security is becoming more and more important in our daily lives. Since we
cannot live without the internet, it is more important to provide a good and secure network
environment. However, Cross-site scripting (XSS) can be used to inject malicious scripting code
into applications and then send the code back to the client. When users use a browser to access a
malicious code injection site, the code will be executed directly on the user’s computer.

The solution is to look for XSS in the browser’s JavaScript engine or look for the server
component to filter out malicious code. In any case, an attacker could create several new types of
malicious scripts to avoid detection and make it difficult to collect all the keywords in the search
list to avoid XSS attacks. Therefore, it is worth focusing on XSS so that more user looks for
more solutions to prevent XSS attacks.
Acknowledge
First of all, I would like to thank all the people who contributed to the realization of this project.
Thank to your encouragement and help. I have been able to do it without problems and able to
complete this project smoothly. I appreciate all of my lecture’s instructor and all the teachers
who taught me before. During working on this project, all imparted much useful knowledge to
me. All the enough suggestions gave much help on this project.
Contents
Abstract.......................................................................................................................................................1
Acknowledge...............................................................................................................................................2
1. Project Overview...............................................................................................................................4
1.2 Project Objectives............................................................................................................................4
2. Literature Review..............................................................................................................................5
2.1 Detail about Cross-site scripting...............................................................................................5
2.2 Requirement analysis of project requirement.........................................................................6
2.3 How Cross-site scripting affect.................................................................................................7
2.3.1 Stored XSS attack (Persistent).................................................................................................7
2.3.2 Reflected XSS attack (non-Persistent).....................................................................................7
2.3.3 DOM based XSS attack............................................................................................................7
3. Design.................................................................................................................................................8
3.1 Overview system flow of Cross-site scripting attack.....................................................................8
3.2 XSS attack system flow...................................................................................................................9
3.3 Attacker side..................................................................................................................................10
4. Analysis and Testing........................................................................................................................11
4.1 To test XSS vulnerability in web application.........................................................................11
4.2 To steal victim’s cookie session ID on Vulnerable Website..................................................12
4.3 Testing on Vulnerable website (bWAPP)...............................................................................13
4.4 Stealing user’s cookie session ID on bWAPP.........................................................................17
4.5 Testing in Xss-game.appspot.com...........................................................................................19
4.6 Testing on non-vulnerable website.........................................................................................24
4.7 Cross-site scripting Reflected (JSON)....................................................................................30
5. Prevention of XSS attack................................................................................................................35
5.1 Encoding.........................................................................................................................................35
5.2 Validation input.............................................................................................................................36
5.3 HTML Sanitizing...........................................................................................................................37
6. Project Summary.................................................................................................................................38
6.1 Discussion.......................................................................................................................................38
6.2 Conclusion......................................................................................................................................39
References.................................................................................................................................................40
 1. Project Overview

Virtually all businesses, most government agencies, and many individuals now have web
sites. The number of individuals and companies with Internet access is expanding rapidly and all
of these have graphical Web browsers. The reality is that the Internet and the Web are extremely
vulnerable to compromises of various sorts. As businesses wake up to this reality, the demand
for secure Web services grows.

Cybersecurity has become an essential part of every industry and many professionals are
showing interest in this particular domain.

This project is to protect web from cyber-attacks such as Cross-site scripting including
Store XSS attack, Reflected XSS attack and DOM based XSS attack which are common threats
for web. The attacker may use XSS scripting to steal directly from victim’s computers. It shows
how attacker could use Cross-site scripting (XXS), to steal sensitive data.

1.2 Project Objectives

 To test XSS vulnerability in web applications
 To understand XSS attacks
 To steal victim’s cookie session ID using XSS attacks
 To prevent XSS attacks
2. Literature Review
2.1Detail about Cross-site scripting
Cross site scripting (XSS)
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious
scripts are injected into otherwise benign and trusted websites. XSS attacks occur when
an attacker uses a web application to send malicious code, generally in the form of a
browser side script, to a different end user. Flaws that allow these attacks to succeed are
quite widespread and occur anywhere a web application uses input from a user within the
output it generates without validating or encoding it. The traditional use of XSS allows
the attacker to steal session cookies, allowing them to impersonate the user (the victim).
But it's not just about stealing cookies; Attackers can use XSS to spread malware, deface
websites, wreak havoc on social media, and phish for credentials, as well as carry out
more malicious attacks in combination with social engineering techniques. However, the
attacker does not attack the victim directly, and the attacker exploits a vulnerability in a
website visited by the victim and obtains the website to deliver the malicious script to the
attacker.
This project aims to do cookie session identifier theft via a cross-site scripting
vulnerability. An attacker can hack the session token using client-side malware or code. It
shows how an attacker can use an XSS attack to steal the session ID.
 2.2 Requirement analysis of project requirement
OS Requirements

 Window 7 / 10

Software Requirements

 XAMPP
 Vulnerable websites
bWAPP (Buggy Web Application)
xss-game.appspot.com
 Non-vulnerable websites
Netacad.com
KMD moodle
 Malicious script code
 2.3 How Cross-site scripting affect
Types of XSS attacks

1. Stored XSS attack (Persistent)

2. Reflected XSS attack (non-persistent)

3. DOM based XSS attack

2.3.1 Stored XSS attack (Persistent)

Injected script is permanently stored on the target servers, such as in a database, in a
message forum, visitor log, comment field, etc. The victim later retrieves the malicious
script from the server when it requests the stored information.

2.3.2 Reflected XSS attack (non-Persistent)

Injected script is reflected off the web server, such as in an error message, search result,
or any other response that includes some or all of the input sent to the server as part of the
request. Injected code travels to the vulnerable web site, which reflects the attack back to the
user’s browser.

2.3.3 DOM based XSS attack

Advanced type of XSS attack which is made possible when the web application’s client-
side scripts write user provided data 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.
 3. Design
3.1 Overview system flow of Cross-site scripting attack
Cross site scripting

Cross site scripting (XSS) is a common attack that injects malicious code into a
vulnerable web application. XSS attack differs from other web attacks (e.g., SQL injections) in
that it does not directly target the application itself. Instead, the users of the web application are
the ones at risk. XSS attacks are used to hijack an account, steal sensitive data, such as user
credentials or commercially valuable data.

Fig: 3.1.1 Overview diagram of XXS attack

Above figure shows the general architecture of the XSS attack. An attacker exploits a
website with XSS vulnerabilities by injecting malicious script code. If you respond to a pop-up
message on the Website: The site is said to be resistant to XSS attacks. If a user visits a website
with this vulnerability, Malicious script code runs and runs in the user's browser. Finally, an
attacker obtains sensitive user information through these XSS-vulnerable websites by using
malicious script code.
3.2 XSS attack system flow

Fig: 3.2.1 System flow diagram

The system diagram shows how an attacker could use an XSS attack to steal a session
ID. First of all, an attacker searches for websites that have XSS vulnerabilities and then
installs text boxes, Text areas; Include malicious script code in any input box, such as
website URL, etc., on the website. Malicious script code is used to indicate any code
between the <script> < / script> Get users' cookies intended for tags to be vulnerable
websites. When a user visits a website with this vulnerability, Malicious script code runs in
the user's browser. Finally, an attacker could use malicious script code to obtain access to a
user's data through a malicious website.
3.3 Attacker side

Fig: 3.3.3 Attacker side

How to know when Cross-site attacked

One of the dangers of an executed Cross Site Scripting attack is that to the user, nothing
looks different between prior the attack and after the attack. Therefore, users should be
careful to visit websites and web developers also must prevent their websites from XSS
attacks.
 4. Analysis and Testing
4.1 To test XSS vulnerability in web application
 To test XSS vulnerability, script code can be injected in many input areas:

 Website URL

 Search bar

 Contact Us area

 Sign in/ Sign up area

 Comment box and etc.

 Inject a simple script code like <script>alert(1)</script> into one of above areas.

 If a pop-up executes, that website means vulnerable to XSS.

 Users’ sensitive information can be stolen easily via those XSS vulnerable websites by
attackers.
4.2 To steal victim’s cookie session ID on Vulnerable Website
bWAPP (Buggy Web Application)

bWAPP is an open source deliberately insecure web application. It helps security

enthusiasts, developers and students to discover and to prevent web vulnerabilities. It
prepares to conduct successful penetration testing and ethical hacking projects. It is a
PHP application that uses a MySQL database. It can be hosted on Linux/Windows with
MySQL. It can also be installed with XAMPP. It supports many types of attacks such as
injection attacks, broken authentication and session management, cross-site scripting
attack, insecure direct object references, security misconfiguration, sensitive data
exposure and missing functional level access control attacks.
The bWAPP XSS vulnerability test page is shown in Figure 3. On the bWAPP
home page, evidence you must enter errors in the bee and password fields in the login
box. A Cross-Site Scripting attack is required to access the XSS attack test page, as
shown in Figure 3. The XSS attack can then be tested and an attacker could use malicious
script code to obtain sensitive user information. through the bWAPP website.

Fig:4.2.1 Vulnerability testing page

 4.3 Testing on Vulnerable website (bWAPP)

Fig: 4.3.1 Testing vulnerability to bWAPP

Showing in Fig 4.3.1 typing down name in the name box as normal user log in as usual.
Normal user will enter his/her name to enter in site. Every login was required this step to enter in
a site.
Display after insert a name

Fig: 4.3.2 Display after insert user name

After user done enter name in box, it will display “Welcome (name)” which shown in fig 4.3.2.
Testing vulnerability

<script>alert(‘You have been hacked’)</script>

Fig: 4.3.3 Inserting JavaScript in boxes

Validation of vulnerability to bWAPP

Fig 4.3.4: Validation of vulnerability to bWAPP

Figure 4.3.4 confirms that bWAPP is resistant to XSS attacks. To get a pop-up message
from the website, the attacker enters as shown in Figure 4.3.3. <script> </script> bWAPP is
known to be able to withstand XSS attacks because a warning message (You have been hacked)
appears between the tags.
 4.4 Stealing user’s cookie session ID on bWAPP

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

Cookie

Fig: 4.4.1 Stealing cookie session ID from bWAPP

Figure 4.4.1 prove that how to steal the cookie session ID of the vulnerable XSS website
bWAPP. Showing in Figure 4.3.3 and 4.3.4, the bWAPP is already resistant to XSS attacks, so
an attacker could steal the bWAPP cookie session ID. To steal a host ID from a cookie; Insert a
warning (document.cookie) between the <script> </script> tags.
Receive cooking session from bWAPP

Fig: 4.4.2 Receiving cookie session ID from bWAPP

In Figure 4.4.2, It indicates that the cookie session ID was obtained from the vulnerable XSS
website, bWAPP. An attacker enters unwanted script code into the input fields to steal the cookie
session ID message, as shown in Figure 4.3.4.
 4.5 Testing in Xss-game.appspot.com

Fig: 4.5.1 XSS vulnerability testing page of xss-game.appspot.com

This security game consists of several levels resembling real world applications which are
vulnerable to XSS to find the problem and attack the apps. XSS bugs are common because they
have a nasty habit of popping up wherever a web application deals with untrusted input. It only
supports testing for XSS attack.

Following Fig 4.5.1 shows XSS vulnerability testing area in xss-game.appspot.com. Information
about XSS scripting attack, missions and levels are displayed in home page. XSS attack can be
tested starting from level 1 to level 6 in xss-game.appspot.com. Then, attacker user’s sensitives
information from that XSS vulnerable website, xss-game.appspot.com.
Testing in xss-game.appspot.com vulnerable website

<script>alert(‘name’)</script>

Fig: 4.5.2 XSS vulnerability testing to xss-game.appspot.com

The XSS phase 1 test is shown in fig 4.5.2. The attacker inserted JavaScript code into the search
box to test XSS vulnerability. If user run a pop-up message, an attacker could steal sensitive user
information, such as a cookie session ID.
 Fig: 4.5.3 XSS vulnerability validation to xss-game.appspot.com

Fig 4.5.3 confirms that xss-game.appspot.com is vulnerable to XSS attacks. The attacker enters
to take advantage of the message that appears, as shown in fig 4.5.2. A warning message (name)
appears between the <script></script> tags. Therefore xss-game.appspot.com is known to be
resistant to XSS attacks.
Stealing cooking sessions ID from xss-game.appspot.com

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

Fig: 4.5.4 Stealing cooking session ID from xss-game.appsppot.com

Fig 4.5.4 shows the hacking session cookie ID of the website xss-game.appspot.com with XSS
vulnerability. xss-game.appspot.com is known to be vulnerable to XSS attacks, as shown in fig
4.5.3 and 4.5.4. Therefore, an attacker could steal a cookie session ID from xss-
game.appspot.com. An alert(document.cookie) is inserted between the <script></script> tags to
steal the session ID from the cookie.
 Fig: 4.5.5 Getting cookie session ID from xss-game.appspot.com
Fig 4.5.5 shows that the cookie operator ID received a notification from xss-game.appspot.com.
The attacker entered the malicious script code in the search box to steal the cookie session ID, as
shown in fig 4.5.4. Therefore, the cookie session ID message is alerted.
 4.6Testing on non-vulnerable website
Kmd.edu.mm /moodle (Non-vulnerable website)

Fig: 4.6.1 KMD Moodle login page

KMD student attendance, all educational programs and responsibilities are supported at
kmd.edu.mm/moodle. Therefore, this site must be secure as all kmd’s student’s attendance and
assignments are verified on this site. If moodle is vulnerable to XSS attacks, attackers can easily
steal student information.
 <script>alert(document.cookie)</script>

Fig: 4.6.2 XSS vulnerability testing in kmd.edu.mm/moodle (non-vulnerable website)

Fig 4.6.2 shows the XSS vulnerability for kmd.edu.mm/moodle. The attacker inserted JavaScript
code in the boxes to test the XS vulnerability at kmd.edu.mm/moodle. If alerted to a pop-up
message, kmd.edu.mm/moodle knows that it is capable of withstanding the XSS attack and that
the attacker can obtain sensitive information from students.
 Fig: 4.6.3 XSS non-vulnerability validation to kmd.edu.mm/moodle

A bad login error is displayed and the message does not appear as shown in fig 4.6.3. Therefore
kmd.edu.mm/moodle is known to be vulnerable to XSS attacks and the attacker could not easily
steal sensitive information of the students by using malicious script code.
XSS non- vulnerable websites

netacad.com

Fig 4.6.4 netacad.com log in page

The Cisco Networking academy website aims to provide hands-on learning opportunities and
change the lives of students. Therefore, websites like Cisco Networking Academy are great place
for students to study and learn. Training and gaining knowledge about Cisco networking on this
site should not be tolerated by any attacker. Therefore, it must be safe. To prevent XSS attacks
the official code included in the page source of this site.
 Fig: 4.6.5 XSS vulnerability testing to netacad.com

Fig 4.6.5 shows the XSS vulnerability test for netacad.com. the attacker inserted JavaScript code
into the input fields to test the XSS vulnerability. If user receive an alert about a pop-up message,
netacad.com knows that it could resist the XSS attack and that the attacker could gain access to
the confidential information of countless students.
 Fig 4.6.6 XSS non-vulnerability validation to netacad.com

Fig 4.6.6 shows and error that the pop-up message failed to receive a warning, and the
authentication error failed. As a result, netacad.com is known to be vulnerable to XSS attacks
and could not steal information from countless of users by using malicious script code.
 4.7Cross-site scripting Reflected (JSON)
XXS Reflected (JSON)

Fig 4.7.1 XSS Reflected (JSON)

Reflected cross-site scripting (JSON) attacks include when an attacker saves a malicious
script in a search or contact information present on a web site or contact form. A typical example
of multi-site scripting is the search form, visitor submit their search query to the serve and only
see the results.

JSON injection occurs when data from an untrusted source is removed from a server and
written directly to a JSON stream. This is known as server-side JSON injection. No data is
parsed directly using JavaScript’s evaluation function to purify data from untrusted sources.
 Fig 4.7.2 Movie name reflected

Type one movie name in given box. As shown in Fig 4.7.2 the movie name is reflecting in both
address bar and on the webpage and if the output got reflected on the address bar or on the
webpage then attacker can inject payload.
 Fig 4.7.3 Inject payload

As Fig 4.7.3 shown that payload didn’t work because whenever the result reflected on the web
page is always the same as trying to verify the source of the view page for that web page. That
way can understand the DOM structure of the HTML element. Then attacker can inject payload.
 Fig 4.7.4 View page source

The entire statement is covered with two references. Start with <script> tag and the first
statement are not close yet. To inject JavaScript code in order to execute payload first and need
to close the current statement and inject payload as a new statement in that way attacker can able
to execute current payload.

Fig 4.7.5

Close open and close curly braces, square brackets and single quote and add the semicolon at the
end of the statement to terminate the statement.

Fig 4.7.6

This will be the payload in order to started one <script> tag. No need to start <script> tag again
and only need to show the alert dialogue and close the </script> tag.
 Fig 4.7.7 Step to create the payload

Fig 4.7.8 Alert box Pop-up

As shown in fig 4.7.8 is successfully able to show the movie name on an alert dialogue box.
 5. Prevention of XSS attack
It is the responsibility of the web developer to prevent XSS attacks. The following precautionary
mechanisms should be considered to prevent XSS attack. In the page source code, to prove XSS
attacks, you need to write JavaScript code to prevent XSS attacks and to reject malicious script
code. XSS attacks can be prevented using the following XSS protection tool.

1. Encoding
2. Validation input
3. HTML Sanitizing

5.1 Encoding
Protection against XSS attacks allows the web developer to encode user input so that the browser
can translate it into code, not data.

Allows characters like < and > into &lt; and &gt;, respectively.

Fig 5.1.1 Getting user’s input to encode

Fig 5.1.1 shows the user or attacker input to encrypt to prevent XSS attack. Regular users enter
the actual information, but attackers use malicious JavaScript code to steal sensitive information
from users using XSS attacks. Malicious script code is required for the code to prevent XSS
attacks.
 Fig 5.1.2 Encoding attacker’s input to prevent XSS attacks

In fig 5.1.2 attacker entry Malicious JavaScript code is displayed as plain coding. Script tags are
encoded as <script> and </script> as text so malicious script code works as normal text without
compromising the system. Therefore, to prevent XSS attacks, it can be used as a code protection
mechanism on website.

5.2 Validation input

Instead of denying the request, enabling authentication is especially useful, as it prevents a user
from entering the fields without adding special characters and is good for protecting XSS in
forms. Filtering user input without removing all the code unnecessarily </html> <script> HTML
and JavaScript tags such as </script> are not allowed. The advantage of authentication is that
malicious entries are filtered into the page source code so that malicious script codes are
discarded without entering the site.
5.3 HTML Sanitizing
Although data cleansing is a strong defense, it should not be used alone to attack XSS attacks.
Clearing user input is especially useful on sites that allow HTML markup; The data received is
especially useful in ensuring that users do not jeopardize acceptable user input.

 If you sanitize content after updating it, your security attempts can be easily canceled.
 If the content is sent to the library for refinement, check that it doesn’t change the
sentence in any way. Otherwise, your security attempts are canceled again.
 You should regularly patch DOM purify or other HTML sanitization libraries you use.
Browsers are constantly changing their functionality and looking for regularly.
6. Project Summary

6.1 Discussion

After the description of the previous, the reader should be familiar with method of XSS
vulnerability attack. As we all know there are three main types of XSS STORE XSS,
REFLECTED XSS, DOM-based XSS which is changeable and unpredictable. Weakness
gradually changes many new bypasses filter expressions. The XSS vulnerability is becoming
more and more popular and XSS attacks will increase.
6.2 Conclusion
In this project, vulnerable web applications or websites can be identified by using XSS (Cross-
site scripting attacks). XSS attacks can be very dangerous for web applications because script
code can be injected in many input areas such as search bar, contact us area, sign in/ sign up area
and comment box. In addition, XSS can attack vulnerable web applications through simple script
code and gain victimization role through those vulnerable web application. Therefore, XSS
protection is very important for web security.

However, the XSS vulnerability is unbeatable. But it’s easy to reduce the risk of XSS attack.

On the user side, users should choose a secure web browser and update it. And use the latest
version web browser. If users do not do this either JavaScript or some Quick time functions
features are required and users can disable them. Use a JavaScript or script less version of
Firefox in a web browser. Nowadays, there are many anti-XSS software programs that could be
plug-in tools to help users find and block user’s web browser. XSS advises users to attack and
reject fake URLs.

For web application developers, in particular, it is important to filter it. Data input process, data
output process which eliminate harmful additives. In addition, developer have to pay more
attention to HTTP referrer and presentation methods. Therefore, if the web application has a
strong filtering policy, it will be reduced possibility of XSS vulnerability attack on clients.

Therefore, the key to eradication the XSS vulnerability is security. The only valid data is the
user’s input in the web browser and the security output. In the further XSS spying and anti-XSS
tools will be added. Let’s pay more attention to these and more users computers more secure.
References
https://outpost24.com/blog/How-identify-Cross-Site-Scripting-vulnerabilities
https://excess-xss.com
https://www.scribd.com/document/337103496/15-Vulnerable-Sites-to-Legally-Practice-Your-
Hacking-Skills
https://sourceforge.net/projects/bwapp/
https://www.apachefriends.org/index.html
https://xss-game.appspot.com/level1
https://owasp.org/www-community/attacks/xss/