Download - CROSS-SITE SCRIPTING PREVENTION
CROSS-SITE SCRIPTING PREVENTION
BY APPLYING CONTENT SECURITY POLICY
PIRAVEEN A/L RAJADURAI
Bachelor of Computer Science (Computer Network Security)
Faculty of Informatics and Computing
University Sultan Zainal Abidin, Terengganu, Malaysia
2
OCTOBER 2020
III
DECLARATION
I hereby declare that this report is based on my original work except for quotations and citations,
which have been duly acknowledged. I also declare that it has not been previously or concurrently
submitted for any other degree at Universiti Sultan Zainal Abidin or other institutions.
Name: PIRAVEEN A/L RAJADURAI
Date: ………………………………………………
IV
CONFIRMATION
I have read this report and in my point of view, this project has fulfilled a condition to be awarded a
Bachelor of Computer Science (Computer Network Security) with Honours.
Name: En Ahmad Faisal Amri Bin Abidin @ Bharun
Date: ………………………………………….
V
ACKNOWLEDGEMENT
I would like to thank everyone who had contributed to the successful completion of project. I would
like to express my gratitude to my supervisor, En Ahmad Faisal Amri bin Abidin for his invaluable
advice, guidance and his enormous patience throughout the development of the project. In addition, I
would also like to express my gratitude to my colleagues and classmates for their motivation and
immense knowledge. They were exceptionally generous in sharing their extensive knowledge in the
field of IT Security and mental support with me. Last but not least, my sincere thanks to my family
and loved ones whom have been providing me with great support throughout the project.
VI
ABSTRACT
In this project, the great threat Cross-Site Scripting (XSS) is introduced that faced with the web pages.
Because of the impacts of such web threats during design and developing web pages, web developers
VII
must be aware and have adequate knowledge about varies type of web attacks and how to prevent or
mitigate them. Web developers should have knowledge about how attackers attack websites and
exploit weak points on websites during filling forms, registering and opening suspicious links or
attachments in emails. The important of this subject is to provide great details and information about
identifying impacting and protecting from these types of web threats. It aims to provide both web
developers and users with enough knowledge while developing and using websites to prevent from
such attacks and reduce them impacting and protecting from these types of web threats. It aims to
provide both web developers and users with enough knowledge while developing and using websites
to prevent from such attacks and reduce them. In this paper use PHP’s functions to evaluate the
efficiency of web pages for implementing it and to prevent XSS attack.
VIII
Contents
DECLARATION .................................................................................................................. III
CONFIRMATION ................................................................................................................ IV
ACKNOWLEDGEMENT ...................................................................................................... V
ABSTRACT ........................................................................................................................ VII
CHAPTER 1 .......................................................................................................................... 1
INTRODUCTION ................................................................................................................. 1
1.1 Background ................................................................................................................ 1
1.2 Problem Statement ...................................................................................................... 3
1.3 Objectives ................................................................................................................... 3
1.4 Scope .......................................................................................................................... 3
1.5 Academic Value .......................................................................................................... 4
1.6 Limitation of work ...................................................................................................... 4
1.7 Expected Result ........................................................................................................... 5
1.8 Summary .................................................................................................................... 6
CHAPTER 2 .......................................................................................................................... 7
Literature Review .................................................................................................................. 7
2.1 Introduction ................................................................................................................ 7
2.2 Cross-site scripting ...................................................................................................... 9
2.9 Summary .................................................................................................................. 18
CHAPTER 3 ........................................................................................................................ 19
IX
METHODOLOGY .............................................................................................................. 19
Reference ............................................................................................................................ 30
LIST OF ABBREVIATIONS / TERMS / SYMBOLS
XSS Cross-site scripting
UFW Uncomplicated firewall
CSP Content-security policy
OS Operating system
HTTP Hypertext Transfer Protocol
X
LIST OF FIGURES
Figure 1: Apache configuration status 8
Figure 2: Scenario in XSS 9
Figure 2.5: Mapping between HTML5 and JavaScript features and Content Security Policy controls
12
Figure 3.0: SecSDLC mechanism 19
Figure 3.1: Step of testing
20
XI
1
CHAPTER 1
INTRODUCTION
1.1 Background
Cross-Site Scripting has been known to be the most common and serious attack against web
based services. Confidentiality of browsers has been compromised in many ways since they support
the execution of embedded scripts. With this capability of sites to be attacked, the attackers have the
capacity to take control of the sites through cross site scripting attacks. How to combat and prevent
the attacks has to be looked at seriously. With this in mind I have come up with a solution to detect
and deter these attacks. I elaborate how well overly we can solve the problem with content security
policy that deals with the cross-site scripting attacks. The network has developed from static sites to
dynamic sites and the social media from Facebook, twitter, whatsapp, e.t.c are the leading online
interaction sites. The participants in these networks use these malicious injected script codes without
knowing. The current browsers are so limited in detecting the attacks and hence tools need to be
developed to deal with this problem on the browser side. Content-Security-Policy is the name of a
HTTP response header that modern browsers use to enhance the security of the document (or web
2
page). The Content-Security-Policy header allows you to restrict how resources such as JavaScript,
CSS, or pretty much anything that the browser loads. The project is specific to look at the gap, build
and test the components of the tool and evaluate the tool’s performance, reliability and accuracy as
compared with other tools. These project tries to answer most of the asked questions such as, is it
possible to stop XSS attacks in a more secure and easy way, what do the current tools offer, what are
the shortfalls of these tools and previous researches and can we develop a secure and light tool that
can be incorporated within the web service scripts to reduce overhead load associated with current
tools. The project covers the area of XSS related attacks more so on the client side of the browsers,
malicious attacks and input area
3
1.2 Problem Statement
System isn’t secured enough to withstand any kind of attacks
System can’t detect and specify any kind of attacks that takes place
The browser doesn’t inspects every item that the website’s HTML requests
1.3 Objectives
● To study XSS-based attacks and its patterns to find out information attacker’s after
● To apply content security policy in web application for added security measure
● To test web server that has been applied content security policy with web application
firewall
1.4 Scope
● To build a web server and upload a browser
● To integrate web server with content security policy
4
● Launch XSS attacks to web browser that has been embedded with content security
policy
1.5 Academic Value
● The process of studying and understanding of the XSS attacks specifically and how it
works
● The process of studying content security policy and find out how it can withstand
XSS attacks by the help of web application firewall
1.6 Limitation of work
● Limited time to study the whole concept of the cross-site scripting attacks and the
dangers it implies
5
● Limited technological facilities by conducting project at home
● Internet disruption given with online distance learning period
1.7 Expected Result
The expected result should be like this
Figure 1: Apache configuration status
Uncomplicated firewall( UFW) rules has been assigned to Apache web server
Apache web server has been installed and configured
By creating virtual host, attacks can be initiated and from those outcomes, content security
policy has been assigned
6
1.8 Summary
This chapter describes a few topics included in the introduction of the project such as the background
of the project, the problem statement, objective for this project, scope, and the limitation of work.
Thus, it helps to organize better documentation of the project.
7
CHAPTER 2
Literature Review
2.1 Introduction
Security of web applications is a major concern in many organizations. Organizations come
up with widespread ways to protect themselves. They try to protect their sensitive data and systems
through many tools like firewall, Intrusion Detection System (IDS) e.t.c from attacks on their web
based services. Most don’t achieve they intend even after putting up such tools. Some go to the extent
of deploying humans just to monitor the traffic within their organizations. But still we have cases of
attacks even on the most presumed secure organization. The main attacks are on SQL queries through
8
SQL injection by XSS designed by hackers. This literature review digs deep into the security
threats/vulnerabilities that are exploitable or are already exploited by these XSS attacks. Gadhiya et al
2014, states that,“as new technology arrives, it comes with lot of new features and possibly attacks. In
the today’s trend of social web application, the SQL injection, cross site scripting (XSS) attack and
cross site forgery attack are major challenges for web application.”
Federal Information Processing Standards Publication (FIBS PU 200) defines a threat as a possible
danger that might exploit a vulnerability to breach security and thus cause harm. Threats are basically
exploits that allows one to obtain valuable thing at absolutely no cost with the intent of destroying
reputation.
The most important security notion within web communication is the idea of the same-origin policy.
Same origin policy plays a lot in the systems vulnerability by assuming that what follows in a secure
connection is always trusted. Even though the idea of same origin policy is much welcomed, it has
brought with it the problem of hackers taking advantage. The principal intent for this mechanism is to
make it possible for largely unrestrained scripting and other interactions
9
2.2 Cross-site scripting
Figure 2 Scenario in XSS
10
2.3 Cross-site scripting examples
Most sites are based on scripts and this makes them easy to attack. With millions of web services
developed everyday attackers are also busy checking vulnerability associated with such application
development. Generally cross site scripting vulnerability has been so profitable and attackers are so
informed on how to exploit this. Going on with getting the vulnerability the hackers can get control of
the whole site.
The risks associated with XSS attacks if not dealt with are so wide and leaves your website vulnerable
to:
a) Stealing of login details like username and passwords.
b) Taking sensitive information from clients and their website behavior.
c) Stealing of company data.
d) Keystroke logging of clients that visit your site
e) Bringing down your whole site.
f) Causing denial of service
g) When they take control of your site they can ask for ransom.
h) Redirecting your visitors to wrong sites.
11
When XSS attackers exploit the vulnerability and attack a site they use those websites to:
a) Probe the rest of the intranet for other vulnerabilities
b) Spread the XSS attack cross the intranet
c) Monitor the intranet behavior
d) Launch Denial of Service attacks
e) Launch Data illegal acquisition
2.4 Cross-site scripting vulnerability exploitation
According to Patil and Agrawal 2015, “wherever web based applications are distributed applications
consisting of components that execute either on a web server or on a user's client, scripting
vulnerabilities arise when content controlled by an adversary (i.e. Un-trusted data) flows into critical
operations of the program (i.e. critical sinks) without sufficient security confirms. Patil determines
that attackers take advantage of distributed applications to allow for scripting attacks to flow into
critical parts of any application. This causes an attacker to gain higher privileges than intended by the
web based application, characteristically contributing entrusted data the same chances as the web
application's code.”
Most of the attacks are first achieved by doing random checks on the vulnerability of the applications
to XSS attacks. Unfortunately, most web applications, both Free/Open Source Software and
commercial software, are susceptible. Attackers simply perform a Google search for terms that are
often found in the software. After discovering the vulnerable web site the attacker looks through the
HTML to find where the exploit code can be put. After this has been determined, the attacker then
begins to code the exploit in any of these three ways:
12
1. Reflected attacks: The client/end-user is duped into clicking a malicious link or submitting a
changed or manipulated form. The injected code is sent to a vulnerable web server that directs the
cross-site attack back to the user’s browser. The browser then executes the malicious code, assuming
it comes from a trusted server.
2. Stored (persistent) attacks: This is where a malicious code is injected into the target server and
sits there waiting for trigger. When interacting with the target server, an end-user inadvertently
retrieves and executes the malicious code from the server.
3. DOM-based attacks: Remote execution is activated to allow the attacker to execute malicious
code on the target computer. The attacker injects the written code into the target site.
Getting the pay
After the attacker gains access to the vulnerable site, he/she now starts to be rewarded with the pay for
the attack. In cases where the hacker’s intent was to steal login credentials then they are now
collected. Actually the attacker is now in control and will do whatever they wish to do. Google and
other site engines usually flag vulnerable sites after such attacks even if the sites have been fixed. This
is quite expensive to the organization, considering the reputation cost it has on the organization.
If the attack succeed, he/she will often do it on other related websites to increase the reward.
13
2.5 Content security policy
Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain
types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are
used for everything from data theft to site defacement to distribution of malware.
CSP is designed to be fully backward compatible (except CSP version 2 where there are some
explicitly-mentioned inconsistencies in backward compatibility). Browsers that don't support it still
work with servers that implement it, and vice-versa: browsers that don't support CSP ignore it,
functioning as usual, defaulting to the standard same-origin policy for web content. If the site doesn't
offer the CSP header, browsers likewise use the standard same-origin policy.
To enable CSP, configure web server to return the Content-Security-Policy HTTP header. (Sometimes
you may see mentions of the X-Content-Security-Policy header, but that's an older version and you
don't need to specify it anymore.)
Alternatively, the <meta> element can be used to configure a policy, for example: <meta http-
equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">
14
Figure 2.5: Mapping between HTML5 and JavaScript features and Content Security Policy controls
15
2.6 Cross-site scripting mitigation
A primary goal of CSP is to mitigate and report XSS attacks. XSS attacks exploit the browser's trust
of the content received from the server. Malicious scripts are executed by the victim's browser
because the browser trusts the source of the content, even when it's not coming from where it seems to
be coming from.
CSP makes it possible for server administrators to reduce or eliminate the vectors by which XSS can
occur by specifying the domains that the browser should consider to be valid sources of executable
scripts. A CSP compatible browser will then only execute scripts loaded in source files received from
those allowlisted domains, ignoring all other script (including inline scripts and event-handling
HTML attributes).
As an ultimate form of protection, sites that want to never allow scripts to be executed can opt to
globally disallow script execution
2.7 Importance content-security of policy
Web security is based on same-origin policy (SOP), which prevents a website from accessing data
outside its own origin. In theory, this should be enough to ensure security, but the modern web
requires sites to include lots of assets from external sources, such as scripts and other resources from
content delivery networks (CDNs), Google Analytics scripts, fonts, styles, comment modules, social
media buttons – the list goes on.
16
At the same time, malicious hackers use cross-site scripting (XSS) attacks to trick websites trusted by
the user into delivering malicious code. Without additional safety measures, the browser executes all
code from a trusted origin and can’t tell which code is legitimate, so any injected malicious code is
executed as well.
Content Security Policy (CSP) is a standardized set of directives that tell the browser what content
sources can be trusted and which should be blocked. Using carefully defined policies, it can restrict
browser content to eliminate many common injection vectors and significantly reduce the risk of XSS
attacks. By default, CSP also enforces modern script coding styles for extra security.
2.8 Content security policy directives
The main purpose of CSP is to restrict web content sources, so there are many directives for
specifying permitted sources for various types of assets. Once a Content-Security-Policy header is
specified, the browser will reject any content from sources that are not explicitly whitelisted using any
of the directives below. Source values are separated by spaces and can include both URLs and the
special keywords 'none', 'self', 'unsafe-inline', and 'unsafe-eval'. Each directive can be specified only
once in the same header, and keywords must be entered in single quotes.
17
1) default-src is a fallback directive used to specify the default content policy for most of the source
directives. Common uses include default-src 'self' to allow content from the current origin (but not its
subdomains) and default-src 'none' to block everything that’s not explicitly whitelisted.
2) script-src is used to whitelist script sources. To allow scripts from the current origin only, use
script-src 'self'.
3) style-src is used to whitelist CSS stylesheet sources. To allow stylesheets from the current origin
only, use style-src 'self'.
4) connect-src specifies permitted origins for direct JavaScript connections that use EventSource,
WebSocket, or XMLHttpRequest objects.
5) object-src allows control over the sources of plugins such as Flash. Note that you can also specify
permitted plugin types using the plugin-types directive (unsupported in Firefox as of v76).
6) img-src lets you restrict image sources.
font-src specifies permitted sources for loading fonts.
7) media-src restricts origins for loading sound and video resources.
8) child-src is used to restrict permitted URLs for JavaScript workers and embedded frame contents,
including embedded videos. In Level 3, frame-src and worker-src directives can be used instead to
control embedded content and worker processes respectively.
9) frame-ancestors restricts URLs that can embed the current resource in <iframe>, <object> and
similar elements.
18
2.9 Summary
XSS threats, its principles and aspects, dangers types are presented in this work. Nowadays, XSS
counts as one of the prime threat for web applications. There are three types of XSS, stored XSS,
reflected XSS and DOM based XSS. XSS is simply known as “script injection attacks”. Web
developers must be aware to face attackers and how they attack websites and taking advantages out
from weak points of websites during form filling, logging in and opening fishy links or attachments in
emails.
19
CHAPTER 3
METHODOLOGY
3.1 INTRODUCTION
A variation of this methodology used to create a comprehensive security posture is called the security
systems development life cycle (SecSDLC). SecSDLC is a formal approach to designing information
security programs that follows the methodology of a traditional information systems development life
cycle (SDLC) including a recursive set of phases such as investigation, analysis, logical design,
physical design, implementation and maintenance and change. The SecSDLC process involves the
identification of specific threats and the risks. To protect confidentiality, integrity and availability of
information is the main focus for this SecSDLC.
20
Figure 3.0: SecSDLC mechanism
This SecSDLC (Michael E. Whitman & Herbert J. Mattord ,2016) can serve as a basis for
understanding a common approach to developing and implementation new security programs. The
benefits of using this methodology is allowing some degree of re-work, revisiting previous stages
when issues arise or progress is unsatisfactory. Furthermore, if the program is not adjusting
adequately to the changes in the internal or external environment, it may be necessary to begin the
cycle again.
3.1.1 INVESTIGATION
This is the first step where a student starts collecting the information about the project. The task is
needed for student to find a group member and discuss together about what kind of project that they
will do. Each of student need to prepare at least two project. The content of the proposal will be the
kind of requirement that they need to do such as software, hardware and so on.
21
Besides that, he/she need to provide the goals, scope, problem statement, budgets and more towards
each of project. After that, the group will be propose to the supervisor as their preferences and the
supervisor will discuss together with the group members for the suitable project that they can handle.
3.1.2 ANALYSIS
In this phase, the team needed to refer to the first phase that provide the document about goals, scope,
problem statement, budgets, requirement of software and hardware and associated about the selected
project based on the agreement of both supervisor and students. After review the document, the group
member will assigned to each role where they will do the preliminary analysis towards the selected
project. In this project, an interview is accurate for support the project and as fact finding.
Then, the group member will focus more on the content of documentation such as do the deep search
about the software and hardware that will be used, the environment that will be created and more.
When the document has been studied, it will develop to identify vulnerabilities and takes carefully
reasoned steps to assure confidentiality, integrity and availability.
3.1.3 LOGICAL DESIGN
After investigate and analyse the information about the project, its continues with the logical design
phase .This phase where we will create the plan of the project to shows the system specifications or as
known as blueprint and develop it for security. Besides that, this phase is needed for support the next
phase that might prove useful when implemented as a physical design.
22
3.1.4 PHYSICAL DESIGN
Previous phase is the implementation blueprint for the desired solution. In this phase, team member
start to install the software needed to build the environment based on previous phase.
3.1.5 IMPLEMENTATION
In order to ensure that all devices can run smoothly, this phase will be make on each device used.
Also, testing and program or system acceptance happened in this phases.
Figure 3.1: Step of testing
23
3.1.5.1 RECONNAISANCE
This phase deals with information gathering about a specific website or system. Both passive and
active reconnaissance can lead to the discovery of useful information to use in an attack. As example,
to find what kind of type that web server and operating system (OS) version number that is used. This
information may enable find a vulnerability in that OS version and exploit the vulnerability to gain
more access .The more information collected about a specific system or a website, it is bigger chance
for succeed in later phase .
3.1.5.2 SCANNING
After completing in deep reconnaissance, the attacker should have a list of target that can be scanned
.This phase will show the process of identifying live systems and the services that exist on those
systems. This phase broken into two part that is port scanning and vulnerability scanning .In port
scanning, it should be have a list of open ports and potential service running on a specifc website or
target system. While in vulnerability scanning, the attacker will show the process of locating and
identifying specific weaknesses in the software and services on a certain website or target system.
3.1.5.3 EXPLOITATION
Once the attacker know exactly what ports are open, what kind of services are running on
those ports and what the vulnerabilities are associated with those services, the attacker can begin to
attack the target. This phase involve a lots of different techniques, tools and code. The ultimate goal
of this phase is to have administrative protect the website from the attacker from stole the data.
24
3.1.5.4 MAINTAINING ACCESS
Most payloads or attacks are not persistent because sometimes it delivered in the exploitation phase
with only temporary access to the system, so as to that we must always analyse the system from the
attacker. It can also be defined as sustainability of a payload or attacks for a specific set of time. How
long can a payload or a certain type of attacks can bring the expected result before it has been
identified by system administrator and mitigation approaches has been deployed? It is necessary for
an attacker or a penetration tester to make a good use of his/her exploit whether it’s custom-based or
generated automatically by exploitations tools.
3.1.6 MAINTENANCE & CHANGE
This phase where performance measures and operational reporting in implementation. When the
existing system or program is deemed, ineffective or inefficient, the team will go the previous phase
or first phase to repair. Once the information security program is implemented, it must be operated,
properly managed, and kept up to date by means of established procedures. This phase required all
phases that are investigate, analysis, logical design, physical design and implementation so that
SecSDLC is perfectly done.
25
3.2 Framework
26
3.3 Flowchart
3.4 How to do scanning
After an attacker or a penetration tester has completed the reconnaissance phase of an organization,
they will move into the scanning phase. In this phase, they can take the information learned about the
employees, contractors, and information systems to begin expanding the view of physical and logical
information system structures within the organization. Like any of the other phases in the penetration
testing lifecycle, the penetration tester can return to earlier phases as needed to gain more information
to enhance information gathered in the scanning phase.
27
The main focus of the scanning phase is to determine specific information about the computers and
other devices that are connected to the targeted network of the organization. Throughout this phase,
the focus is on finding live hosts, determining node type (desktop, laptop, server, network device, or
mobile computing platform), operating system, public services offered (web applications, SMTP,
FTP, etc.), and even possible vulnerabilities. Scanning is done with a number of different tools such
as Nmap, Hping, and Nessus. The goal of this phase is to have a listing of possible targets for the next
phase of the penetration testing lifecycle which has identified as exploitation
3.5 Why exploitation phase is necessary
During this phase a penetration tester or an attacker will try to find exploits for the various
vulnerabilities found in the previous phase. There are many repositories on the internet that provide
proof‐of‐concept exploits for most of the vulnerabilities. The odds are high for a penetration tester or
an attacker to have programming knowledge of C or scripting languages like Perl, Python or Ruby. It
helps in understanding and writing exploits and custom tools / scripts.
This phase can be dangerous if not executed properly. There are chances that running an exploit may
bring a production system down. All exploits need to be thoroughly tested in a lab environment prior
to actual implementation. Some organizations would require that certain vulnerabilities on critical
systems should not be exploited.
There are good exploitation frameworks available that would aid a penetration teste or an attacker in
developing exploits and executing them in a systematic manner. Few good commercial as well as
open‐source exploitation frameworks are The Metasploit Project, Core Security, Technologyʹs Impact,
Immunityʹs CANVAS. It is advised to make full use of the potential of such frameworks, rather than
28
using it for merely running exploits. These frameworks can help reduce a lot of time in writing
custom exploits.
Quite often, successful exploitation of a vulnerability might not lead to root (administrative) access. In
such a scenario additional steps need to be taken, further analysis is required to access the risk, that
particular vulnerability may cause to the target system.
3.6 Importance of reconnaissance
When performing a penetration test or a live attack, it is very crucial to give enough emphasis on
reconnaissance. Many times the information collected during the recon phase plays critical role during
exploitation as well as post-exploitation phase of a penetration testing or a white box hacking.
Sometimes recon can go beyond collecting basic information to understand the system and can also
identify information which might straight away lead to exploitation, that too sometimes without
actually touching the entity being tested. Even after having such significance this phase is not given
enough importance and most of the tests focus straight away on exploitation. The key point here is
that exploitation is certainly important but performing a thorough recon could prove very helpful in it
and also make it easier, faster and stealthier.
Depending upon the entity under assessment the information that is to be collected changes, for
example in case of a web application identifying the CMS version and the third party libraries being
used can help a lot; similarly for a network identifying the open ports and the services running on
29
them is a core requirement. There are a variety of tools which can perform these functions and hence
plays a huge role in giving a favorable outcome whether it’s a penetration testing or live attacks.
Tools that can bring the best out of recon phase are Maltego, Recon-ng, Wappalyzer, Shodan and
many more. Recon phase should be given equal importance as much as exploitation phase because it
basically helps us to understand deep and thoroughly about the target system and it’s mechanisms.
30
Reference
1) https://misterscanner.com/open-source-web-application-firewall
2) https://www.lepide.com/blog/the-15-most-common-types-of-cyber-attacks/
3) https://blog.netwrix.com/2018/05/15/top-10-most-common-types-of-cyber-attacks/
4) https://www.w3.org/Security/wiki/Content_Security_Policy
5) https://blog.securityinnovation.com/a-simple-explanation-of-cross-site-scripting
6) https://portswigger.net/web-security/cross-site-scripting
31