Jakub Korab

I have recently had a requirement in a web application for a WYSIWYG editor as a textarea replacement. Having taken a quick look at some popular Ajax toolkits for the job, it seems that while they all perform to a greater or lesser extent as advertised, it seems that security issues, in particular XSS attacks, were not at the forefront of the developers minds. Dojo in particular has an Editor widget (http://dojotoolkit.org/docs/rich_text.html) that sends an HTML string over the wire when the form is submitted. Let’s examine a standard use case:

• 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.

The biggest problem I’ve encountered in the past is something that sends shivers down the spine of most IT professionals - the dreaded question of how long a piece of work is going to take. I’m not talking about quoting for year long projects - they’re a whole different kettle of fish - but about the tasks that you have to do that are on the project plan. Software development is inherently dealing with unknown quantities - new technologies, unencountered bugs, changing requirements… the list seems to be unending. No two projects ever seem to be the same yet you are expected to give an accurate estimate every time. Even the meaning of the word changes depending on who is using it - programmer “best guess based on available understanding of the problem”, client/PM “fixed quote cast in concrete”.

The Software Engineering Profession has waxed lyrical on the topic for years, yet there is still no easily applicable model. Yes, there are tools such as function points and Cocomo, but they are no help for the most part. Heavy, complex, don’t take the nuances of the technology into account and they’re not really useful at the day-to-day scale of estimating. Is a web database system going to take the same amount of time to complete whether you use standalone JDBC, Spring templates, Hibernate or Ruby on Rails? Is it going to take the same amount of time to complete regardless of whether you are using the stable version of your favourite open-source package, or the new one with those brand new time-saving features you just have to use? No.

I approach the problem as per the XP boys. Implement a slice of functionality using the software stack, work out your “velocity” and extrapolate to a larger scale. In order to work out how long the work is taking I use a tool called ToDoList (http://www.abstractspoon.com/tdl_resources.html). Break down a task into it’s various steps and time how long each one takes. You can then base estimates of future work using the same technology by looking back on the task list for previous projects. It’s a variation on estimation
by experience, but slightly more formal since you’re not relying on memory. It would be interesting to see whether a larger resource that would let you see how long other people took to complete similar tasks would help, or whether it’s an inherently personal thing. My guess is the latter, which makes keeping a record of previous work all the more important. It’s not a panacea, but it will help.

It’s great to see when your work finally gets up and running and people start using it. I’ve been doing some work on http://www.milkround.ie, a graduate recruitment website, for a little while now and the first draft version went up and had the kinks ironed out before Christmas. Now back from holidays, it’s good to see a substantial number of subscribers. It will be interesting to see how the project develops over the coming months.