CHAPTER 1

INTRODUCTION

What is attack on web applications?

Serious weaknesses or vulnerabilities allow criminals to gain direct and

public access to databases in order to churn sensitive data – this is known as a web
application attack. Many of these databases contain valuable information (e.g.
personal data and financial details) making them a frequent target of attacks.
1.1 GENERAL
The World Wide Web (WWW), refers to as the web platform, has evolved
into a large-scale system composed by millions of applications and services. In the
beginning, there were only static web pages which provide static information
expressed in text and graphics. As the Internet is growing, the web sites become
more professional and dynamic. In web application, in order to improve the user
experience, there is a trend that scripting languages (mostly JavaScript) have been
widely used. However, this trend also makes XSS (Cross-Site Scripting attacks)
which is one of the most serious threats to Internet. Some famous social
networking sites, such as Facebook, MySpace and Twitter have been suffered by
XSS attacks.
It is considered as one of the top 10 web application vulnerabilities by
the Open Web Application Security Project (OWASP) according to Cenzic
Application Vulnerability Trends Report. XSS has the features of self spread and
fast spread, and simple implementation as well, so it attract more and more
attention. Main aim of the project is to implement a technique which can secure the
web applications against cross site scripting attacks.

1
1.2 OBJECTIVES
XSS attacks are essentially referred to the illegal scripts injected in a web
page. When a user browses the page suffered by XSS attacks, the scripts embedded
in the web page will be triggered, resulting in some malicious attack effect. One of
the important reasons of this attack is that there is lack of common and
complete methodology for the evaluation either in terms of performance or needed
source code modification which in an overhead for an existing system. A
mechanism which will easily deployable and provide a good performance to
detect and prevent the Cross-site scripting (XSS) attack is essential one. One
obvious solution to protect web applications against such attack is escaping and
encoding method.
The objectives of this project are: to develop an understanding of the many
risks of XSS attacks, to identify some companies affected by XSS attacks and the
damages they suffered, to launch XSS attacks on a local server to measure the
damages they can cause, to propose best-practice solution to securing web
applications against XSS attacks.
1.3 TYPES OF XSS ATTACK
The way to inject malicious scripts into the web page can be
classified into three categories:
 Reflected (Non-Persistent) XSS Attack
 Stored (Persistent) XSS Attack
 Document Object Model (DOM) based XSS Attack
Reflected (Non-Persistent) XSS Attack
Reflected attacks are executed by the victim’s browser and occur when the
victim provides input to the website. Reflected attacks are those where the injected
code is reflected off the web server such as in an error message, search result, or any
other responses that include some or all of the inputs sent to the server as part of the
request. When a user is tricked into clicking on a malicious link or submitting a
2
specially crafted form, the injected code travels to the vulnerable web server, which
reflects the attack back to the user’s browser. The browser then executes the code
because it came from a trusted server.

Figure 1.3.1 Reflected XSS Attack

Stored (Persistent) XSS Attack

Stored XSS attacks save malicious scripts in databases, message forums, and
comment fields of the attacked server. The malicious script is executed by visiting
users, thereby passing their privileges to the attacker. Stored attacks are those where
the injected code is permanently stored on the target servers. The victim then
retrieves the malicious script from the server when it requests the stored
information. The persistent or stored XSS attack occurs when the malicious code
submitted by the attacker is saved by the server in the database and then
permanently runs in the normal page. Many websites host a support forum where
registered users can make contributions by posting messages, which are stored in
the database.

An attacker could post a message containing the malicious JavaScript code

instead. If the server fails to sanitize the input provided, it results in execution of the
injected script. The code will be executed whenever a user tries to read the post.

3
 Figure 1.3.2 Stored XSS Attack

Document Object Model (DOM) based XSS Attack

DOM-based XSS represents a new threat dimension to web applications, with
different prerequisites as compared to the standard XSS. Therefore, there exist some
web applications on the Internet that are vulnerable to DOM-based XSS without
showing features of the standard XSS. Attackers are able to collect sensitive
information from the user’s computer. For instance, an attacker might place a
malicious flash file on a site that clients visit. When the client’s browser downloads
the video, the file triggers a script in the browser and the attacker can take control of
elements of the pages inside the client’s browser.

4
1.4 REAL WORLD INCIDENTS OF XSS ATTACKS
The utmost noticeable attack discovered on web platform is XSS attack. Such
attacks are now transformed into a serious infection for contemporary web
platforms. The exponential Impact of XSS worms in recent years is given by
following figure.

Figure 1.4 Exponential Impact of XSS

1.4.1 XSS Attack on MySpace (2005)

In October 2005, an XSS worm attacked a popular social networking website
known as MySpace. Samy Kamkar, a 19-year-old hacker created the first known
XSS worm to exploit MySpace’s blacklist-based validation mechanism
(Dabirsiaghi, 2008). What made this attack so important is that it didn’t need user
input – it spread on its own – and it consequently popularized XSS attacks. Within
24 hours, the attack affected over one million MySpace users. Although Kamkar’s
worm was harmless in theory, MySpace had to briefly shut down to fix the problem
that allowed the worm to self-propagate, resulting in hours of lost production and
MySpace becoming a victim of the attack right along with all the affected users.
5
 Kamkar was able to penetrate MySpace’s system by uploading an infected
JavaScript to his profile, which then retrieved the user identity of the victim from
the HTML source using the DOM (Richie, 2007). The attack itself was possible
because an HTTP GET parameter was accepted without proper input validation
checks and then echoed back to the user. If a secure Hypertext Transfer Protocol
(HTTPS) had been implemented, this attack could have been prevented. (Richie,
2007). In retrospect, there were many opportunities to prevent this attack. MySpace
was capable of filtering the JavaScript, but failed to do so. Whitelisting and output
escaping also could have prevented this attack. Implementing a content security
policy could have blocked Kamkar from altering the code for his profile.
1.4.2 XSS Attack on PayPal (2006)
In June 2006, PayPal fell victim to an attack that had the potential to affect
over 200 million users. Although the code from the attack was never released, it was
said to be an XSS attack. The attacker inserted malicious code to retrieve
confidential user information (Borg, 2006) (Seals). The attacker targeted users by
sending an email stating their PayPal account had been disabled, and providing a
link that allegedly would forward them to a solution. Instead, the link pointed to a
malicious URL hosted on the legitimate PayPal website that asked for the user’s
social security number, credit card number, PIN, and other personal information
(Borg, 2006).
This attack hinged on the attacker’s malicious code being saved into the web
application repository by the server, and then launched on the victim’s browser
(Kour, 2016). This was possible because PayPal’s Web Application Firewall (WAF)
was outdated, and they were not filtering for malicious JavaScripts. PayPal never
revealed the amount of revenue it lost or the number of customers affected by this
XSS attack.

6
1.4.3 XSS Attack on Orkut (2010)
In 2010, an XSS vulnerability was exploited on Google’s social media
platform Orkut. It was a fast-moving malicious JavaScript that forced users to post
specific content. This attack affected a victim’s profile, then spread through all their
friends, who spread it to all their friends, and so on, ultimately affecting over five
million users all over the world. It spread overnight and infected users who viewed
emails or Orkut messages carrying the malicious payload (Higgins, 2007). The
email addresses of all victims were made available to the attacker which left them
vulnerable to further attacks. The vulnerability was fixed within a few hours and the
affected profiles were repaired. Since the accounts were connected to Google, all
users were instructed to reset their passwords.
Persistent XSS vulnerabilities like the one exploited in this attack are the
result of failing to properly sanitize input into forms. This allows attackers to insert
malicious code into pages (Constantin, 2010). Validating input could have been
used to prevent this XSS attack by making sure only legitimate data was being input
into the webpage forms.
Another effective measure would have been a content security policy that
could have prevented the malicious JavaScript from being loaded and executed in
the first place. In addition, Orkut didn’t use a secure protocol; if they had, the breach
also may have been prevented.
1.4.4 XSS Attack on Amazon (2013)
In December 2013, Amazon became a victim of a persistent XSS attack that
left their customers vulnerable to their information being stolen. The vulnerability
affected Kindle e-book readers. The malicious code was injected through e-book
metadata. For example, the attacker could add a book title containing code such as
“<script src="https://www.example.org/script.js"></script>” (Kovacs, 2014). This
allowed cookies to be accessed by the attacker, which could lead to personal

7
information being compromised, such as usernames and passwords. This
vulnerability affected everyone who used the Kindle library to keep their e-books.
Amazon took a little over a month to respond to this vulnerability. The attack
damaged Amazon’s reputation, and likely affected their revenue: users were afraid
to download the Kindle application due to all the bad press, which meant they
weren’t buying eBooks for the reader either. This vulnerability could have been
prevented by using intrusion detection systems, which wouldn’t have allowed the
attacker to insert malicious data via e-book metadata. Likewise, validating input
could have prevented the malicious code injection.
1.4.5 XSS Attack on Twitter (2014)
In 2014, an XSS vulnerability was found in TweetDeck, an application within
Twitter (Cross-Site Scripting (XSS) Found in Tweetdeck, 2014). The attacker
simply tweeted malicious JavaScript to make users automatically retweet tweets,
and it began to regenerate. At the time, Twitter had over 50 million users, and over
15 percent of them were affected. Users were concerned that their accounts had
been hijacked. The vulnerability remained on the site for so long that some users
began to use it to implement harmful JavaScript and possibly steal other users’
credentials.
It is very likely that many users’ information was stolen, although this was
never confirmed. This attack was possible because Twitter didn’t have an updated
WAF to filter code before it is processed to the webpage. To prevent this attack,
Twitter could have practiced sanitizing input, which would have prevented the
attacker from implementing the code in the browser. Twitter also could have
protected their restricted servers by implementing separation of duty and access so
that third parties would not be able to access them.

8
 CHAPTER 2
LITERATURE SURVEY

2.1 A MULTI-AGENT SCANNER TO DETECT STORED-XSS

VULNERABILITIES

The multi–agent architecture allows the different agents to be able to operate

independently, so the system is more efficient than those based on a single operator.
Multi-agent system is used for the scanning of web sites in an automated manner to
discover the occurrence of XSS vulnerabilities exploitable by stored XSS attack.
Such agents explore the web pages for locating the suspicious injection points where
XSS worms could be exploited. They also executes by sensing the input positions of
certain web pages and then inserting selected suspicious scripts at known input
positions. The vulnerability scanner does not need to have access to the source code
of the scanned application. Finally, their technique tests certain web pages for
injected scripts for confirming the attack.

ADVANTAGE
 The architecture is highly flexible.

 It is used for detecting stored XSS attack.

 The proposed system can be used by developers to enhance web
security.

DISADVANTAGE

 Performance is very low because of the existence of the exploitation of

multi-agent system to discover the malicious JavaScript code.

 Only few vulnerabilities are identified.

9
2.2 PROGRAM SLICING STORED XSS BUGS

Static detection algorithm is based on static analysis for detecting Stored XSS
bugs in PHP application and integrate it with program slicing method to generate
the slices of web application related to possible Stored XSS. This algorithm is to
locate possible vulnerabilities and then uses program slicing method to generate the
program slices related with the detected vulnerabilities. In contrast to traditional
static tainting-based approaches for detecting Reflected XSS, In this project the
algorithm is used for detecting Stored XSS and generate the complete related
program slices further for later manual checking or dynamic analysis. However, it
does not compatible with the object-oriented features of PHP and also the complex
program will make slicing difficult.

ADVANTAGE
 Efficient in performing the slicing of complex PHP program modules.
 More accurate array element treatment in alias analysis.
 Slicing the vulnerable program out when detecting a possible Stored
XSS.

DISADVANTAGE
 Does not compatible with the object-oriented features of PHP.
 Manual effort is needed to find vulnerabilities.
 Does not compatible with the dynamic web pages.

10
2.3 MACHINE LEARNING BASED CROSS SITE SCRIPTING
DETECTION IN ONLINE SOCIAL NETWORK

Machine learning techniques are utilized to initially aim for extracting the
Web pages as input and feature vector as an output which would be utilized in
classification of Web pages as suspicious or not. The identification of XSS infected
HTML web pages was done by utilizing the feature samples and the associated
machine learning algorithms. There are two classifiers on the basis of the
characteristics of these features, and they are proved to be effective for the proposed
features. A novel method is proposed to simulate XSS worm spreading and build
webpage database. As a web application, online social network has a lot in common
with general networks. By taking webpages in OSN’s traffic as ordinary pages, a
static analysis can be made on them. Then, four groups of features are extracted
from webpages. That are keyword features, JavaScript features, HTML tag
features, and URL features.

ADVANTAGE
 This technique is effective.
 This method is efficient in OSN’s XSS detection.
 Machine learning based feature extraction of web pages.

DISADVANTAGE
 Memory space can be wasted.
 Manual method for the collection of feature samples.

11
2.4 ROBUST TESTING PLATFORM FOR DOM-BASED XSS
VULNERABILITIES

Robust testing evaluates and identifies DOM-based XSS susceptibilities in

web applications. The technique rewrites JavaScript of the requested website to
achieve character-precise taint tracing. Dynamic taint tracking has been employed
to perform information flow analysis of JavaScript-based applications. DEXTERJS
stores taint information along with each string. DEXTERJS is designed to
instrument and scan both HTTP and HTTPS websites. DEXTERJS can scan pages
which require login by accepting valid cookies from the user. It has two core
modules: Instrumentation engine and Exploit generation. The former is responsible
for character-precise taint tracing. It intercepts HTTP request, recognizes malicious
JavaScript in the HTTP response. The later module analyses the tainted flows,
identified by the first module, and constructs context-based test payloads, which can
be simply tested on the vulnerable web site.

ADVANTAGE
 Capable to detect DOM-Based XSS Vulnerabilities.
 This approach is efficient in looking up taint information.
 It does not lead a memory blow up.

DISADVANTAGE
 Requires major changes in the source code of web applications.
 Memory space can be wasted.

12
2.5 AUTOMATED DETECTING AND REPAIR OF CROSS-SITE
SCRIPTING VULNERABILITIES THROUGH UNIT TESTING

A unit testing based approach is to automatically detect and repair XSS

vulnerabilities due to incorrect encoding function usage. The proposed approach
combines static-dynamic vulnerability detection technique based on unit testing
Static analysis is used to find the vulnerabilities have the advantage of complete
source code coverage but suffer from high rate of false positive results due to
ambiguities in determining whether a suspected vulnerability can actually be
exploited. Dynamic analysis approaches can find the vulnerabilities with low rate of
false positives due to using the real results of source code execution but suffer from
the source code coverage issue leading to false negatives. To reduce both false
positive and false negative, The Unit Test Construction component analyzes the
source code in order to automatically extract and generate unit tests for XSS
detection in such a way to ensure test coverage. The Attack Evaluation component
will use a repository of attack scripts, generated using the proposed Attack
Generation component, to evaluate each unit test. Reported vulnerabilities may be
examined by the auto-fixing component to find repairs.

ADVANTAGE
 This approach can be easily integrated into existing software
development practices.
 It can pinpoint the location of a vulnerability in the source code.

DISADVANTAGE
 Requires major changes in the source code of web applications.

13
2.6 MODEL CHECKING FOR THE DEFENSE AGAINST CROSS SITE
SCRIPTING ATTACKS

An automatic modeling method for the defense against cross-site scripting

attacks is proposed in the paper. Bugs of the website are found and counter
examples are showed with model checker SMV based on the website behavior
model expressed in CTL (Computation Tree Logic). An operation behavior is
judged if it conforms to requirements of the website for legal behavior, so as to
prevent XSS attacks from the point of operation. The website behavior model is a
standardized and formal representation of the user behavior and logical structure of
the website, for the interaction between the user browser and the web server. It is
used to describe the legitimate behaviors that the website permits, in other word,
only the behaviors that are addressed in the definition of the website behavior model
are the legitimate behaviors that the website permits. The website behavior model is
stored in the form of XML file in order to facilitate the client browser to recover the
model in a unified manner. By this way, bugs of some e-commercial websites
related to transaction process which can lead to the illegal scripts injected in a web
page were found before the websites online.

ADVANTAGES
 Bugs of the website are found
 Counter examples are showed with model checker SMV based on the
website behavior model expressed in CTL.

DISADVANTAGES
 Data privacy is more complex
 It needs to decrypt the stored data

14
 CHAPTER 3

EXISTING SYSTEM

3.1 EXISTING SYSTEM

Most of the recent existing work has focused on the development of XSS
defensive solution by re-architecting the existing infrastructure of web browsers by
applying machine learning algorithms. In existing approach normally developers use
java script validation or user input filter to prevent client side malicious inputs.
Some more secure web applications use application level firewall to filter user
request. But still, we are not able to stop XSS attacks. In this project, we prevent
XSS vulnerability on web applications using encoding and escaping method
efficiently when compared with existing methods.
3.2 DISADVANTAGE
 Only few vulnerabilities are identified.
 Does not compatible with the object-oriented features of PHP.
 Requires major changes in the source code of web applications.
 Manual effort is needed to find vulnerabilities.
 Does not compatible with the dynamic web pages.

15
 CHAPTER 4

PROPOSED SYSTEM
4.1 PROPOSED SYSTEM
There are several methods and approach for preventing the XSS
attack but still, it is not prevented completely. So we use a hierarchical approach
throughout the development process to secure the web application for both client
side and server side because a single method and approach are not sufficient to
handle it.
To prevent cross site scripting attacks, all variables output in a web page are
encoded before sending it to end users. Encoding variables output substitutes HTML
markup with alternate representations called entities. When entities are encoded,
the web application displays them but does not run them, such as <script> gets
converted to &lt;script&gt; Below table shows the entity name that we can use for
HTML encoding for some HTML characters.

Symbol Entity name Entity Numeric code

” Quotation mark &#34;
‘ Apostrophe &#39;
$ Dollar sign &#36;
% Percent sign &#37;
& Ampersand &#38;
/ Solidus (slash) &#47;
, Comma &#44;

Space &#32;

> Greater than &#62;

< Less than &#60;

16
4.1 TECHNIQUES

1. Validating the input

Input validation ensures that web application is providing trusted data

and keeping away untrusted or malicious data from harming the database,
web application, or end user’s personal data. It never allows direct insertion
of script, HTML comment, attribute name, tag name, CSS into the input field.

2. Encoding User Input

Data encoding is the modification of input data to make sure that it is

valid. It can be done by enclosing the received data in double quotes. By
changing an invalid data to a valid form confirms that the received data won’t
harm your web application or database. Encoding is transforming data from
one format into another format, while as the escaping is a subset of encoding,
where not all characters need to be encoded. Only some characters are
encoded.

3. Escaping User Input

The data received by a web application is secured before making it

available for the end user. This is referred to as escaping data or escaping data
inputs. This methodology prevents interpretation of received data in any
malicious manner. The web application is designed in such a way that it
censors the received data and does not allow the characters (mainly, ‘<’ and
‘>’) to be rendered. The escape method should be used for HTML, attribute,
CSS, URL values to prevent those characters that can be used to inject the
Script like &, ’, ”, /, \,<, >, &lt, &gt, &amp, &quot, &#x27, &#x2F and etc.

17
 CHAPTER 5
SYSTEM DESIGN
5.1 SYSTEM ARCHITECTURE
The overall system architecture diagram explains the structure of our
complete project in a graphical model in very simple and effective manner. It almost
holds every modules of our developing projects and the workflow of the
components and the relative data resources.

Figure 5.1 System Architecture

18
5.2 USE CASE DIAGRAM

A use case is a set of scenarios that describing an interaction between a user

and a system. A use case diagram displays the relationship among actors and use
cases. The two main components of a use case diagram are use cases and actors. An
actor is represents a user or another system that will interact with the system
modeled. A use case is an external view of the system that represents some action
the user might perform in order to complete a task.

Figure 5.2 Use Case Diagram

19
5.3 SEQUENCE DIAGRAM
A sequence diagram shows, as parallel vertical lines (“lifelines”), different
processes or objects that live simultaneously, and as the horizontal arrows, the
messages exchanged between them, in the order in which they occur. This allows
the specification of simple run time scenarios in a graphical manner.

WEB
ATTACKER APPLICATION WEB SERVER

Inject malicious code

Input Validation

Applying Encoding and

Escaping Method

Store Sanitized Input

Visit the Website

Display Sanitized webpage

Figure 5.3 Sequence Diagram

20
5.4 ACTIVITY DIAGRAM

Activity diagrams are graphical representations of workflows of stepwise

activities and actions with support for choice, iteration and concurrency. In the
Unified Modeling Language, activity diagrams can be used to describe the business
and operational step-by-step workflow of components in a system. An activity
diagram shows the overall flow of control.

Figure 5.4 Activity Diagram

21
 CHAPTER 6
SYSTEM REQUIREMENTS

6.1 HARDWARE REQUIREMENT

 Processor : Dual Core or Above
 RAM : 2 GB and Above
 Hard Disk : 80 GB or Above
 Monitor : LCD Monitor Above 15”

6.2 SOFTWARE REQUIREMENT

 Operating System : Windows 7/8/10
 Front End : HTML, CSS, JAVASCRIPT
 Back End Tool : phpMyAdmin
 Language : PHP, JAVASCRIPT
 Web Server : Wamp Server
 Web Browser : Firefox / Chrome

6.3 SOFTWARE ENVIRONMENT

6.3.1 INTRODUCTION

Wampserver is the web development environment. Wampserver refers

to a software stack for the Microsoft Windows operating system, created by
Romain Bourdon . WAMP is a variation of LAMP for Windows systems and
is often installed as a software bundle (Apache, MySQL, and PHP). It is often
used for web development and internal testing, but may also be used to serve
live websites. WAMP acts like a virtual server on our computer. It allows us to
test all Wordpress features without any consequences since it’s localized on
our machine and is not connected to the web.

22
Each letter represents:

1. “W” stands for Windows, there’s also LAMP (for Linux) and MAMP
(for Mac).
2. “A” stands for Apache. Apache is the server software that is responsible for
serving web pages. When we request a particular webpage, Apache grants
the request over HTTP and shows the site.
3. “M” stands for MySQL. MySQL’s job is to be the database management
system for the server. It stores all of the relevant information like site’s
content, user profiles, etc.
4. “P” stands for PHP. It’s the programming language that was used to write
WordPress. It acts like glue for this whole software stack. PHP is running
in conjunction with Apache and communicating with MySQL.

6.3.2 FEATURES OF WAMP SERVER

 It is an Open Source Web Server Package that is used to run web

applications Locally.

 More efficient as it has less performance issues compared to remote

servers.

 WampServer does not require File transfer Protocol to the server

therefore it is easy and first to edit files.

 It’s a light software that is smooth and easy to install and configure.

 Works best on windows operating system and specifically suitable

for projects in the production environment.

23
  Provides the ability to upgrade and downgrade some of its
components to provide a suitable production environment for the
user.

 Provides Apache-MySQL-PHP environment suitable for developing

web applications.

 Its available for both 64 bit and 32 bit windows operating systems.

 WampServer is easy to configure both during installation and use.

 Easy to configure different servers and support WordPress and

Drupal based applications.
 It provides reliable and User-friendly interface.

 WampServer is much secure to work with compared to other Web

servers as it provides login to database authentication capability.

 Provides an easier functionality of creating databases, relations,

relationships, triggers among other databases functionalities locally
on your computer.

 It enables software developers to easily setup local development

stack for developing web. 

 Level of customization it provides for apache/mysql and php is the

best. 

6.3.3 WAMPSERVER FRAMEWORK

The WampServer framework is a web application development
framework from Microsoft. It provides a controlled programming environment
where software can be developed, installed and executed on windows-based
24
 OS. While Apache, MySQL, and PHP are open source components that can be
installed individually, they are usually installed together. One popular package
is called "WampServer," which provides a user-friendly way to install and
configure the "AMP" components on Windows.

6.3.4 COMPONENTS OF WAMPSERVER

6.3.4.1 PHPMYADMIN
It allows web developers to change or add users and for making new
databases. phpMyAdmin is a free software tool written in PHP, intended to
handle the administration of MySQL over the World Wide Web.
phpMyAdmin supports a wide range of operations with MySQL. The most
frequently used operations are supported by the user interface (managing
databases, tables, fields, relations, indexes, users, permissions, etc), while
you still have the ability to directly execute any SQL statement.

25
 Figure 6.3.4.1 phpMyAdmin page

Features:
 Intuitive web interface
 browse and drop databases, tables, views, fields and indexes
 create, copy, drop, rename and alter databases, tables, fields and
indexes
 maintenance server, databases and tables, with proposals on
server configuration
 execute, edit and bookmark any SQL-statement, even batch-
queries
 manage MySQL users and privileges
26
  manage stored procedures and triggers
 Import data from CSV and SQL
 Export data to various formats: CSV, SQL, XML, PDF,
OpenDocument Text and Spreadsheet, Word, LATEX and
others
 Administering multiple servers
 Creating PDF graphics of your database layout
 Creating complex queries using Query-by-example (QBE)
 Searching globally in a database or a subset of it
6.3.4.2 APACHE
The most important part of the WAMP package is  Apache (or "Apache
HTTP Server") which is used to run the web server within Windows. By
running a local Apache web server on a Windows machine, a web developer
can test webpages in a web browser without publishing them live on the
Internet.

6.3.4.3 SQL SERVER

WAMP also includes MySQL  which is one of the most common
technologies used for creating dynamic websites. SQL Server is a relational
database management system from Microsoft that is designed for the enterprise
environment. It is a high-speed database. It supports to manage and store
collected data proficiently. It is the most popular and open-source. It runs on
T-SQL (Transact -SQL), a set of programming extensions from Sybase and
Microsoft that add several features to standard SQL, including transaction
control, exception and error handling, row processing, and declared variables.
By installing these components locally, a developer can build and test a

27
 dynamic website before publishing it to a public web server.

Figure 6.3.4.1 SQL server page

CHAPTER 7
IMPLEMENTATION AND RESULT
7.1 LIST OF MODULES
1. Creation of webpages
2. Database Connectivity
3. Detection of XSS vulnerability
4. Prevention of XSS attack
7.1.1 CREATION OF WEBPAGES
This work implements the creation of a sample website which has the cross
site scripting vulnerabilities using HTML, CSS, javascript with some basic user
28
interactions. The sample website needs to be run in a browser using localhost site
like wamp. We are going to demonstrate the types of XSS attacks on our site.
Our main page of web application looks like this:

7.1.2 DATABASE CONNECTIVITY

After designing web pages, database is required to store the data
given by the user. Database connectivity is established by using php language.
phpMyAdmin page with database and tables for this project look like this:

29
 Figure 7.2 Phpmyadmin page

7.1.3 DETECTION OF XSS VULNERABILITY

This module is about how to attack the site through cross site scripting
utilizing contents, with the end goal that we will prevent these attacks in our site
later. The way to inject malicious scripts into the web page can be classified into
three categories:
 Reflected (Non-Persistent) XSS Attack
 Stored (Persistent) XSS Attack
 Document Object Model (DOM) based XSS Attack
To begin with we are performing cross-site scripting on our website
through every one of these sorts of XSS attacks.
Reflected (Non-Persistent) XSS Attack
 Comment page of sample website looks like this

30
 Figure 7.3 Sample comment page

 In Comment page, the comments box allows the user to print their comments.
But instead of that, if the user enters some malicious script in the comments
box it just locally executes in the users session.
 Let us insert a script which displays text box.

Figure 7.4 Injecting text box script

 Let us insert a script which displays alert box.

31
 Figure 7.5 Injecting alert box script

 On executing this we get a comment page like below

Figure 7.6 Execution of alert box script

Stored (Persistent) XSS Attack

Persistent attack defines that the code that is going to harm the user should be
stored on the server side.
Attack Scenarios:
 Phishing Attack
 Comment page of sample website looks like this:

32
 Figure 7.7 Sample comment page

 Let us insert a script which displays internal frame.

Figure 7.8 Injecting internal frame script

 Let us insert a script which when we try to load original page gets redirected to
another page.

33
 Figure 7.9 Injecting page redirection script

 After executing this when we try to load that vulnerable webpage it gets
redirected to another website as shown below.

Figure 7.10 Redirection of original comment page

 Thus, this script is stored in the server side database and gets executed every
time the vulnerable site is run.

34
 Cookie Stealing
 To demonstrate cookie stealing attack, we create a simple web application in
which the users are allowed to comment on the picture after a successful login.

Figure 7.11 Sample login form

 New user can register with desire username and password by using their
mail id.

Figure 7.12 New user registration page

35
 Registered user can login to the comment page using their credentials.

Figure 7.13 user1 login - demo

 After a successful login cookie will be created for every user.

Figure 7.14 Displaying user cookie

 Comment page of this web application looks like below. Let us insert a script
which when we try to load original page gets redirected to attacker website
with user cookie.

36
 Figure 7.15 Injecting cookie stealing script

 In that website, the attacker can write the code to store the stolen cookies in his
text file.
 After executing this when other user login to the comment page their cookie
will be send to the attacker.

Figure 7.16 user2 login - demo

37
 When the user click on the link it will be redirected to attacker site.

Figure 7.17 user2 - session

 The injected script is stored in the server side database and gets executed every
time the vulnerable site is run.

Figure 7.18 Redirection with stolen cookies

 The attacker can view the stolen cookies in the text file itself. Using this
credentials the attacker can login as a normal user and also capable of changing
user’s password.

38
 Figure 7.19 Stolen cookies stored in text file

Document Object Model (DOM) based XSS Attack

 Comment page of sample website looks like this:

Figure 7.20 Sample web page

 Let us insert a script in URL which displays alert box.

39
 Figure 7.21 Injecting alert box script in URL

 After executing this the alert box is displayed every time the vulnerable site is
run and force the user to click ok button to view the original page.

Figure 7.22 Execution of alert box script

7.1.4 PREVENTION OF XSS ATTACK

After using encoding and escaping method in development process, the web
application escapes the vulnerable script but does not run them.
Reflected (Non-Persistent) XSS Attack
 Let us insert a script which displays text box.
 The vulnerable script gets escaped, only the content outside of the tag will be
displayed.

40
 Figure 7.23 Prevention against Reflected XSS

Stored (Persistent) XSS Attack

Persistent attack defines that the code that is going to harm the user should be
stored on the server side.
Attack Scenarios:
 Phishing Attack
 Let us insert a script which when we try to load original page gets redirected to
another page.

Figure 7.24 Injecting page redirection script

41
 The script tag gets escaped, only the content outside of the tag will be
displayed.

Figure 7.25 Prevention against Stored XSS

 Cookie Stealing
 Let us insert a script which when we try to load original page gets redirected to
attacker website with user cookie.

Figure 7.26 Injecting cookie stealing script

42
  The script tag gets escaped, only the content outside of the tag will be
displayed.

Figure 7.27 Prevention against cookie stealing

Document Object Model (DOM) based XSS Attack

 Let us insert a script in URL which displays alert box.

Figure 7.28 Injecting alert box script in URL

43
 The script tag which is given in the URL gets escaped, only the content outside
of the tag will be displayed.

Figure 7.29 Prevention against DOM based XSS

44
7.2 SAMPLE CODING
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<?php
$db=new mysqli("localhost","root","","db3");
?>
<style>
th{
text-align:center;
font-weight:bold;
font-size:20;
}
td{
text-align:center;
font-size:20;
}
body{
background-image:url("../image/ss.jpg");
background-repeat:no-repeat;
background-size:cover;
font-family: 'Montserrat', Arial, Helvetica, sans-serif;
}
#feedback-page{
text-align:center;
}
#tab1{
background: linear-gradient(45deg, #c0c0c0 0%, #E0DCDC 50%, #DBDBDB 100%);
width:80%;
}
45
#form-main{
width:80%;
float:left;
padding-top:0px;
}
#form-div {
background-color:rgba(72,72,72,0.4);
padding-left:45px;
padding-right:35px;
padding-top:15px;
width: 325px;
height:65%;
float: left;
left: 85%;
position: absolute;
margin-top:5px;
margin-left: -260px;
border-radius: 7px;
}
.montform .feedback-input {
color:#3c3c3c;
font-family: Helvetica, Arial, sans-serif;
font-weight:300;
font-size: 18px;
border-radius: 0;
line-height: 20px;
background-color: #fbfbfb;
padding: 10px 10px 10px 40px;
width:100%;
box-sizing: border-box;
border: 3px solid rgba(0,0,0,0);
}
.montform .feedback-input:focus{
background: #fff;
46
border: 3px solid #3498db;
color: #3498db;
outline: none;
padding: 13px 13px 13px 54px;
}
.montform #name{
background-image: url("https://cdnjs.cloudflare.com/ajax/libs/foundicons/3.0.0/svgs/fi-
address-book.svg");
background-size: 30px 25px;
background-position: 11px 8px;
background-repeat: no-repeat;
}
.montform #name:focus{
background-image: url(https://cdnjs.cloudflare.com/ajax/libs/foundicons/3.0.0/svgs/fi-
address-book.svg);
background-size: 30px 25px;
background-position: 8px 5px;
background-position: 11px 8px;
background-repeat: no-repeat;
}
.montform #email{
background-image: url(https://cdnjs.cloudflare.com/ajax/libs/foundicons/3.0.0/svgs/fi-
mail.svg);
background-size: 30px 25px;
background-position: 11px 8px;
background-repeat: no-repeat;
}

.montform #email:focus{
background-image: url(https://cdnjs.cloudflare.com/ajax/libs/foundicons/3.0.0/svgs/fi-
mail.svg);
background-size: 30px 25px;
background-position: 11px 8px;
background-repeat: no-repeat;

47
}
.montform #comment{
background-image: url(https://cdnjs.cloudflare.com/ajax/libs/foundicons/3.0.0/svgs/fi-
pencil.svg);
background-size: 30px 25px;
background-position: 11px 8px;
background-repeat: no-repeat;
}
.montform textarea {
width: 100%;
height: 100px;
line-height: 150%;
line-spacing: 60px;
resize:vertical;
}
.montform input:hover, .montform textarea:hover,
.montform input:focus, .montform textarea:focus {
background-color:#e6e6e6;
}
.button-blue{
font-family: 'Montserrat', Arial, Helvetica, sans-serif;
float:left;
width: 100%;
height:50px;
border: #fbfbfb solid 2px;
cursor:pointer;
background-color: #3498db;
color:white;
font-size:20px;
padding-top:14px;
padding-bottom:14px;
transition: all 0.3s;
align:center;
margin-top:-4px;
48
font-weight:300;
}
.button-blue:hover{
background-color: rgba(0,0,0,0);
color: #0493bd;
}
.montform .submit:hover {
color: #3498db;
}
.ease {
width: 0px;
height: 74px;
background-color: #fbfbfb;
transition: .3s ease;
}
.submit:hover .ease{
width:100%;
height:40px;
background-color:white;
}
@media only screen and (max-width: 580px) {
#form-div{
left: 3%;
margin-right: 3%;
width: 80%;
margin-left: 0;
padding-left: 3%;
padding-right: 3%;
}
}
</style>
</head>
<body><div align="right"><font size="5"><a href="../first.php"
class="c"><b>HOME</b></a></font></div>
49
<h1> <center>PREVENTION OF STORED XSS</center></h1>
<h3 align="right">COMMENT
PAGE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</h3>
<div class="container">
<div id="form-main">
<div id="form-div">
<form class="montform" id="reused_form" method="POST" >
<p class="name">
<input name="Name" type="text" pattern="[a-zA-Z.]+([ ]?[a-zA-Z]+)*"
class="feedback-input" required placeholder="Name" id="name" /></p>
<p class="email">
<input name="email" type="email" name="email" required class="feedback-input"
id="email" placeholder="Email" />
</p>
<p class="text">
<textarea name="comment" class="feedback-input" id="comment"
placeholder="Message"></textarea>
</p>
<div class="submit">
<button type="submit" name="add" class="button-blue">SUBMIT</button>
</div>
</form>
</div>
</div></div>
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
<br><br><br><br><br>
<?php
if(isset($_POST["add"]))
{
function escape($comment)
{
$comment=htmlspecialchars($comment,ENT_QUOTES,'UTF-8');
return filter_input(INPUT_POST,'comment',FILTER_SANITIZE_STRING);

50
}
$msg=escape($_POST["comment"]);
$name=filter_input(INPUT_POST,'Name',FILTER_SANITIZE_STRING);
$email=filter_input(INPUT_POST,'email',FILTER_SANITIZE_EMAIL);
$sq="insert into student6(Name,email,comment) values ('$name','$email','$msg')";
if($db->query($sq)){
echo "<center><b><font size='4'>Your comment is submitted
successfully</font></b><br><br></center>";
}
else{
echo "<center><b><font size='4'>Your comment is not
submitted</font></b></center>";
}
}
$s= "select * from student6";
$res=$db->query($s);
if($res->num_rows>0)
{
echo "<CENTER><table id='tab1' border='2' bgcolor='transparent' cellspacing='0'
cellpadding='2'></CENTER>";
echo "<tr><td colspan='4'><center><b>COMMENTS</b></center></td></tr>";
echo "<tr><th>Date</th><th>Name</th><th>E-mail
Id</th><th>Comments</th></tr>";
$i=0;
while($r=$res->fetch_assoc()){
$i++;
echo
"<tr><td>{$r["datetime"]}<td>{$r["Name"]}</td><td>{$r["email"]}</td><td>{$r["co
mment"]}</td></TR>";
}
}
?>
</body>
</html>

51
 CHAPTER 8
TESTING
8.1 SYSTEM TESTING
Software will undergo many changes after it is delivered to the user. Because
of many errors, performance enhancements and change to new environments.
System testing is the stage of implementations, which is aimed at ensuring that the
system works accurately and efficiently before live operations commences. Testing
is vital to the success of the system. The candidate system is subject to a variety of
tests. Data prepared for the purpose of testing is called test data. Testing is the
process by which the programmers generate a set of test data, which gives the
maximum probability of finding all types of errors that can occur in the software
and the following steps has been performed.
 Unit Testing
 Integration Testing
 Validation Testing
 Output Testing
 User acceptance Testing
8.1.1 UNIT TESTING
Unit testing comprises generally of elements tested done by a developer. Each
developer or development team will perform its own unit testing. This testing is
carried put during programming stage itself. In this step each data has been tested
for parallel to its development and the uncovered errors were corrected.
8.1.2 INTEGRATION TESTING
Integration testing is a systematic technique for constructing tests to uncover
errors associated within the interface. It comprises two or more developers or
development teams combining the programs to determine how they work together.
In this testing the reporting components were integrated with the rest of the

52
application and tested to ensure that the whole system worked correctly. The report
components were loaded into the system and run through the application the reports
generated from the application were then verified.
8.1.3 VALIDATION TESTING
Validation testing is where requirements established as a part of software
requirements analysis is validated against the software that has been constructed.
This test provided the assurance that the software meets all functional, behavioral
and performance requirements. The rules generation form on the system has sent
test data for the reports along with the expected output. The values for the report
input parameters were specified and the expected report data were sent in PDF
format.
8.1.4 OUTPUT TESTING
After performing the validation testing, the next step is the output testing of
the enhanced system. No system could be useful if it does not produce the required
output in the required format. The output generated by the system are tested
according to the users requirement. During output testing the user requires some
new report layout changes. These changes were done and tested before the final
delivery of the system.
8.1.5 USER ACCEPTANCE TESTING
User acceptance testing comprises a completed and successful end to end
system test with review of the results by one or more user with specific knowledge.
Users may apply a variety of validation techniques. For example: generate a report
from the new system and compare the results with the same report from the current
system, data inspection and others. Prior to this testing the system was delivered to
the client along with the steps for implementation. In user acceptance testing the
system was run in the client environment by the actual system users. The users were
allowed to test the system and raise any issues for a specific period after which the
system is assumed to be complete and error free.
53
8.2 BLACK BOX TESTING
Black-box testing is a method of software testing that examines the
functionality of an application based on the specifications. It is also known as
Specifications based testing. Independent Testing Team usually performs this type
of testing during the software testing life cycle. This method of test can be applied
to each and every level of software testing such as unit, integration, system and
acceptance testing.
There are different techniques involved in Black Box testing process
1. Equivalence Class
2. Boundary Value Analysis
3. Domain Tests
4. Orthogonal Arrays
5. Decision Tables
6. State Models
7. Exploratory Testing
8. All-pairs testing
8.3 WHITE BOX TESTING
White box testing is a testing technique that examines the program structure
and derives test data from the program logic/code. The other names of glass box
testing are clear box testing, open box testing, logic driven testing or path driven
testing or structural testing. White Box Testing Techniques includes
 Statement Coverage - This technique is aimed at exercising all
programming statements with minimal tests.
 Branch Coverage - This technique is running a series of tests to ensure
that all branches are tested at least once.
 Path Coverage - This technique corresponds to testing all possible paths
which means that each statement and branch is covered.

54
 CHAPTER 9
CONCLUSION AND FUTURE WORK
9.1 CONCLUSION

In this project, we have implemented the various attacks possible with XSS
vulnerability in web applications and its prevention measures. Result of encoding
and escaping Technique before and after the implementation of respective
countermeasures reveal that if the web applications are developed with security in
mind from the beginning itself, then many attacks on web applications can be
avoided almost without any extra effort and time.

55
9.2 FUTURE ENHANCEMENT
The proposed solution is found to be very effective by the experimental
results. But we can never be completely sure that no one can break our filter.
Attackers always find their ways to break application security. If we really want to
make a hard-to-crack XSS filter, we have to analyze more on all XSS patterns and
then we can use our prevention technique efficiently. After efficient analysis and
using better prevention technique, we can stop or fix the dangerous XSS web
application vulnerabilities. We should not depend on a single technique or
approach, we should use a multilayer security and also we should have focused on
initial level security. Future work is based on how to construct a website which is
not vulnerable to such attacks or how to deal with the sites which are already being
attacked with Cross-Site scripting attacks.

56
REFERENCES
[1] Galan E, Alcaide A, Orfila A, Blasco J, "A multi-agent
scanner to detect stored-XSS vulnerabilities" in IEEE International
conference for internet technology and secured transactions. pp37-
48.
[2] Wang Y, Li Z, Guo T, “Program slicing Stored XSS Bugs in
Web Application”, in 2011 IEEE fifth international symposium on
theoretical aspects of software engineering. pp 191-194
[3] R. Wang, X. Jia, Q. Li, S. Zhang, “Machine learning based
cross site scripting detection in online social network” in 2014 IEEE
internationsl conference in high performance computing and
communications on cyberspace safety and security. Pp 823-826..
[4] I. Parameshwaran, E. Budianto, S. Shinde, H.Dang, A. Sadhu
“Robust testing platform for Dom-Based XSS vulnerabilities” in
proceedings of the 2015 10th ACM joint meeting on foundations of
software engineering pp946-949.
[5] R. A. Popa, N. Zeldovich, “Automated detecting and
repairing Cross Site Scripting vulnerabilities through unit testing” in
IEEE Symposium on Security and Privacy, IEEE Computer Society,
2013.
[6] T. Qustin, E.Larson, and D. Ernst, “Model checking for the
defense against Cross site scripting attacks” computer, vol. 35, no.2,
pp 59-6, feb 2002.

57