What Is Cross-site Scripting?

What Is Cross-site Scripting?

A cross-site scripting attack is a kind of attack on web applications in which attackers try to inject malicious scripts to perform malicious actions on trusted websites. In cross-site scripting, malicious code executes on the browser side and affects users. Cross-site scripting is also known as an XSS attack. The first question that comes in mind is why we call it “XSS” instead of “CSS.” The answer is simple and known to all who work in web development. In web design, we have cascading style sheet s (CSS). So cross-site scripting is called XSS so it does not get confused with CSS.

The consequences of malicious JavaScript

Among many other things, the ability to execute arbitrary JavaScript in another user's browser allows an attacker to perform the following types of attacks:

• Cookie theft -The attacker can access the victim's cookies associated with the website using document.cookie, send them to his own server, and use them to extract sensitive information like session IDs.
• Keylogging -The attacker can register a keyboard event listener using addEventListener and then send all of the user's keystrokes to his own server, potentially recording sensitive information such as passwords and credit card numbers.
• Phishing -The attacker can insert a fake login form into the page using DOM manipulation, set the form's action attribute to target his own server, and then trick the user into submitting sensitive information.

Although these attacks differ significantly, they all have one crucial similarity: because the attacker has injected code into a page served by the website, the malicious JavaScript is executed in the context of that website. This means that it is treated like any other script from that website: it has access to the victim's data for that website (such as cookies) and the host name shown in the URL bar will be that of the website. For all intents and purposes, the script is considered a legitimate part of the website, allowing it to do anything that the actual website can.

This fact highlights a key issue:

If an attacker can use your website to execute arbitrary JavaScript in another user's browser, the security of your website and its users has been compromised.

Types of Cross-site Scripting Attack

• Non-Persistent Cross-site scripting attack
• Persistent cross-site scripting attack
• DOM-based cross-site scripting attack

What is a reflected XSS attack

Reflected XSS attacks, also known as non-persistent attacks, occur when a malicious script is reflected off of a web application to the victim’s browser.At first, reflected XSS might seem harmless because it requires the victim himself to actually send a request containing a malicious string. Since nobody would willingly attack himself, there seems to be no way of actually performing the attack.

As it turns out, there are at least two common ways of causing a victim to launch a reflected XSS attack against himself:

• If the user targets a specific individual, the attacker can send the malicious URL to the victim (using e-mail or instant messaging, for example) and trick him into visiting it.
• If the user targets a large group of people, the attacker can publish a link to the malicious URL (on his own website or on a social network, for example) and wait for visitors to click it.

. The vulnerability is typically a result of incoming requests not being sufficiently sanitized, which allows for the manipulation of a web application’s functions and the activation of malicious scripts.

Unlike a stored attack, where the perpetrator must locate a website that allows for permanent injection of malicious scripts, reflected attacks only require that the malicious script be embedded into a link. That being said, in order for the attack to be successful, the user needs to click on the infected link.

As such, there are a number of key differences between reflected and stored XSS attacks, including:

• Reflected attacks are more common.
• Reflected attacks do not have the same reach as stored XSS attacks.
• Reflected attacks can be avoided by vigilant users.

With a reflected XSS, the perpetrator plays a “numbers game” by sending the malicious link to as many users as possible, thereby improving his odds of successfully executing the attack.

Reflected XSS attack prevention and mitigation

There are several effective methods for preventing and mitigating reflected XSS attacks.

First and foremost, from the user’s point-of-view, vigilance is the best way to avoid XSS scripting. Specifically, this means not clicking on suspicious links which may contain malicious code. Suspicious links include those found in:

• Emails from unknown senders
• A website’s comments section
• Social media feed of unknown users

Having said that, it is ultimately up to a website operator to prevent potential abuse to their users.

Additionally, web application firewalls (WAFs) also play an important role in mitigating reflected XSS attacks.With signature based security rules(Essentially, the system can be configured to look for specific patterns, known to be malicious, and block the traffic. This would help with something like the Code Red worm, for example. If packets destined for your Web server (on port 80) are found to be Code Red packets, they could be dropped while allowing normal Web requests to continue through to the server ), supported by other heuristics, a WAF can compensate for the lack of input sanitation, and simply block abnormal requests. This includes, but is not limited to, requests that attempt to execute a reflected cross site scripting attack.

unlike in a stored attack, where the perpetrator’s malicious requests to a website are blocked, in a reflected XSS attack, it’s the user’s requests that are blocked. This is done to protect the user, as well as to prevent collateral damage to all other website visitors.

What is Persistent cross site scripting attack ?

The most damaging type of XSS is Stored XSS (Persistent XSS). An attacker uses Stored XSS to inject malicious content (referred to as the payload), most often JavaScript code, into the target application. If there is no input validation, this malicious code is permanently stored (persisted) by the target application, for example within a database. For example, an attacker may enter a malicious script into a user input field such as a blog comment field or in a forum post.

When a victim opens the affected web page in a browser, the XSS attack payload is served to the victim’s browser as part of the HTML code (just like a legitimate comment would). This means that victims will end up executing the malicious script once the page is viewed in their browser.

DOM-Based XSS

As web applications become more advanced, an increasing amount of HTML is generated by JavaScript on the client-side rather than by the server. Any time content needs to be changed without refreshing the entire page, the update must be performed using JavaScript. Most notably, this is the case when a page is updated after an AJAX request.

This means that XSS vulnerabilities can be present not only in your website's server-side code, but also in your website's client-side JavaScript code. Consequently, even with completely secure server-side code, the client-side code might still unsafely include user input in a DOM update after the page has loaded. If this happens, the client-side code has enabled an XSS attack through no fault of the server-side code.

A Document Object Model (DOM) is an API that defines the logical structure of HTML and XML documents. The DOM represents the page so programs can change the document content, style and structure. DOM-based attacks occur when a web app writes data to the DOM before proper data sanitization occurs. If an attacker manages to modify the DOM environment with a malicious payload, the client-side code will execute that payload when the compromised script runs. Unlike request or response models of XSS, DOM-based attacks can be complex to troubleshoot because they involve in-depth analysis of code flow

However, JavaScript that handles data insecurely can enable various attacks. DOM-based vulnerabilities arise when a website contains JavaScript that takes an attacker-controllable value, known as a source, and passes it into a dangerous function, known as a sink.

Terms

Source

A source is a JavaScript property that accepts data that is potentially attacker-controlled. An example of a source is the location.search property because it reads input from the query string, which is relatively simple for an attacker to control. Ultimately, any property that can be controlled by the attacker is a potential source. This includes the referring URL (exposed by the document.referrer string), the user's cookies (exposed by the document.cookie string), and web messages.

Examples:

• document.URL
• document.documentURI
• document.URLUnencoded
• document.baseURI
• location
• document.cookie
• document.referrer
• window.name
• history.pushState
• history.replaceState
• localStorage
• sessionStorage
• IndexedDB (mozIndexedDB, webkitIndexedDB, msIndexedDB)
• Database

Sinks

A sink is a potentially dangerous JavaScript function or DOM object that can cause undesirable effects if attacker-controlled data is passed to it. For example, the eval() function is a sink because it processes the argument that is passed to it as JavaScript. An example of an HTML sink is document.body.innerHTML because it potentially allows an attacker to inject malicious HTML and execute arbitrary JavaScript.

Examples

• HTML Modification sinks
• document.write
• (element).innerHTML
• HTML modification to behaviour change
• (element).src (in certain elements)
• Execution Related sinks
• eval
• setTimout / setInterval
• execScript

Server Side Filters Do Not Matter

One of the biggest differences between DOM Based XSS and Reflected or Stored XSS vulnerabilities is that DOM Based XSS cannot be stopped by server-side filters. The reason is quite simple; anything written after the "#" (hash) will never be sent to the server.

Historically, fragment identified a.k.a. hash introduced to simply scroll the HTML page to a certain element however later on it was adopted by JavaScript developers to be used in AJAX pages to keep track of the pages and various other things, mostly referred as hash-bang "#!".

Due to this design anything after hash won't be sent to the server. This means all server-side protection in the code will not work for DOM Based XSS vulnerabilities. As a matter of fact, any other type of web protections such as web application firewalls, or generic framework protections will not protect you against DOM Based XSS attacks.

However in our case, we don't have plain html and following, proper mvc so Server-filter will work for us. 

Protection tools

a). OWASP Encoding Project : It is a library written in Java that is developed by the Open Web Application Security Project(OWASP). It is free, open source and easy to use.

b). The “X-XSS-Protection” Header : This header instructs the browser to activate the inbuilt XSS auditor to identify and block any XSS attempts against the user.

c). The XSS Protection Cheat Sheet by OWASP : This resource enlists rules to be followed during development with proper examples. The rules cover a large variety of cases where a developer can miss something that can lead to the website being vulnerable to XSS.

d). Content Security Policy : It is a stand-alone solution for XSS like problems, it instructs the browser about “safe” sources apart from which no script should be executed from any origin.

Detect Unsafe Code Using Development Tools

Google has released a Chrome plug-in that can identify insecure practices commonly found in client-side code