• User fills in a form, formatting a text area using the widget.
• The form is submitted and the contents saved in a database.
• The content is served up at a later date.

This is a prime candidate for an XSS attack. These attacks are essentially about injecting malicious code which instructs the user’s browser to act in a particular way. The implications can be a bit scary. Imagine that someone sends HTML through your form to the server that contains JavaScript code to redirect the user to another site. When the server displays the malicious content to a user, they are redirected to a site that looks like the one they came from, and prompts the user for their username and password. The user re-enters their details to log in – and their credentials have been stolen.

So why does the widget expose you to this sort of attack? The user can only use the buttons available to the to format text, and any code that they type in directly into the editor will be escaped – so the user’s

<script language="JavaScript">window.location = maliciousSite;</script>

will become:

&lt;script language="javascript"&gt;window.location = maliciousSite;&lt;/script&gt;

The problem with that is that a bad guy won’t be using your nice interface. They view the form, see that it’s sending HTML and simply craft a request with the malicious code. If your application blindly accepts the input, you are vulnerable. Server side validation helps, but to hand-craft a catch-all validation mechanism that accepts only certain HTML tags is a non-trivial task (especially on a deadline). This approach is also potentially flawed as your validations will inevitably allow certain cases through to the exclusion of others (such as allowing <strong> but not <script>) – see http://www.owasp.org/index.php/Positive_security_model as to why this is a bad idea.

A better option (though not a replacement for validation, which you should apply all the time anyway – but you already do this, right?) would be to use a widget which does not send potentially nasty characters, or to modify the Editor widget to escape the HTML stream in some way (such as into a wiki format) before sending. In the use case above, you would need to apply custom formatting on the server for the text to be displayed as intended by the user when it is served up again.

The Open Web Application Security Project maintain a list of security principles (http://www.owasp.org/index.php/Category:Principle) that you should keep in mind when developing web apps.