Post
Ask Question

Cross-Site Scripting (XSS)

This is a series of Security related articles I wrote. This article is the first one.

Introduction

Cross-site scripting (XSS) is a type of security vulnerability that can be found in some web applications. XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy.

Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec up until 2007. [ref]

This is the structure of this article,

  • Introduction
  • A - What is Cross-Site Scripting (XSS)
  • B - How does XSS Work
  • C - Why Cross-Site Scripting attacks are possible
  • D - Impacts of a XSS Vulnerability
  • E - What are the types of XSS attacks?

A - What is Cross-Site Scripting (XSS)

Cross-site Scripting (XSS) is a client-side code injection attack. The attacker aims to execute malicious scripts in a web browser of the victim by including malicious code in a legitimate web page or web application. Cross-site scripting vulnerabilities normally allow an attacker to masquerade as a victim user, to carry out any actions that the user is able to perform, and to access any of the user's data. If the victim user has privileged access within the application, then the attacker might be able to gain full control over all of the application's functionality and data.

The points are that attacher can

  • Access the Client Web Browser;
  • Excute the malicious code on the Browser.
  • Access and Control the App's Functionality and data

B - How does XSS Work

Cross-site scripting works by manipulating a vulnerable website so that it returns malicious JavaScript to users. When the malicious code executes inside a victim's browser, the attacker can fully compromise their interaction with the application.

C - Why Cross-Site Scripting attacks are possible

XSS attacks are injection attacks that insert malicious script code into a web page processed by a user’s browser. The “cross-site” part means that the attack code has a different origin than the visited site. Normally, this should be impossible due to same-origin policy (SOP) – a fundamental browser security feature that only allows web applications to load scripts that have the same origin.

Note:

For the purpose of same-origin policy and XSS, two sites have the same origin if they have the same protocol (URI scheme, such as https://), host name (such as www.example.com), and port number (usually omitted in website URLs). [see: CORS (1), Consume .NET Core Web API By MVC in Same Origin]

A web page that is vulnerable to cross-site scripting uses unsanitized user input to dynamically build its HTML code. If this input contains a malicious script, the script will be included in the page code and executed by the browser in the current context (because it now originates from the same web page). This opens the way to a wide variety of script-based attacks.

D - Impacts of a XSS Vulnerability

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 web site.
  • Inject trojan functionality into the web site.

E - What are the types of XSS attacks?

There are three main types of XSS attacks. These are:

  • Reflected XSS, where the malicious script comes from the current HTTP request.
  • Stored XSS, where the malicious script comes from the website's database.
  • DOM-based XSS, where the vulnerability exists in client-side code rather than server-side code.

Reflected cross-site scripting

Reflected XSS is the simplest variety of cross-site scripting. It arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.

Here is a simple example of a reflected XSS vulnerability:

https://insecure-website.com/status?message=All+is+well. <p>Status: All is well.</p>

The application doesn't perform any other processing of the data, so an attacker can easily construct an attack like this:

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script> <p>Status: <script>/* Bad stuff here... */</script></p>

If the user visits the URL constructed by the attacker, then the attacker's script executes in the user's browser, in the context of that user's session with the application. At that point, the script can carry out any action, and retrieve any data, to which the user has access.

Stored cross-site scripting

Stored XSS (also known as persistent or second-order XSS) arises when an application receives data from an untrusted source and includes that data within its later HTTP responses in an unsafe way.

The data in question might be submitted to the application via HTTP requests; for example, comments on a blog post, user nicknames in a chat room, or contact details on a customer order. In other cases, the data might arrive from other untrusted sources; for example, a webmail application displaying messages received over SMTP, a marketing application displaying social media posts, or a network monitoring application displaying packet data from network traffic.

Here is a simple example of a stored XSS vulnerability. A message board application lets users submit messages, which are displayed to other users:

<p>Hello, this is my message!</p>

The application doesn't perform any other processing of the data, so an attacker can easily send a message that attacks other users:

<p><script>/* Bad stuff here... */</script></p>

DOM-based cross-site scripting

DOM-based XSS (also known as DOM XSS) arises when an application contains some client-side JavaScript that processes data from an untrusted source in an unsafe way, usually by writing the data back to the DOM.

In the following example, an application uses some JavaScript to read the value from an input field and write that value to an element within the HTML:

var search = document.getElementById('search').value;

var results = document.getElementById('results');

results.innerHTML = 'You searched for: ' + search;

If the attacker can control the value of the input field, they can easily construct a malicious value that causes their own script to execute:

You searched for: <img src=1 onerror='/* Bad stuff here... */'>

In a typical case, the input field would be populated from part of the HTTP request, such as a URL query string parameter, allowing the attacker to deliver an attack using a malicious URL, in the same manner as reflected XSS.

Reference


Similar Articles