Why Cross Site Scripting Is Detrimental And How To Prevent?

August 28, 2019
Tanzina

What is Cross-site scripting (XSS)

Cross-site scripting (XSS) is a type of computer security vulnerability in which an attacker injects data, such as a malicious script into content from otherwise trusted websites. In other words, it gives hackers control of your browser, allowing them to do whatever you want to do through your browser, remotely. Cross-site scripting attacks can happen when an untrusted source is allowed to inject its own code into a web application. 

Malicious scripts are often supplied by the victim’s browser in the form of bits of JavaScript code, but exploits can integrate malicious executable code into many other languages, including Java, Ajax, Flash, and HTML. Cross-site scripting attacks can be very severe, but it is comparatively simple to mitigate the vulnerabilities that allow such attacks.

Cross-site scripting enables an attacker in another user’s browser to execute malicious scripts. The attacker, however, does not directly attack the victim. Instead, the attacker exploits a vulnerability on a victim’s website and gets the website to deliver the malicious script for the attacker.

What is Cross -site Scripting (XSS)

Types of XSS vulnerabilities

There are mainly three types of cross-site scripting vulnerabilities. They are:

  1. Stored XSS
  2. Reflected XSS and
  3. DOM-based XSS

Stored XSS

The most harmful type of cross-site scripting attack is stored (persistent) XSS. A script is injected by the attacker, also called the payload. On the target application, such as a database, it is permanently stored. For example, an attacker inserts a malicious script on a blog, in a forum post or in a comment field.

The XSS payload will then be served as part of a webpage when the victim navigates to the affected webpage in a browser. Then, once the victim views the page in a browser, he will end up inadvertently executing the malicious script.

Reflected XSS

Reflected XSS is the most frequent type of vulnerability in cross-site scripting. In this type of attack, the attacker has to deliver the payload to the victim. Therefore, the attacker’s payload script must be part of the request sent to the webserver. Then it will be reflected back to the HTTP response includes the payload from the HTTP request.

The attacker uses phishing emails and other social engineering methods to lure the victim to inadvertently make a request to the server that includes the XSS payload. The victim then runs the script inside the browser that is reflected and executed. Since reflected XSS is not a constant attack, each victim must be provided with the payload by the attacker.

DOM-based XSS

An advanced type of XSS attack is the DOM-based cross-site scripting. It happens when the client-side script of the web application writes user-provided data to the Document Object Model (DOM).

The web application then reads the data from the DOM and delivers it to the browser. If the data isn’t handled correctly, the attacker is able to inject a payload that will be stored as part of the DOM. After the data is read back from the DOM, the payload will be executed.

Impact of XSS vulnerabilities

An attacker who exploits a cross-site scripting vulnerability is typically able to:

  • Impersonate or masquerade as the victim user
  • Carry out any action that the user is able to perform
  • Read any data that the user is able to access
  • Capture the user’s login credentials
  • Perform virtual defacement of the website
  • Inject Trojan functionality into the website

The actual impact of the attack generally depends on the nature of the application, its functionality and data, and the status of the compromised user. For example:

  • In a brochureware application, where all users are anonymous and all information is public, the impact will often be minimal.
  • In an application holding sensitive data, such as banking transactions, emails, or healthcare records, the impact will usually be serious.
  • If the compromised user has elevated privileges within the application, then the impact will generally be critical, allowing the attacker to take full control of the vulnerable application and compromise all users and their data.

Preventing XSS Vulnerabilities

To prevent XSS security vulnerabilities it is very important to apply a context-dependent output encoding. In some cases, encoding special HTML characters, such as opening and closing tags, may be sufficient. A correctly applied URL encoding is needed in other cases. Links should generally be disallowed if they don’t begin with a whitelisted protocol such as http:// or https://, thus preventing the use of URI schemes such as javascript://.

Although most modern web browsers have an integrated XSS filter, it should not be considered an alternative to sanitization. They are unable to capture all types of attacks on cross-site scripting and are not strict. So they may lead to false positives, which would prevent the proper loading of some pages. The XSS filter of a web browser should only be a “second line of defense” with the concept of minimizing the effect of current vulnerabilities.

Developers should not use blacklists as there is a variety of bypasses for them. Another thing they should avoid using is the stripping of harmful functions and characters as the XSS filters of browsers can not identify the dangerous payloads when the output is manipulated to allow possible bypasses. That being said, as mentioned above, XSS’s only recommended prevention is encoding.

The most precise way to prevent XSS vulnerabilities is using “XXSS protection header” and “XSS filter”. Developers should use the filtering code based on different programming languages. If the language is Java then it should be used “XSS filter”, and the code is given below,

package com.edw; 

import org.owasp.esapi.ESAPI; 

import org.jsoup.Jsoup; 

import org.jsoup.safety.Whitelist;


public final class XssFilter {

          /** 

          * Strips any potential XSS threats out of the value 

          * @param value 

         * @return 

         */

         public String filter( String value ) {

                if( value == null ) 

               return null;

               // Use the ESAPI library to avoid encoded attacks. 

               value = ESAPI.encoder().canonicalize( value );

              // Avoid null characters 

              value = value.replaceAll("\0", "");

             // Clean out HTML 

             value = Jsoup.clean( value, Whitelist.none() );

             return value; 

             } 

      }

If the language is PHP then it should be used “XXSS Protection Header”, and the code is given below,

<?php
//In order to set the XXSSProtection header, you'll have to add the following code to the head of your application:
header(“XXSSProtection:1; mode=block”);
?>

If the language is ruby then it should be used “XXSS Protection Header”, and the code is given below,

// Ruby on Rails sets XXSSProtection header with "1; mode=block" option  by default. 

// If in your case it doesn't, you can add the header manually. 

// Add the following code to APP_DIR/config/environments/production.rb 

config.action_dispatch.default_headers = { 

'XXSSProtection' => '1; mode=block' 

}

If the language is asp.net then it should be used “XXSS Protection Header”, and the code is given below,

/* In order to set the XXSSProtection header, you'll have to add the following code to the head of your application, the following code could be used in your controller:*/ 
Response.AppendHeader("XXSSProtection:1", "mode=block");  
/* In your classes you can use the following code:*/  
HttpContext.Current.Response.AppendHeader("XXSSProtection:1", "mode=block");

Contributor: Md Abdul Monim, Nascenia

No comments

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.