The XSS vulnerability is possible because data received from one user and sent to another can contain not only text but also JavaScript scripts, links to other documents, and other data fraught with danger.

Thus, a malicious person can use a vulnerable system to execute HTML code on the computer of any user (sometimes of a target user) of the system. The code will be executed within the vulnerable system because, in regard to security, the user's browser will treat this code like any other document in this system. Most users set in their browsers the same security level for all sites.

In most cases, a malicious user can execute any JavaScript code on a vulnerable site so that he or she can access cookies on the site. So, the XSS vulnerability allows an attacker to execute system scripts on the clients and not on the server.

In a variant of an XSS attack, the target user is advised to follow a link. If he or she does so, some malicious code inside the URL address will be executed on the target site.

Consider a simple example. This is a guest book, in which a message added by one user can be viewed by others.


 <?     $name=$_POST['name'];     $message=$_POST['message'];     $mode=$_POST['mode'];     $err="";     if($mode=='add')     {       if(empty($name) && empty($message)) $err.="<font color=red>name and    message are empty</font><br>";       elseif(empty($name)) $err.="<font color=red>name is not    specified</font><br>";       elseif(empty($message)) $err.="<font color=red>message is    empty</font><br>";       else       {         $f=fopen("1.txt", "a");         $d=date("Y-m-d H:i:s");         $m="         <b>added $d, user: $name<br></b>         <i>         $message         </i><br><br>         ";         fwrite($f, $m);         fclose($f);       }     }     echo "<html><body>     $err     <center><b>guest book</b></center>     ";     $f=fopen("l.txt", "r"); // The file name is fixed; therefore,                             // tricks with the file name are impossible.     while($r=fread($f, 1024))        echo $r;     fclose($f);     echo "<hr>     add a message:<br>     <form method=POST>     <input type=hidden name=node value=add>     name: <input type=text name=name><br>     message:<br>     <textarea name=message cols=50 rows=6></textarea><br>     <input type=submit value=Add>     </form>     </body>     </html>     ";    ?> 

The logic of this script is the following: At the beginning, the script checks whether data were sent using the HTTP POST method. If they were, it passes control to a block of code that adds the data to a file. The block checks whether the name or message are empty. If either or both aren't specified, an error message is displayed.

When the fields aren't empty, the image from book  1.TXT file, which contains messages and is located in the same folder, is opened for appending data. Then a message based on the received data is generated. No additional data processing takes place before the data entered by a user are written to the file. After the data are appended, the file is closed, and the block terminates.

The next portion of the script is executed regardless of whether data were sent and whether errors were detected in the data. The image from book  1.TXT file that contains all guest book messages is opened for reading, read, and displayed in the browser window. Then the file is closed.

After that, a form allowing a user to enter a name and a message is displayed in the browser window. The form contains a hidden parameter, mode , that informs the script whether data were sent. After the form is displayed, the script execution terminates.

This script works as follows : If a user simply accesses the script using the HTTP GET method, that is, if no POST parameters are sent to the script, the block adding messages to the file isn't executed. Rather, the portion of the script that displays all messages and the form is executed.

Then, if the user decides to add a message to the guest book, he or she enters a name and a message into the form, and sends the data. The data are sent using the POST method. The mode = add parameter is simultaneously sent using the POST method to inform the script that the data have been sent. The block adding messages to the file is executed. If the name and message aren't empty, they are added to the file. Then all guest book messages are displayed.

Consider this script from the security point of view. As in any other case, a potentially dangerous component of the system is the block that works with the file.

However, the functions that open the file for writing and reading get a constant file name. Therefore, an attacker won't be able to change the name of the file being opened.

The contents of the file are displayed unchanged in the browser window. This doesn't allow the attacker to include in the file any commands that could be executed by the server.

At this point, I'd like to mention that a programmer of a similar script would make a mistake if he or she just included the file as a PHP script rather than used the fopen() and fread() functions. This could look as shown in the next fragment.

A fragment of http://localhost/5/1.php

 echo "<html><body>    $err    <center><b>guest book</b></center>    ";    include("1.txt");    echo "<hr>    add a message:<br>    <form method=POST> 

The programmer could erroneously assume that a file with a TXT extension didn't contain PHP commands. However, as I said earlier, the extension of a script included in PHP code doesn't matter. If the script contains PHP tags (e.g., <?, ?>, and a few others), the text within the tags will be executed as PHP code. The attacker can embed PHP code into a message or a name by enclosing the code in the tags <? and ?> .

However, the script being examined is free from that error. The contents of the image from book  1.TXT file are displayed with the fopen() and fread() functions. Therefore, the script doesn't present a direct threat to the system's security.

Nevertheless, you can easily make sure that the script has undocumented features that can be used by the attacker. To prove this, send the following message to the guest book:

 test <b>test</b>,    <font color=red>test</font>,    <font size=+2>TEST</font>    <!-- this is a comment --> 

You can see that the browser displays the result of applying the HTML tags and not the message. The comment isn't displayed.

These obvious undocumented features seem harmless. Now, remember JavaScript and add the following message to the guest book

 test JavaScript    <script Language=JavaScript>    alert('Hello');    </script> 

This message isn't so innocent as the previous. The alert message will appear repeatedly until the system administrator edits the image from book  1.TXT file to delete the message.

This is just an example. If the attacker can use JavaScript, he or she can do much harm.

The possibility to use this vulnerability depends on execution of the code by the browser, that is, on the client. In some cases, the code can be executed by the target user's browser; in other cases, it will be executed by any browser that visits the page.

The XSS vulnerability can be exploited regardless of the method used to store data on the server: in files, in a database, or in an other way.

Again, the XSS vulnerability is possible because data entered by one user are displayed for others without additional checks or filtration. Consider another example.


 <?     $sid=$_GET['sid'];     $page=$_GET['page'];     if(empty($sid)) $sid=md5(uniqid(rand(),1));     echo "     <html>     <body>     <a href=2.php?sid=$sid>Main</a>     <a href=2.php?page=1&sid=$sid>The first</a>     <a href=2.php?page=2&sid=$sid>The second</a>     <a href=2.php?page=3&sid=$sid>The third</a>     <br>     ";     if(empty($page))       echo "This is the main page. Please, select a link in the above list";    if ($page==1)       echo "This is the first page";     if($page==2)       echo "This is the second page";     if($page==3)       echo "This is the third page";     echo "     </body>     </html>     ";    ?> 

In this example, no data are stored on the server. The script outputs some text depending on the received GET parameter ( page ).

However, the danger hidden in this script is of another type.

Note the other GET parameter, sid . It is used to track the user's movements over the site. Such a practice is common.

You can see that if the parameter wasn't sent, it is generated pseudorandomly. If it was sent when moving to another page, it is used again. Thus, the identifier is generated once and then bound to a particular user. In other words, information sent as the GET parameter sid is then passed in GET parameters of all links on the page.

To check this, examine the links on the subsequent pages:

  • http://localhost/5/2.php?sid=aaaaaaaaaaaa

  • http://localhost/5/2.php?sid=bbbbbbbbbbb%20cccccccccc

As a result of the first request, the page will contain links to the following pages

  • http://localhost/5/2.php?sid=aaaaaaaaaaaa

  • http://localhost/5/2.php?page=1&sid=aaaaaaaaaaaa

  • http://localhost/5/2.php?page=2&sid=aaaaaaaaaaaa

  • http://localhost/5/2.php?page=3&sid=aaaaaaaaaaaa

As a result of the second request, the page will contain links to the following pages:

  • http://localhost/5/2.php?sid=bbbbbbbbbbb

  • http://localhost/5/2.php?page=1&sid=bbbbbbbbbbb

  • http://localhost/5/2.php?page=2&sid=bbbbbbbbbbb

  • http://localhost/5/2.php?page=3&sid=bbbbbbbbbbb

The portion after the %20 character sequence was lost. Note that this sequence codes a space character. This response of the system isn't documented; therefore, it is fraught with danger.

To understand this, examine the HTML code generated in the second request.


 <html>    <body>    <a href=2.php?sid=bbbbbbbbbbb cccccccccc>Main</a>    <a href=2.php?page=l&sid=bbbbbbbbbbb cccccccccc>The first</a>    <a href=2.php?page=2&sid=bbbbbbbbbbb cccccccccc>The second</a>    <a href=2.php?page=3&sid=bbbbbbbbbbb cccccccccc>The third</a>    <br>    This is the main page. Please, select a link in the above list.    </body>    </html> 

You can see that the decoded value in the sid parameter (a space instead of the %20 sequence) was inserted after sid= . In other words, the received value in the sid parameter was inserted into the HTML page without filtration. To be more precise it was inserted as follows:

 <a href=...sid=$sid>...</a> 

Even if the attacker doesn't know the code of the script but just examines the code of the returned HTML pages, he or she will be able to create an HTTP request depending on the sid value so that malicious code is executed on the computer of the user who made this request. In this example, the attacker would insert a value of the sid parameter, close the <a> tag, and insert his or her malicious code. Then the attacker would put a tag without a > bracket so that the < bracket of the original tag, a , closes the tag placed by the attacker.

For example, the attacker could insert the following sid value:


Here, the </script> tag is missing a closing bracket so that the bracket intended to close the <a> tag actually closes the </script> tag. Then the attacker would URL-encode a few characters and send the link to a target user. When the latter follows the link, the malicious JavaScript code will execute on his or her computer in the context of the target site.

In this example, the malicious link could look as follows:


To summarize, the XSS vulnerability can be either of two types:

  • Information entered by a user is stored on the server and then sent to other users without filtration.

  • Some parameters of an HTTP request are output to an HTML page without filtration. It doesn't matter whether this information is stored on the server and whether it is output elsewhere.

Hacker Web Exploition Uncovered
Hacker Web Exploition Uncovered
ISBN: 1931769494
Year: 2005
Pages: 77 © 2008-2017.
If you may any questions please contact us: