COVER PAGE

UNIVERSITY OF ZIMBABWE

A DISSERTATION SUBMITTED IN PARTIAL FULFILLMENT OF THE HONORS IN

BUSINESS STUDIES AND COMPUTING SCIENCE DEGREE (HBSCT4)

SECURITY INTELLIGENCE ANALYSIS IN WEB APPLICATIONS

SUBMITTED BY

GODWIN TIZWI

R129815M

SUPERVISED BY
MR ZANAMWE
FACULTY OF COMMERCE
BUSINESS STUDIES DEPARTMENT

i
DECLARATION

This is meant to certify that this dissertation project entitled ‘Security Intelligence Analysis In
Web Applications’ which is submitted in partial fulfillment of the requirements for the degree
programme Honors in Business Studies and Computing Science (HBSCT) by the University
of Zimbabwe constitutes of only my original work and due acknowledgments have been
brought forward in the text to all the materials used.

Name of Student : Godwin Tizwi Date………………………………………..

Supervisor : Mr. Zanamwe Date………………………………………..

ii
ABSTRACT

The concept of security in web applications is not new. However, it is often ignored in the
development stages of the web applications. Being wide and spread across different domains,
it is challenging to come up with a security solution that works for all web applications.
Moreover, developers are more inclined to produce working features for the applications in the
rapid development approaches that are chosen, than providing security for the code and often
do not practice secure coding. Therefore, countless web applications are launched with security
vulnerabilities which manifest later in their life cycle. Integrating security features should be
part of the development process for these web applications to prevent unwanted attacks. Along
with cross-site scripting, injection attacks and resource alterations; code tampering on the client
side is a serious security risk for web applications. Without practicing secure coding and having
an integrity verification system in place, it is difficult to defend these unwanted attacks

ACKNOWLEDGMENTS
I would like to thank my supervisor, Mr. N. Zanamwe, for his guidance and support during my
graduate career. I am forever in his debt for affording me this opportunity. I would also like to
thank my college members for their comments and guidance. Additionally, I would like to
thank my good friends Pride Mavesere and Delight Nyauta for their unwavering support, which

iii
has been of great importance to me. I would also like to thank my parents and my siblings for
their unyielding love and support throughout the year.
Moreover, I would also like to express my deepest gratitude and appreciation to my wife
Tapiwa Tizwi and my beloved son Tinashe Tizwi for giving me space to do my research
without any form of disturbances.

TABLE OF CONTENTS
COVER PAGE............................................................................................................................ i
DECLARATION .......................................................................................................................ii
ABSTRACT ..............................................................................................................................iii
ACKNOWLEDGMENTS ........................................................................................................iii
CHAPTER ONE: INTRODUCTION OF THE STUDY........................................................... 1

iv
 1.1 STATEMENT OF THE PROBLEM ............................................................................... 1
1.2 PURPOSE OF THE RESEARCH ................................................................................... 2
FIGURE 1.1 ....................................................................................................................... 2
1.3 SIGNIFICANCE OF THE RESEARCH ......................................................................... 2
1.4 RESEARCH AIM ............................................................................................................ 3
1.5 RESEARCH QUESTIONS ............................................................................................. 3
1.6 RESEARCH OBJECTIVES ............................................................................................ 3
CHAPTER 2: LITERATURE REVIEW ................................................................................... 4
2.1 INTRODUCTION TO WEB APPLICATIONS .............................................................. 4
FIG. 2.1. WEB APPLICATION ARCHITECTURE......................................................... 5
2.2 WEB APPLICATION SECURITY ................................................................................. 5
2.2.1 WEB APPLICATION ATTACKS ............................................................................... 6
2.3 CLIENT SIDE SECURITY ............................................................................................. 8
2.4 RELATED WORK ........................................................................................................ 10
2.4.1 EXISTING PROBLEMS IN PURELY SERVER SIDE MECHANISMS ................ 10
2.4.2 EXISTING WEB APPLICATION SECURITY MECHANISMS ............................. 11
2.5 SUMMARY ................................................................................................................... 14
CHAPTER 3: MATERIALS AND METHODS ..................................................................... 16
3.1 INTRODUCTION ......................................................................................................... 16
3.2 RESEARCH DATA....................................................................................................... 16
3.2.1 PRIMARY DATA ...................................................................................................... 16
3.2.2 SECONDARY DATA ................................................................................................ 17
3.3 EXPERIMENTAL SETUP ............................................................................................ 17
3.3.1 SELECTION OF TOOLS FOR EVALUATION ....................................................... 17
3.3.1.1 VEGA ...................................................................................................................... 18
3.3.1.2 ZED ATTACK PROXY .......................................................................................... 18
3.3.1.3 SKIPFISH ................................................................................................................ 18
3.3.1.4 JBROFUZZ .............................................................................................................. 19
3.4 EXPERIMENTAL ENVIRONMENT........................................................................... 19
3.5 EVALUATION CRITERIA .......................................................................................... 19
FIG 3.5 ............................................................................................................................. 20
3.6 WORKING PRINCIPLE OF THE PROPOSED APPROACH .................................... 22
3.7 SECURITY POLICIES ................................................................................................. 22
3.7.1 SECURITY POLICIES FOR ATTACK PREVENTION .......................................... 22
TABLE. 3.7.1. TYPES OF ATTACKS TO POLICY MAPPING .................................. 23
3.8 SUMMARY ................................................................................................................... 25
CHAPTER 4 RESULTS AND DISCUSSION ........................................................................ 26

v
 4.1 INTRODUCTION ......................................................................................................... 26
4.2 PRE-INTEGRATION PROTECTION EVALUATION ............................................... 27
FIG. 4.1. ATTACK PREVENTION RATE PRIOR TO INTEGRATION OF THE
APPROACH. ................................................................................................................... 28
4.4.2 PROTECTION EVALUATION WITH SECURITY POLICIES .............................. 28
FIG. 4.2. ATTACK PREVENTION RATE AFTER THE INTEGRATION OF THE
APPROACH. ....................................................................................................................... 29
4.5 DISCUSSION ................................................................................................................ 29
CHAPTER 5: CONCLUSIONS AND RECOMMENDATIONS ........................................... 31
5.1 SUMMARY ................................................................................................................... 31
5.2 LIMITATIONS .............................................................................................................. 31
5.3 RECOMMENDATIONS ............................................................................................... 32
REFERENCES .................................................................................................................... 33

vi
CHAPTER ONE: INTRODUCTION OF THE STUDY

There has been a phenomenal rise in the use of web-based applications over the last decade [3].
Applications such as e-banking, e-commerce, online blogs, and social networking sites have
become a common platform for transmitting information and delivering online services.
Although web applications offer great digital experiences, only the secured ones can deliver
the services safely. Since these applications deal with sensitive data and operations, for
attackers they are an easy, lucrative, and potential target to acquire confidential data, earn
monetary gain, and perform several unlawful activities. Nowadays, web application security is
one of the pertinent issues in information security due to the continuous growth in the number
of web attacks. According to the Internet Security Threat Report (ISTR) 2017, more than 76%
of the scanned websites were found vulnerable [2]. A survey reports that 60% of the hacker
attacks either targeted the web applications or utilized them as the attack vectors. Some
illegitimate actions that unauthorized individuals or computer systems may wish to perform
might be expected, such as improperly accessing the banking details, initiating unauthorized
transactions, or modifying online resources for their own goals rather than those of the operator
of the resources, such as defacing an online presence; stealing money, goods or information;
sabotage; or performing other illegitimate actions. Owing to the fact that these applications are
easy to develop and deploy, people are using them for both personal and professional reasons.
However, information security and privacy issues are not always taken into consideration
properly when these applications are developed. Hence, they fall victim to cyber-attacks and
can be prone to giving out valuable information. The most vulnerable among these are e-
businesses and applications that deal with a user's personal information such as credit card
information and insurance records. According to Verizon's 2018 data breach report, 76% of
web attacks had a financial or espionage motive [4]. It is mostly after a security breach occurs,
when security becomes a priority. Therefore, it is becoming increasingly important to develop
web applications that have proper security measures in place and protect the applications that
have already been deployed.

1.1 STATEMENT OF THE PROBLEM

The researcher seeks to examine strategies of maximizing security in web applications. The
researcher is interested in securing web applications against some named threats by providing

1
developers guideline to follow. From the background, it can be noted that there are a number
of attacks to web applications. The researcher believes these attacks can be minimized if proper
security codes are implemented within the web applications code. Thus the researcher is more
interested with improving security with secure coding practices.

1.2 PURPOSE OF THE RESEARCH

In the past few years, businesses and establishments have invested in cyber security and anti-
malware software. This has shown a rise in the number of security personnel maintaining the
network and firewalls of a particular institution [40]. Security has been taken into consideration
more and more in the development stages of a web application [41]. Web applications can be
attacked on both the client side and the server side including any third parties that are involved
in the process of getting the information to the client's web browser. Even though all web
applications should have security in place on both ends, it is not always the case. As can be
seen in the research literature, more often than not security is enhanced on the server side while
keeping the client side open to threats [42]. Client side data cannot be trusted and should always
be scrutinized before usage. Security measures such as cryptographic algorithms can be put in
place to fend off attackers. Due to increased number of these cyber-attacks, the protection of
information and communication has become of major concern. For these reasons the researcher
has come up with this paper to explore current threats to the security of web applications,
security strategies in use and devise new strategies. This research will result in strategies that
will enable maximum web security. Figure 1.1 illustrates a high-level work flow of our
approach. Our approach takes in web applications in order to secure it. To achieve this goal, at
first, guidelines are provided for integrating security policies to the web applications.

Integrate
Security Modified Secure
Web application
Polices Web Application

FIGURE 1.1

1.3 SIGNIFICANCE OF THE RESEARCH

2
In embracing technology progress, web application security must form an integral and
indivisible part of the process. According Positive Technologies there has been an increase in
the threats attacks to different entities with government, banks, healthcare and manufacturing
not spared [4]. Thus it has been noted with the researcher as an important area of focus to
research on in order to prevent losses that may be incurred with these threats.

1.4 RESEARCH AIM

● To examine current web applications threats

● To improve the security of web applications.

1.5 RESEARCH QUESTIONS

This paper will respond to the questions below:

1. What are the web application security issues?
2. Which web application security strategies that are currently used?
3. What new policies that can be introduced to improve web applications security?

1.6 RESEARCH OBJECTIVES

● To exploit current web application threats

● To examine security practices used in web applications
● To develop security policies for web applications.

3
CHAPTER 2: LITERATURE REVIEW

2.1 INTRODUCTION TO WEB APPLICATIONS

Literature review serves as a crucial approach to conceptualize the research areas and survey
and synthesize prior researches (Saunders, Lewis & Thornhill, 2009, p.58). Web applications
can have different definitions depending on different stakeholders. This is not surprising since
it bears similarities to desktop applications and websites. Also, depending on if someone is an
end-user or a developer, the way web applications present themselves can be very different. To
understand the inner workings of a web application, at first, we have to understand the basic
differences between a web application and a desktop application. Desktop applications, for
example, an image viewer or a file reader resides entirely on the PC. They are installed and run
on the desktop and other than the occasional update through the Internet, the code for these
applications can be run independently and offline. This brings us to the major difference with
web applications. Popular web applications that we frequently use are email applications (i.e.,
Outlook mail, Gmail), instant messaging applications, online shopping applications among
others. These applications do not reside on our PCs but rather on web servers that we access
over the Internet. Web browsers serve as the portal through which we can access and use web
applications. Moreover, the updates for web applications do not happen on the user end, rather
web applications are updated on the server and users get access to it through their browsers.

Web applications are also confused with websites and sometimes the words are wrongly used
interchangeably by users. From a developer’s perspective, there are a few differences that can
be used to separate one from the other. In essence, websites can be made of a single page built
with HTML, CSS and JavaScript that remain constant with time. These websites might have
no interaction with the user. A website does not require a database or even a programming
language to build it. Web applications on the other hand are dynamic applications that modify
their outputs according to user interactions. They deal with user inputs and data processing and
have a database in the back end. An online retail web application will have a store front for the
user to see on their browser, a form that the user can fill up to send to the server, and a database
that stores inventory and client details. Different programming languages such as PHP, Ruby,
Python and frameworks such as Rails are used to build and operate a web application. These
differences are important when it comes to securing a web application. To understand the
constraints of web application security we have to understand how a web application operates.

4
For this, I refer to Figure 2.1 which shows a deployment diagram for a typical three-tier web
application. Although there are other architectural models that can be used, this figure gives us
a basic view of the different layers and stakeholders involved in a web application. It can be
noted that our approach does not change for different architectures as long as the web
applications in question have separate client sides and server sides.

FIG. 2.1. WEB APPLICATION ARCHITECTURE.

A web application is deployed on a web server which has different files and code needed for
the application. The database is usually stored on a separate server and connected to it. In this
three-tier architecture, we have clients or the end users, web servers, and a back-end database
system. The clients can get access to web applications through their web browsers once it has
been served. Each part of this system has security challenges that have to be dealt with. The
next section discusses some of these security issues in more detail.

2.2 WEB APPLICATION SECURITY

The security of web applications has been a constant source of concern for web application
developers and their clients. Attacks on web application client sides are far more prevalent than
before and the security systems put in place are having a hard time keeping up with the

5
nontrivial attacks. Till date, most web application developers are also in charge of the security
aspect of their applications. Even though most of the prevalent attacks on web applications
have well known solutions, they are not implemented by developers during the development
of the application. There is also the added fear of weighing down the application with too many
security features, therefore making it less responsive. However, that has not stopped
researchers and security analysts from working for solutions for these attacks. There are
recommendations circulated by researchers working to provide security to web applications for
specific attacks and vulnerabilities. Communities such as OWASP (Open Web Application
Security Project) and CWE (Common Weakness Enumeration) are acting as platforms where
researchers and professionals come together to provide information about best practices when
it comes to secure coding and securing web applications (OWASP 2018).

2.2.1 WEB APPLICATION ATTACKS

In regards to web application attacks, at first, I have highlighted attack types from OWASP
Top 10 2019 list of most prevalent attacks [2]. They are SQL injection attacks and cross-site
scripting attacks (XSS). Along with these attacks, I aim to prevent resource alterations.
Injection attacks have been the top attack type in the OWASP list for past several years. It is
the first type of attack that is used when an application is targeted by miscreants. The purpose
of this attack is to provide inputs to the application that can cause unexpected responses to
assist the attacker. If the data provided to the application is used without sanitizing or filtering,
this can lead to an injection attack. Not removing ambiguity in user queries (escaping) can also
cause injection attacks. SQL, NoSQL and OS injection attacks are some of the most common
types of attacks. To prevent these attacks, especially SQL injection attacks, the first line of
defense is to always check and filter user inputs. Input sanitization and output validation are
key factors in keeping a web application secure. OWASP also recommends using client side
input validation by utilizing a white list along with server side input validation. Context aware
escaping also helps prevent injection attacks.

A web application deals with large amounts of information both private and public when it
operates. Some of this data might be sensitive such as keys that are exchanged, challenges that
are sent in different protocols and passwords and credentials that are saved. This can also
include vulnerable code on the client side especially when it is used for security reasons. If
sensitive data in web applications are not stored or transmitted properly keeping security in

6
mind, it can fall into the wrong hands leaving the application and its users vulnerable to attacks.
This is why proper encryption need to be put in place when dealing with data

A prevalent attack our approach aims to prevent is the cross-site scripting (XSS) attack. This
attack happens due to vulnerability in web applications when they allow unclean and data not
validated code to appear in their output. Taking advantage of this oversight, the attacker can
execute malicious scripts into a web application and steal private information through cookies,
among other things. Although strict server side security is enough to prevent most XSS attacks,
it does not include all types of this attack. Without client side security functions, not all XSS
attacks can be prevented. To analyze the prevention methods for XSS attacks, we have to
understand different types of XSS attacks. The three main types of XSS attacks are persistent
XSS attacks, reflected XSS attacks and DOM-based XSS attacks (where DOM stands for
Document Object Model). For all three types of these attacks, the attacker injects a malicious
payload into a web application but uses different ways and resources to do so. Among these,
the persistent attack is the most common attack. Here, a web application is injected with a
malicious string with the use of a form on the web application. The attacker sends the malicious
string as a response on the form and it gets stored in the web application's database. When a
user requests a page, the malicious string can be sent over as an output. By clicking on this
link, the victim's browser would execute the script and this would send private information
including the victim's cookies to the attacker's server.

The next kind of XSS attack is the reflected attack. In this instance, the attacker tricks the user
into requesting a malicious URL from the web application. When the web application responds,
it sends the malicious string URL. This executes on the user's browser and sends the
confidential information and cookies to the attacker's server. The third type of attack that
requires client side security is the DOM-based XSS attack. Here, the malicious code is actually
the client side code and not the server side code. In this type of attack, since the web application
is not checking the user inputs for safety, the malicious script is executed after the page is
loaded. This is different from the last two attacks. In those attacks, the malicious script is
executed when the page is loading. The way this attack works initially is similar to the first two
as the attacker makes use of a malicious URL and tricks the user into requesting it. However,
in this case, the malicious script is only inserted into the page after the page's script is executed.
Then, the user's browser executes the malicious script and the attacker receives the victim's

7
information and cookies. In the first two attacks, if the server-side code was not vulnerable, the
attacks could have been prevented.

However, that is not the case for DOM-based XSS attacks. Resource alteration occurs when
servers and Content Delivery Networks (CDNs) fail in delivering scripts and stylesheets in
their original state. These resources get altered by the attackers supplying malware. To keep
the web applications secure, care has to be taken to check whether a content that is asked for is
actually what is presented. To verify that there needs to be a known good state saved
beforehand. This has to be kept in an unalterable state or obscured from view. Cryptographic
measures have been of great use in this regard. Having a hash value of a known good state to
compare with during runtime assists in proving no alterations have happened. Our approach
delves into solving this problem as well.

2.3 CLIENT SIDE SECURITY

A client-server themed web application is usually multitier and spreads across multiple
domains. However, more often than not security systems are placed on the server side leaving
the client side with vulnerabilities [17]. The security measures such as cryptographic
algorithms, user verifications and session validations can be changed by attackers at runtime
as well .Moreover, there are specific attacks for example XSS attacks that are targeted towards
taking advantage of a client side vulnerability. Therefore, without proper policies to maintain
the security of the client side, web applications can and will be compromised. In terms of
security, the most important issue to acknowledge is that client side data should always be
inspected both before and during usage.

To put things into perspective, we now see web applications updating their pages without
communicating with the server. The need to remain fast paced has increased the pressure for
data to be generated on the go. In most cases, JavaScript is generated on the client side at
runtime. This can happen after an AJAX (Asynchronous JavaScript and XML) request and can
put the web application in danger if the content does not go through a security check. This
increases the room for vulnerabilities in the client side code [18]. This can also happen if the
client side code includes unsafe user inputs in a DOM update after a page is loaded. These
practices can lead to an attack even if the server side code is secure. Prevention methods for
these attacks are mostly targeted for the server. Encoding, sanitization and validation of the

8
inputs are some of these methods. However, they can be used to secure both ends if dealt with
intuitively as I present. Since inputs taken from the user are not to be trusted, there has to be
measures put in place to check for safety and vulnerability. However, we also need to take into
consideration where the inputs have been entered on the page. This brings up the concept of
context in a web application. In web applications, context refers to when and where user inputs
are taken. This has to be taken into account when checks are performed to ensure that the inputs
are safe to use. A check for a JavaScript value is different from a check for a URL query or a
HTML element, depending on the context of how it is entered. Here, if a user input is used
without sanitization, the attacker's job would be to end the context by using the closing
delimiter (e.g., commas, semicolons, quotes, and braces) and inserting the malicious payload.
Having quotation marks in the output of the web application makes it vulnerable to a type of
attack in a certain context. Therefore, removing them before they are sent over should make
the page less vulnerable. However, if the delimiter is different for another context, this solution
fails. This is taken into account in our proposed solution.

When it comes to access control on web pages, the most widely used policy is the Same-Origin
Policy (SOP). According to its implementation, SOP requires that JavaScript can only acquire
information about iframes and properties of windows if their origins are the same as the page
containing the script. This implementation varies from browser to browser which is one of the
first challenges in implementing this policy. An origin is defined by a protocol, a domain and
a port of an URL. This definition holds true for most browsers except Internet Explorer, where
an origin does not require port information. In other browsers, there remain dissimilarities in
the implementation of the SOP. In Internet Explorer and Opera browsers, a JavaScript file can
access other local files through DOM by the use of the “file" protocol. However, this is not the
case in most other browsers. This creates inconsistencies when using SOP as the primary
security policy against prevalent attacks [15] .Moreover, it has also been brought up in several
research experiments that SOP does not provide adequate leakage prevention for sensitive
information. If a malicious JavaScript can get access to the information, it can send this
information to other remote servers. This can lead to cookie-stealing, location hijacking, history
sniffing, and behavior tracking. The focus of a security solution therefore needs to be consistent
across browsers and also needs to include security policies that can deliver coverage for
different attack scenarios. Another issue with client side security is the alteration of JavaScript
files during runtime. Even after following secure coding practices, some attacks might be
difficult to thwart. Therefore, it is essential for the security of the application that JavaScript
9
files and their functions are tracked and verified. The verification should be done repeatedly
and in a way that is not visible or predictable to the attacker. To ensure that no changes have
been made to the code, we can check the integrity of the files and functions. This can be
accomplished using cryptographic methods, such as hash functions. Most developers choose
to have a trusted version of the file on the server for verification. I will discuss why that is an
issue in the next section. The client side files need to be tracked and checked for changes during
runtime. This creates a tough problem to address as everything on the client side is visible to
the attacker and debugging is an option. To counter this problem, I have to come up with an
approach that is able to keep track of the client side code and notify the user if any content has
been changed. Since it will be on the client side, the implementation details will have to be
obfuscated to avoid tampering. The security features of the web application can therefore be
secured using this verification system.

2.4 RELATED WORK

Research has been done for defending web applications from different angles. However, most
of these works are for prevention and detection of attacks and blackbox testing of
vulnerabilities [19]. Web application firewalls (WAFs) are promising as primary defense
mechanisms for web applications. They depend on anomaly detection techniques to protect
web applications but do not always provide separate client side mechanisms against named
attacks (W.robertson etal 2006). Moreover, WAFs can be bypassed by knowledgeable intruders
which is why there needs to be a system in place on the web applications. To detect and protect
web applications from vulnerabilities, a significant amount of research has focused on static
and dynamic analysis of the application code. These solutions can be used periodically by the
developers to check for vulnerabilities in the web application and make changes accordingly.

However, these would not offer runtime protection of the client code. Moreover, some
solutions require that policies to check for vulnerabilities must be specified in a specialized
language, which may not be developer-friendly [11].

2.4.1 EXISTING PROBLEMS IN PURELY SERVER SIDE MECHANISMS

A crucial part of protecting the client side is verifying untrusted content on the web application.
Most defense mechanisms in the research literature focus on server side mechanisms only. This

10
is mainly due to the fact that servers are more protected by themselves and have more
operational power. Security policies are enforced on the servers for detecting and dealing with
attacks. The difficulty with these solutions is that they depend heavily on the fact that
processing on the client end is in sync with the server. This assumption has been proven to be
costly and dangerous on several occasions. Since browser behavior changes according to
browser implementations, servers cannot predict client side processing and it is not always
possible to mimic results(Jason Bau 2010). Even then, server side defense mechanisms are used
to specify and enforce security policies for the browser (F. Ricca and P. Tonella 2011). Without
real-time cooperation and assimilation from both ends, these solutions do not meet their goals.

2.4.2 EXISTING WEB APPLICATION SECURITY MECHANISMS

Recent work on web application security involve end-to-end security schemes and protection
of the web application through code instrumentation [32]. Web application scripts are among
the most vulnerable parts of a web application. To get information about what script is used,
where it is from and from where it is loaded, web clients need to be examined. Web application
defenses, however, do not always come from the client end since it is vulnerable by itself. Fine-
grained authentication and verification systems are implemented on the server side as
mentioned above. However, purely client side defense mechanisms do exist that enforce
policies without the help of the server [9]. Detection of malicious code is a mechanism that can
be successfully carried out on this side. Another method that is used to enhance security is code
instrumentation. Browser-based attacks rooted in JavaScript are thwarted by instrumentation
techniques where the code is rewritten according to given policies. This is similar to
information flow security techniques where the flow of processes in the web application is
protected through tracking and maintaining type systems. The problem with some of these
techniques is the high overhead cost of integration as rewriting code or tracking the flow of
information both require a system in place that has to be programmed beforehand by developers
[8]. For preventing SQL injections through user inputs, researchers have proposed many
defense mechanisms and frameworks. Here, I discuss some of the techniques presented in the
recent literature.

Blackbox testing and code checking have been the front runners when it comes to detecting
SQL injection attacks among researchers. Although blackbox testing does not require
knowledge of the code base, like all black-box approaches, it does not assure completeness

11
while checking for vulnerabilities [33]. Combined static and dynamic analysis as seen in
AMNESIA employs model-based code checking to detect and prevent SQL injection [14]. This
technique uses static analysis to build models of different types of SQL queries. During
runtime, AMNESIA intercepts all queries to the database and verifies them against the
statically built models. If the queries do not pass the verification test, they are prevented from
executing. The limitation with this technique is that if the primary models are not accurate, the
success rate for this approach drops significantly. If code obfuscation is used while sending in
queries, the models will not be able to identify actual attacks during runtime. SQL Guard and
SQL Check also use runtime query checks to see if they can be verified through models.

These approaches also use a secret key to delimit user inputs during parsing through the runtime
checker. Therefore, if the key is discovered, then these approaches would fail to offer security.
More recent dynamic prevention of SQL injections includes CANDID where a programmer
intended SQL query structures are learnt by the system. During runtime, CANDID dynamically
constructs the structure of the intended queries and compares them to the benign learnt ones.
This approach needs its own language and query structure for formal analysis and
transformation. It limits itself as a solution when a benign query is wrongly detected as an
attack query, if transformed improperly. This leads to other similar benign queries to be
wrongly judged. Moreover, each type of query needs to be transformed before the solution can
be used. Although the above approaches can limit the number of SQL injections, they are not
developer-friendly. The solutions provided in the above research works, are aimed at web
applications that are already deployed and needs a substantial amount of technical knowledge
and research for integration purposes.

Another way to defend the web application against attacks that is seen in recent literature is
through defensive programming. In Detection and Prevention of SQL Injection Attack a Survey
done, the authors present an approach that uses whitelists and blacklists to automate prevention
of SQL injections. This is a low cost mechanism that can check inputs against given lists and
that can be integrated by developers with minimum changes to the web application code. It
does not involve any new static or dynamic transformations. However, this procedure can lead
to cross-site scripting attacks through SQL injections. To deal with XSS attacks, further
security policies need to be put in place. In the context of cross-site scripting attacks, the
defense mechanism depends on the kind of attack.

12
For stored and reflected XSS attacks, the prevention methods are usually on the server side.
This is done by inspecting and verifying data that is exchanged between the client and the
server. Tainted flow analysis in the Perl interpreter is a popular server side defense mechanism.
Here, tainted data is marked and tracked through the program and any attempt to use it for a
critical command is aborted with an error. The commands involve modification of files,
directories, processes and invoking sub shells which are caught and terminated instantly.
Interpreter-based approaches for PHP are presented by A. Nguyen-Tuong [30]. With boundary
injection and policy generation, Shahriar et al. Swati Maurya1 present an automated framework
to detect server side XSS attacks. This framework comes with a tool to automatically insert
boundaries and generate policies for JavaServer Page (JSP) programs [31]. However, this is
still a server side mechanism and lacks the functions required to prevent client side XSS attacks.
There are some approaches similar to ours that employ defense mechanisms on the client side.
This system monitors the execution of JavaScript code and uses intrusion detection techniques
to detect malicious behavior. However, this does not ensure security against DOM-based XSS
attacks. Application level firewall keeps sensitive information from leaking by analyzing
HTML pages that have already been browsed for hyperlinks. This technique is used to prevent
XSS attacks. By analyzing HTTP traffic exchanged between the client and the server, Ismail
et al. O. Ismail and team present a way to detect XSS attacks. Even though it shows promise
against reflected attacks, it does not prevent stored or DOM-based XSS attacks[34]. Moreover,
the above approaches work with web applications that have been deployed. They do not have
separate policies for developers to follow if they do not intend to integrate the whole system.
Resource alteration can occur when files and stylesheets are hosted on third party servers and
Content Delivery Networks (CDNs). If the servers are compromised, the content delivered are
altered with malintent. To prevent resource alteration, web developers use HTTPS to ensure
that the connection between the web server and web browser is encrypted. However, that does
not ensure the integrity of the content provided. No prevention mechanism that is specific to
fighting resource alteration was found in the recent literature.

Code tampering on the client side has been addressed through information flow analysis in
recent research work. This is mostly due to the fact that it is easier to secure the server side and
provide security to the client through extension of the server side methods. JavaScript integrity
has been overlooked for document structure integrity and integrity of content caching [35].
These do not protect the client code from alteration during runtime. This has been a long
running problem in web applications. Any solution that runs security functions on the client
13
side, has to make use of the main UI thread and therefore, would slow down the responsiveness
of the application. J. Wan present a solution for verifying the integrity of application cache in
android runtime to defend it against attacks. However, similar solutions for JavaScript runtime
are not available [36]. The security mechanisms discussed here are built as separate systems
that can be used on web applications. It is not possible to implement parts of the solutions and
achieve a secure web application. Web application developers are not helped by these security
mechanisms if they do not adopt the entire system as a whole and implement it. Developers
would need to integrate entire solutions to their native code for security purposes. This
integration might even lead to bigger security holes.

The primary focus of our approach is to provide the power of attack prevention to the
developers. I present security policies derived from secure coding practices that developers can
refer to and integrate to their web applications without the need to learn about an external
approach. There is no need for integration of an analysis and transformation system. Our
approach relies on developers reevaluating and changing their coding practices to ensure more
security for their web applications in terms of SQL injection, XSS attacks and resource
alteration. In our approach, we present two security enhancing components for web
applications to protect web application client sides.

The approach that I propose is to use background threads to secure web applications. These
background threads would be responsible for lengthy computations needed to confirm code
integrity. The JavaScript feature that is used in this case is the web workers API (w3schools
2019). The worker threads run in the background while leaving the main UI thread of the web
application free to execute other files on the web application or stay responsive to the user. The
worker threads also provide entanglement in the verification process for added security. This
research uses these web workers to perform the integrity verification of the client side code for
securing the code during runtime.

2.5 SUMMARY

To date, the client side of a web application is protected through the extension of server side
mechanisms. Traffic is restricted via firewalls and proxies. However, this only takes notice of
network traffic and once traffic is allowed, the web application is at risk from exposure to
attackers. The filtering solutions that are available are limited to their customization and do not

14
provide security from a wide range of attack perspectives. This makes web application attacks
through the client side a popular and easy way to gain access and cause harm.

15
CHAPTER 3: MATERIALS AND METHODS

3.1 INTRODUCTION

In this chapter I am going to present the methods showing the general research approach to be
used. The process in which the experiments will be run and data that will be collected and how
these experiments will address each and every objective will be shown in this chapter. Again
data analysis methods used to collect data will be analyzed and presented. Later through the
chapter the validation and the summary of the chapter will be presented. It is important to note
that when presenting the aspect of web application security and integrity, we must keep in mind
the many languages, platforms, techniques, and protocols which are in use. The security
mechanisms that might work for a web application to share artwork written in PHP and
JavaScript might not work for e-business web applications written in ASP. NET. These aspects
are taken into consideration while presenting security recommendations [25] .Moreover,
thought has to be given to the development process of the application and the compatibility of
these unique security schemes [26]. As discussed previously, our approach is focused on
securing the web application against some named attacks and verifying the integrity of the
JavaScript security code during runtime. To secure the client side against third party attacks, I
propose some security policies. These policies are presented as guidelines to make web
applications secure against SQL injection attacks, cross-site scripting (XSS) attacks and
resource alterations. These policies are derived from secure coding practices present in industry
driven research [24].

3.2 RESEARCH DATA

3.2.1 PRIMARY DATA

This data is collected through survey method. This data is original in nature. This data is
collected by distributing the questionnaire & getting filled by the concerned respondents, for
this purpose, online questionnaire as well as manual method was used. Telephonic and/or
personal interview conducted with the IT industry people.

16
3.2.2 SECONDARY DATA

Secondary data is used to study the web security offered by various products of intrusion
detection available in market. Secondary data is collected from reputed journals, articles,
websites and product documentation.

3.3 EXPERIMENTAL SETUP

In this section, I present our experimental setup to acquire the comparative results. The setup
is targeted towards taking advantage of the vulnerability of the web applications. At first, our
proposed approach aims at preventing SQL injection, cross-site scripting, and resource
alteration attacks through the security policies. Our experiments emulate these attacks on web
applications. To emulate these attacks, I used several open source tools. Below, we describe
which tools were used along with why they were used to evaluate the web applications.

3.3.1 SELECTION OF TOOLS FOR EVALUATION

To run experiments and check for vulnerabilities, we choose tools to attack the web
applications. These tools are chosen based on their ability to take advantage of vulnerabilities
that might be present in the web applications and mimic attacks such as cross-site scripting,
SQL injection and code tampering. In Table 4.1, we present the tools that are used along with
their purposes. All the tools in the table are used with a specific target in mind. At first, we
check the web applications for overall security and vulnerability. This is done using Skipfish.
This report is used to review and integrate security policies for SQL injection, cross-site
scripting and resource alteration in the security policy component. Zed Attack Proxy is used
for its vulnerability reports for the same purpose. It is also utilized for fuzzing purposes.
Fuzzing is defined by the act of providing web applications with different kinds of inputs with
the intention of making it fail or crash so that vulnerabilities can be found. For fuzzing
purposes, I employ attack scripts generated by a crawler. This is done with the use of the
fuzzing tools. The tools use the scripts to create HTTP requests and records the responses for
inspection. For more detailed injection and cross-site scripting attacks, along with fuzzing,
Vega and JBroFuzz are employed.

TABLE. 3.3.1. EVALUATION TOOLS

17
 Tool Intended Use
Vega SQL injection, header injection, cross-site scripting
Zed Attack Proxy Automated scanner, passive scanner, forced browsing, fuzzer
Skipfish Security threats, vulnerability report
JBroFuzz Automated fuzzing

3.3.1.1 VEGA

This is an open source tool that is used to check for cross-site scripting vulnerabilities. It is
written in Java and has a GUI. It can be employed to scan a single web page and customized
to scan a whole web application. It presents us with a report about web application
vulnerabilities and the attacks they might succumb to. The attacks we are interested in are XSS
attacks and SQL injections [38].

3.3.1.2 ZED ATTACK PROXY

This tool is made by OWASP and it is an open source web application scanner. It is automated
to find web application vulnerabilities. It was given the second place at the Bossie awards for
the best open source networking and security software in 2015 [39]. It provides a set of manual
tools along with the automated scanning system. It is used to get reports about vulnerabilities
on the web applications.

3.3.1.3 SKIPFISH

This tool is used to check for vulnerabilities and create a report. The tool makes use of recursive
crawling and dictionary-based probes to check for security holes. It then creates a sitemap with
the active security checks. The report generated by Skipfish is used to gather data for the
comparison of prevention rates against attacks. It also supports most popular web frameworks
and mixed-technology sites which make it possible to evaluate all the open source web
applications in our repository. It has automatic learning capabilities and also makes use of
differential security checks. This makes it very useful when checking for security holes in web
applications of different functionalities.

18
3.3.1.4 JBROFUZZ

This is another tool from OWASP that is used to secure web applications. It uses fuzzing to
inspect vulnerabilities. JBroFuzz is customized for mimicking SQL injection and XSS attacks
on all the web applications. This tool is also employed to verify that the input validation and
output encoding that is integrated are up to the mark. The use of these four tools along with
manual inspection is aimed at evaluating the security policies that are integrated in the web
applications. By employing automated attacks, we are able to do an exhaustive evaluation with
possible inputs and outputs.

3.4 EXPERIMENTAL ENVIRONMENT

The environment setup for the experiments involved having the means to open, run and serve
web applications. The machine used for this experiment has a dual core intel processor with
2GB of memory. It has a 64 bit operating system with Windows 10 pro. To serve the web
applications, I make use of the xampp. I use version 3.2.2 of this web server. The web
applications are run on the machine with the help of the web server application. I visit different
parts of the web application to perform attacks and calculate the prevention rate.

3.5 EVALUATION CRITERIA

In this section, I discuss the criteria on which we are evaluating our approach. The goal of the
two components is to provide security for the web applications against prevalent attacks and
prevent changes to the code. I choose prevention against vulnerabilities as the main criteria for
the evaluation. Our experiments mimic real life attacks and the evaluation is done on the
applications based on whether they are able to prevent these attacks. The attacks that our
approach intends to protect the web application from are cross-site scripting attacks, SQL
injection attacks and resource alteration. These attacks are initiated with the tools discussed in
Section 3.3.1.

19
A proper security review consists of researching every possible aspect in which targeted system
can have weaknesses. This process can be separated into multiple smaller parts to make it more
easy to understand. In this study primary and secondary data is collected to analyze security
intelligence in web applications. Primary data is collected through survey method whereas
secondary data is collected through published and unpublished material. Experiments will be
carried to analyze the vulnerabilities of web applications. The experiments will include
penetration test. A penetration test can be described as a method to test the security of a system,
by simulating different types of attacks but without affecting in reality the resources and creates
an evaluation results to help us analyze for weaknesses. A Web Application Penetration process
involves a test or analysis of the application to discover weaknesses and vulnerabilities. If a
security issues is found, it will be showed to the user (administrator-owner) along with the
result of the impact sometimes giving as well a technical solution [27]. Some of this web
Application Penetration Testing tools includes hydra, SQLiX, Netsparker and Fiddler. These
tools help in the analysis process to determine if a specific application is vulnerable. Based on
their results we may end fixing issues related to the vulnerability of the problem itself. For
example, is possible that one domain results shows password transmitted over HTTP problems,
I will tend to find an approach and solution to this problem by creating a summary report with
the available resources and complex analysis.

Brief information about the testing tools used on this report includes SQLiX coded in Perl, a
SQL injection scanner that is able to crawl and detect SQL injection, it does identify the
backend of the database and grab function results and even execute MS-SQL queries or
commands. Netsparker is a False-positive web application security scanner tool that is free for
non-commercial use and comes with a friendly user interface. [9] Figure 3.5 shows a
screenshot of the Netsparker program running a full web application security test of one of the
selected domains for the IT Company.

FIG 3.5

20
The testing methodology was based on the following criteria.
Vulnerability summary, based on the domain we are testing the documentation include
parameters, methods, the URL (if present), and the type of vulnerability discovered and how
critical can be the issue. Vulnerability research, after an issue is presented a brief description

21
of the vulnerability is included with the impact, actions and solutions that can be consider to
resolve the problem.

3.6 WORKING PRINCIPLE OF THE PROPOSED APPROACH

The proposed approach for integrating security in web applications has two components in it.
At first comes the security policies and then the integrity verification module. The security
policies work alongside each other to provide security for the client side code and protect it
against SQL injection, XSS attacks and resource alteration attacks. The integrity verification
module consists of implementations on both client and server sides. It works during runtime to
prevent code changes on the client side. This module uses a challenge-response protocol along
with hash-based message authentication codes to ensure integrity. The security policies deal
with code security and they employ methods to ward some named attacks. The integrity
verification module confirms that the client-side code is not tampered with during runtime.
Both the components are required to confirm that the web application is secure against above
mentioned attacks.

3.7 SECURITY POLICIES

The first component in our approach is made up of several security policies that work toward
preventing attacks on web applications. These policies are derived from secure coding practices
and can be designed as guidelines that should be followed to protect web applications. They
are targeted towards specific parts of web applications. The policies are integrated in the order
that they are mentioned below. The policies deal with how data on web applications are used
and how vulnerable the applications are to the client or even an attacker. Here, we assume that
the client is benign and the attacks occur through a third party attacker. The policies proposed
are input sanitization, output validation, principle of least privilege, sub resource integrity, and
content security.

3.7.1 SECURITY POLICIES FOR ATTACK PREVENTION

Each of the security policies have specific targets it must achieve. The initial aim is to ascertain
that no user inputs can be received or sent back without going through escaping and encoding

22
mechanisms. The first two policies deal with this issue. This is essential for defense against
SQL injection and XSS attacks. Then we move on to giving and restricting access to the web
application data. To ensure that the different parts of the web applications are only given the
least amount of access it needs, we integrate a policy called the Principle of Least Privilege
inspired by OWASP [23]. This policy assists in the prevention of all three above mentioned
attacks along with any code alterations. Web applications also use scripts from third party
resources including servers or Content Delivery Networks (CDNs). If these scripts are not
checked for integrity before execution, they might be the cause of security breaches. Therefore,
we have integrated a way to confirm that all the resources used by the web application are
checked for integrity. This policy is aimed at preventing resource alterations. We have also
developed and customized a content security policy [22] for web applications. This policy
ensures that the behavior of the web application is restricted to some rules. This makes it
possible to prevent harmful changes to the application if a successful malicious injection
occurs. This aims at preventing cross-site scripting attacks. Table 3.1 presents how each of the
policies are mapped to specific attacks.

TABLE. 3.7.1. TYPES OF ATTACKS TO POLICY MAPPING

Policy Attack type

Input Sanitization SQL injection, XSS attack

Output Validation SQL injection, XSS attack

Principle of Least Privilege SQL injection, XSS attack, Resource

Alteration

Sub resource Integrity Resource Alteration

Through the enforcement of these policies, our aim is to provide a line of defense against these
attacks in web applications. Our first priority is to ensure proper input sanitization and output
validation. This will always remain the most important defense to prevent attacks. The rest of

23
the policies are customized to deal with different privileges and behaviors’ in web applications.
Working together, these policies provide a robust line of defense against attacks.

One of the main problems apparent in web applications is insufficient input sanitization. When
it comes to secure coding practices, this is the top priority in building a secure application.
Without it, the application is open to attacks such as injection attacks, cross-site scripting (XSS)
and even phishing attacks. The first security policy that is integrated into the web applications
in our repository is input sanitization. This is also because malformed inputs can cause web
applications to collapse by wreaking havoc on the security components. It can redirect user's
browser to their own malicious site, steal the user's private data and exploit cross-site scripting.
Although most approaches have server side prevention mechanisms, we are interested in
sanitizing the data submitted by the client in HTML forms and URLs. Since both SQL injection
and XSS attacks are caused by mishandling user inputs, the first policy in this component is
input sanitization.
As soon as any input is taken by the web application, it has to be checked for syntactic and
semantic relevance. There are default filters in some languages that are in use in web
applications. Frameworks such as Apache Commons Validator [21] and Django Validator [20]
are used for data type validation. However, we do keep in mind that filters can be bypassed by
intruders and there are other security policies in place if that happens. Our guideline ensures
that the length and the fields are checked for each input. We aim to deny all attempts at putting
untrusted data in HTML documents unless it is required by the application. Following our
guideline, we start with escaping HTML before inserting it into the element content and HTML
common attributes. Dynamically generated JavaScript code is treated as data value as the code
cannot be trusted.
We aim to validate all incoming responses from the web application while verifying that they
conform to certain rules and constraints. We use validate.js library to emulate primary
validations on web applications. In addition to the validators provided, we add more for the
inputs required for each web application. The most crucial ones are for username, email,
password, birthday, country, zip code, and any numerical inputs. For example, when validating
a password for user registration, our approach verifies that there is an upper case letter, a lower
case letter, an alphanumeric character, and that it is not similar to the username1. It does not
let the user proceed without meeting these constraints.
According to the latest password guidelines from the National Institute of Standards and
Technology, the above constraints for passwords need to be updated for better protection.
24
Our proposed approach uses a whitelist system to protect web applications against injection
attacks. This is different for each application according to the genre. We define the whitelist
and characteristics for each input depending on expected entries. The inputs only go through
the application if they match. The list can be hosted on the client or the server and checked for
every input. The minimum and maximum values for numerical parameters are reinforced.
There is also a check for minimum and maximum length of Strings.
Most importantly, this approach recommends using parameterized queries when querying a
database. Accordingly, each query is prepared as a SQL statement and the parameters are
passed to it later. This prevents attackers from altering a query to inject code and cause an
attack. Through the use of prepared statements, the database is able to differentiate between
code and data. Consequently, there is no need to manually escape inputs. With the use of
parameterized queries, there are also fewer String concatenations and smaller Strings sent back
and forth between the client and server. This is the leading option for the prevention against
SQL injections [29]. Figure 3.1 presents a parameterized query. Here, placeholders are used
for name and email instead of actual values. The value for mentioned name and email will be
supplied at runtime. This avoids String concatenations and constructs a query plan on the server
at runtime. This simple change in how the query is stated can help prevent SQL injection
attacks.

3.8 SUMMARY

The chapter consists of a testing methodology conducted at the application level, using
penetration testing tools. The analysis explains the most known security threats based on the
results obtained for the IT Company. This chapter presents the two components of our proposed
approach that work together to secure web applications. The security policies work to fend of
SQL injection attacks, XSS attacks and resource alteration attacks. The integrity verification
module makes use of web workers to ensure client side code integrity during runtime.
Integrating both these components on web applications protects them from some prevalent
attacks and code tampering on the client side.

25
CHAPTER 4 RESULTS AND DISCUSSION

4.1 INTRODUCTION

The experiments to show the success rate of this approach is conducted through the
vulnerability scanner and attack tools. Each of the tools stated above are used on the web
applications. This is done before any of the changes are made to the web applications. The
results from the experiments are then saved as the “before" version of the experiments.
Afterwards, the web applications are put through our approach and the security policies and
integrity verification module are integrated to it. This makes the web applications less
vulnerable and they are able to protect themselves from SQL injection attacks, cross-site
scripting attacks and resource alterations. The web applications are put through the same
experiments again after each component is integrated.

To emulate SQL injection attacks and XSS attacks, we use the fuzzers discussed above. For
attack purposes, we choose attack inputs from two widely used sources to detect XSS and SQL
injections which are XSS Cheat Sheet and SQL Injection Cheat Sheet [37]. For each web
application, the attacks are performed one hundred times, each time with a unique input. The
number of times the web applications can prevent the attacks (out of one hundred) is calculated.
The average of the number of preventions across all the web applications is presented as the
prevention rate.

For resource alterations, we alter the scripts the web application is expecting both before and
after the page is loaded. This is attempted one hundred times for each web application. The
number of times each web application detects the alteration and prevents the scripts from
executing (out of one hundred) is calculated. The average number of times the attacks are
prevented across all the web applications are presented here. The average prevention rate is for
all the web applications in the repository, each of which have been attacked one hundred times
separately.

26
The protection evaluation is divided into three parts. The first part discusses the main flaws and
vulnerabilities found in the web applications. The second part comes in after the security
policies are integrated. It presents the added benefits and shows the results from the
experiments. The third part reveals the results after both the components are integrated. This is
considered as the final results for our approach. The three levels of evaluation are discussed
below.

4.2 PRE-INTEGRATION PROTECTION EVALUATION

To keep track of the vulnerabilities the web applications have before integrating our approach,
we run our experiments on them. These experiments consist of the attacks we later secure the
web applications from. The attacks in question are SQL injection, cross-site scripting and
resource alteration attacks.

Figure 4.1 summarizes the initial experiment results. For each type of attack, we calculate how
many were prevented. As discussed above, the attacks were performed one hundred times with
unique parameters. The prevention rate was calculated by how many attacks from the hundred
attacks were prevented. From Figure 4.1, we can see that the web applications have massively
succumbed to attacks in the first round of experiments. The prevention rate is below 55 percent
for all of the attacks. This includes common SQL injection attacks which are the most popular
type of injection attacks performed on web applications. For evaluation purposes, resource
alteration is done by changing the scripts and files the web application is fetching.

The prevention rate is the lowest for this kind of attack. This is mostly due to the fact that the
web applications in question did not have a mechanism to check for altered scripts. Most web
applications still let the scripts execute after alteration.

27
 Attacks Types
60

50
Prevention Rate

40

30

20

10

0
SQL injection Cross -site Scripting Resource alteration
Axis Title

Attacks Types

FIG. 4.1. ATTACK PREVENTION RATE PRIOR TO INTEGRATION OF THE

APPROACH.

These initial results are needed to calculate how well the applications have been secured after
our approach has been integrated. After this step, we move on to the integration of our approach
to the web applications in two steps. The security policies are integrated to the web application.

4.4.2 PROTECTION EVALUATION WITH SECURITY POLICIES

The first part of our approach to securing the web applications is to integrate the security
policies. The policies begin with input sanitization and output validation. However, this
component also includes policies to decide privilege and check for integrity. Lastly, the content
security policy makes sure that the browsers have power over what to execute. All of these
policies are integrated into the web applications in order. To check if the integration of the
security policies provides the web application with more security, we do another round of
experiments. The protection evaluation is still based on one hundred unique attacks per attack
type. The results are shown in Figure 4.2.

28
 Attacks Types
86

84

82
Prevention Rate

80

78

76

74

72

70
SQL injection Cross -site Scripting Resource alteration
Axis Title

Attacks Types

FIG. 4.2. ATTACK PREVENTION RATE AFTER THE INTEGRATION OF THE

APPROACH.

After the integration of our approach, the prevention rate of the web applications against
prevalent attacks increases. For each of the unique attacks involved, the web applications detect
and deflect them more than before. The prevention rate for resource alteration attacks shows
the most positive change. This is due to the sub resource integrity policy ensuring that the
external scripts cannot be altered. The resource alteration attacks are mostly successful when
the security policies are not able to load before the attacks are performed. This happens when
the attacks are initiated before the page with the security policies has loaded. Both SQL
injection and cross-site scripting attacks are better defended than before. This is due to the
exhaustiveness of the security policies. It can be mentioned that these two policies do not
require that the developers are knowledgeable in web application security. These policies
require that the developers have information about the expected behavior of the web application
in question.

4.5 DISCUSSION
The experimental results show that the proposed approach for securing the web applications
with the use of the two components is promising. Table 4.2 shows the percentage increase in
prevention rates of all the individual attack scenarios. The average percentage increase is
around 32 percent from just integrating the security policies. This is a major change from the

29
initial state of security of the web applications. The prevention rates are calculated from the
average rates across multiple web applications which range in varying sizes, usability and
complication levels. These results show how the introduction of our approach to secure the
web applications makes them less vulnerable to the above mentioned attacks.

TABLE. 4.5. INCREASE IN ATTACK PREVENTION RATE

Attacks Increase in prevention rate

SQL Injection 24

Cross- site scripting 31

Resource alteration 43

30
CHAPTER 5: CONCLUSIONS AND RECOMMENDATIONS

In this chapter, I summarize my research work and recommendations. I also discuss the
limitations of the proposed approach and this can be considered as future work.

5.1 SUMMARY

The primary goal for this dissertation is to provide an approach to secure web application client
sides. To achieve this goal, we make use of secure coding practices to protect the application
against some named attacks using predetermined security policies. From secure coding
practices and secure design principles, we come up with security policies. These policies work
together to protect the web application against some prevalent attacks namely SQL injection,
cross-site scripting and resource alteration. These policies include input and output sanitization,
principle of least privilege, sub resource integrity and content security policy. The integrity of
the JavaScript files is also checked in this component. Not having the same hash value as the
known good hash value or not having the right permissions prevents the JavaScript files from
executing. This ensures that attacks such as cross-site scripting and injection attacks are
prevented. The security provided by the applications is evaluated and the results are presented.
From the analysis of the results, we can say that the security provided for the prevention of
attacks and code tampering on client side is significantly better with the use of our approach.

The contributions of this dissertation include the development of security policies with the help
of secure coding practices and secure design principles. These policies act as a guideline for
web application developers to protect their applications from different types of attacks.
Although not all the policies are novel, the manner in which they are organized with
implementation guidelines for specific web application attacks is original. Moreover, the
evaluation information that is presented is meant for developers to use in factoring in what
approaches to use to secure their web applications. The results can act as a guide for web
application developers in the prevention of similar attacks.

5.2 LIMITATIONS

The web applications that we used for this research work are all open source. They range from
inventory managers to invoicing systems and are built on different platforms with JavaScript

31
used on the client side. However, throughout the experiments, we did not keep track of how
our approach affected each web application in practice. The average attack prevention rate
results across all the web applications in our repository were presented instead of each
individual web application. In this work, we assume that developers know the expected inputs
and outputs for the web applications. Without this, integrating the security policies will be
complicated and might cause security holes. For our approach to be useful, the client side code
needs to be loaded without errors or changes. If the files containing the security policies are
prevented from loading, then this approach will fail to secure the web application. Moreover,
the client side of web applications will always be more vulnerable and difficult to secure than
server sides. The security policies provide the first line of defense against attacks on the web
applications. The policies are designed to prevent attacks for web applications that do not have
more comprehensive security systems in place. However, for a well-rounded security system,
policies should be placed on both the client and the server side that work simultaneously to
provide security to web applications.

5.3 RECOMMENDATIONS

I recommend two areas that will increase the usability of this approach and the security it
provides. As discussed in the contribution section of this dissertation, the security policies that
are presented cover an array of attack prevention methods for web applications. The policies
are chosen from relevant research and OWASP secure coding practices [6]. There was no
specific optimization done in terms of integrating these policies with the web applications in
mind. In the future, more information can be collected for each type of web application to put
in specific sets of rules and constraints when integrating the policies. This will lead to more
secure applications with fewer development patches needed.

Strings made up of entire classes of JavaScript code are passed back and forth in these channels.
The signing process is not possible without the use of at least one of these channels. However,
only the minimum number of these channels is used to connect different files of the web
application to the signing code and main page. Introducing more message channels that carry
encrypted code back and forth can make the system more scalable. This can also be used as a
means for complication. Classifying the client side code and using message channels for
communication can be explored more in the future.

32
 REFERENCES

[1] Zanders, J. P. (2009) “Cyber Security: What Role for the CFSP?” Institute Report - seminar
organized jointly by General Secretariat of the Council of the EU & the EU Institute for
Security Studies in cooperation with Estonia held in Brussels on 4 February 2009, European
Union Institute for Security Studies.
[2] Symantec Co., 2018. ISTR. Internet Security Threat Report, 22, 33
[3] Jacques Bughin and Michael Chui ,2010, The rise of the networked enterprise, Mckinsey
Global Institute.
[4] Verizon, 2018. 2018 Data Breach Investigations Report. [Online]. Available:
http://www.verizonenterprise.com/verizon-insights-lab/dbir/ (Accessed 2018-12-26).
[5] “W3c HTML." [Online]. Available: https://www.w3.org/html/ (Accessed 2019-01-14).
“HTML&CSS-W3c." [Online]. Available: https://www.w3.org/standards/ webdesign/htmlcss
(Accessed 2019-01-14).
[6] “OWASP Secure Coding Practices Checklist - OWASP." [Online]. Available:
https://www.owasp.org/index.php/OWASP Secure Coding Practices Checklist (Accessed
2019-02-18).
[7] http://www.mavitunasecurity.com/netsparker/ [Retrieved: 2019-01-18]
[8] Hedin, Daniel & Sabelfeld, Andrei. (2012). Information-Flow Security for a Core of
JavaScript. Proceedings of the Computer Security Foundations Workshop. 3-18.
10.1109/CSF.2012.19.
[9] T. Jim, N. Swamy, and M. Hicks, “Defeating Script Injection Attacks with Browser-enforced
Embedded Policies," in Conference on World Wide Web. ACM, 2007, pp. 601-610.
[10] “HTML5 Web Workers." [Online]. Available: https://www.w3schools.com/html/html5
webworkers.asp (Accessed 2019-03-09).
[11] Theodoor Scholte and G. Vigna, “Static Enforcement of Web Application Integrity Through
Strong Typing," in Symposium on Security. USENIX Association, 2017.
[12] J. Bau, E. Bursztein, D. Gupta, and J. Mitchell, “State of the Art: Automated Black-Box Web
Application Vulnerability Testing," in Symposium on Security and Privacy. IEEE, May 2010,
pp. 332-345.
[13] F. Ricca and P. Tonella, “Analysis and Testing of Web Applications," in Conference on
Software Engineering. IEEE, 2001, pp. 25-34
[14] W. G. J. Halfond and A. Orso, “Preventing SQL Injection Attacks Using AMNESIA," in
Conference on Software Engineering. ACM, 2006, pp. 795-798

33
[15] N. Bielova, “Survey on JavaScript Security Policies and their Enforcement Mechanisms in a
Web Browser," The Journal of Logic and Algebraic Programming, vol. 82, no. 8, pp. 243-262.
[16] OWASP, “Top 10 2018-Top 10 - OWASP." [Online]. Available: https:
//www.owasp.org/index.php/Top 10 2017-Top 10 (Accessed 2018-11-14).
[17] N. Jovanovic, C. Kruegel, and E. Kirda, “Precise Alias Analysis for Static Detection of Web
Application Vulnerabilities," in Workshop on Programming Languages and Analysis for
Security. ACM, 2006, pp. 27-36.
[18] “AJAX-Request." [Online]. Available: https://www.npmjs.com/package/ajax-request
(Accessed 2018-12-31).
[19] “BIG-IP Application Security Manager." [Online]. Available: https://f5.com/ products/big-
ip/application-security-manager-asm (Accessed 2018-12-08).
[20] “Validators - Django documentation." [Online]. Available: https://docs.
djangoproject.com/en/2.0/ref/validators/ (Accessed 2019-02-01).
[21] “Validator Commons Validator." [Online]. Available: https://commons.apache.
org/proper/commons-validator/ (Accessed 2019-02-01).
[22] “Content Security Policy CSP Reference & Examples." [Online]. Available:
https://content-security-policy.com/ (Accessed 2019-01-21).
[23] “Security by Design Principles - OWASP." [Online]. Available:
https://www.owasp.org/index.php/Security by Design Principles # Principle of Least privilege
(Accessed 2019-02-07).
[24] “OWASP Secure Coding Practices Checklist - OWASP." [Online]. Available:
https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_Checklist (Accessed
2019-03-29).
[25] P. De Ryck, L. Desmet, F. Piessens, and M. Johns, Primer on Client-side Web
Security. Springer, 2014.
[26] “The Web Framework for Perfectionists with Deadlines j Django." [Online].
Available: https://www.djangoproject.com/ (Accessed 2019-03-29).
[27] https://www.owasp.org/index.php/Testing:_Introduction_and_objectives [Accessed 2019-
03-26]
[28] Operating System Market Share Worldwide [online]. [cit. 2019-03-23]. Available
http://gs.statcounter.com/os-market-share
[29] “NIST Special Publication 800-63b." [Online]. Available: /sp800-63b.htm (Accessed 2019-
01-30).

34
[30] A. Nguyen-Tuong, S. Guarnieri, D. Greene, J. Shirley, and D. Evans, “Automatically
Hardening Web Applications Using Precise Tainting," in Conference on Security and Privacy
in the Age of Ubiquitous Computing. Springer, May 2005 pp. 295-307.
[31] Y. Nadji, P. Saxena, and D. Song, “Document Structure Integrity: A Robust Basis for Cross
Site Scripting Defence." in Symposium on Network and Distributed System Security (NDSS),
Jan. 2009, pp. 1.
[32] Y.-W. Huang, F. Yu, C. Hang, C.-H. Tsai, D.-T. Lee, and S.-Y. Kuo, “Securing Web
Application Code by Static Analysis and Runtime Protection," in Conference on World Wide
Web. ACM, 2004, pp. 40-52.
[33] J. Bau, E. Bursztein, D. Gupta, and J. Mitchell, “State of the Art: Automated Black-Box Web
Application Vulnerability Testing," in Symposium on Security and Privacy. IEEE, May 2010,
pp. 332-345.
[34] O. Ismail, M. Etoh, Y. Kadobayashi, and S. Yamaguchi, “A Proposal and Implementation of
Automatic Detection/Collection System for Cross-site Scripting Vulnerability," in Conference
on Advanced Information Networking and Applications, vol. 1. IEEE, Mar. 2004, pp. 145-151.
[35] Y. Nadji, P. Saxena, and D. Song, \Document Structure Integrity: A Robust Basis for Cross-
site Scripting Defense." in Symposium on Network and Distributed System Security (NDSS),
Jan. 2009, pp. 1-20.
[36] J. Wan, M. Zulkernine, P. Eisen, and C. Liem, “Defending Application Cache Integrity of
Android Runtime," in Conference on Information Security Practice and Experience. Lecture
Notes in Computer Science, Springer, Dec. 2017, pp. 727-746.
[37] “XSS (Cross Site Scripting) Prevention Cheat Sheet - OWASP." [Online]. Available:
https://www.owasp.org/index.php/XSS (Cross Site Scripting) Prevention Cheat Sheet
(Accessed 2019-04-14).
[38] “Vega helps you find and fix cross-site scripting (XSS), SQL injection, and more.” [Online].
Available : https://subgraph.com/vega/ (Accessed 2019-05-14).
[39] “Bossie Awards 2015: The Best Open Source Networking and Security Software," Sep. 2015.
[Online]. Available: https://www.infoworld.com/article/2982962/open-source-tools/bossie-
awards-2015-the-best-open-source-networking-and-security-software.html (Accessed 2019-
05-02).
[40] P. E. Proctor, E. Perkins, and A. Walls, “Innovation Insight: Digital Business Innovation Risk
Will Bring About the Rise of the Digital Risk Officer." [Online]. Available:
https://www.gartner.com/doc/2771823/innovation-insight-digital-business-innovation
(Accessed 2019-05-06).
35
[41] R. L. Jones and A. Rastogi, “Secure Coding: Building Security into the Software
Development Life Cycle," Information Systems Security, vol. 13, no. 5, pp. 29-39, Nov. 2004.
[42] P. De Ryck, L. Desmet, F. Piessens, and M. Johns, Primer on Client-side Web Security.
Springer, 2014.

36