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