Twitter's status blog this morning announced that Twitter has addressed the most recent variant of the Mikeyy worm but recommends that you still avoid viewing the profiles of users posting "uncharacteristic or otherwise suspicious tweets."

It shouldn't be this hard, Peter Soderling, founder of Stratus Security told ReadWriteWeb yesterday. "It appears Twitter is solving the problem by focusing on the input filtering, but a simpler and more effective solution would have been to focus on output escaping; encoding the script tags so they could not execute in any victim's browser."

Web application development 101: You want to output something that the user has provided? Escape all of that data so that it is harmless. But what does this really mean in plain English?

Input Filtering in Plain English

Input filtering is the way in which developers validate data coming into their applications, and thwart any invalid, incorrect or malicious data from being used or executed.

Typically, when an application needs a user to input data, the site will offer a form, containing one or more fields.

For instance, Twitter users have the ability to input data in a variety of places within their settings. From the obvious - such as in the account tab - where you can type in your name, username, e-mail, URL, bio, location etc., to the less obvious such as the 'change design colors' that allows you to enter data to specify color.

As a result, all of these fields need to be 'filtered' by the site - not just by making the input validation 'nice' for the user [as described below], but making it safe on the server.

From a user point of view, when you go to change the background color for example, Twitter has ensured you can only input 6 hexadecimal characters; that is, the letters A through F and the digits 0 through 9.

While this may provide users with a sense of relief that nothing malicious can be 'injected' into this field, it may also be providing a false sense of security if Twitter is not filtering the input on its servers.

Here's why.

When you hit the 'save changes' button after you have input your data, your browser sends that information to Twitter's server, which in turn will then store that information.

But what if the information Twitter's server receives tells it to do something malicious? And, what if Twitter's server thinks that the information it has received was from the form where nothing 'bad' can be entered? This is what Mikeyy did. "It basically let me do anything I want within a browser on their Web site," Michael Mooney, the worm's creator, told Andy Sorcini in an interview last week.

Think of it this way. You're sending ReadWriteWeb a letter via snail mail. The postman steams it open, rewrites it and delivers it to us. The information we receive, while still appearing to come from you, may have nothing to do with the original information you sent us.

But how do you send information to Web apps without entering them in the specified fields? Simple, if you have the tools. Programs such as Paros, a security tool created for Web application vulnerability assessment also allows those who are tech savvy enough to monitor, intercept and modify the data being sent to Twitter before it hits Twitter's server.

Of course, this means Twitter is now storing information - not about a color, but potentially, instructions to do something malicious.

Input Filtering at a Server Level

When Twitter's server receives a request (such as to change the background color), it must validate that the information received corresponds to the values Twitter has assigned to it. Continuing with the color example, it must validate that only hexadecimal data has been received.

Clearly, Twitter did not do this from the get-go and is now furiously chasing input vulnerabilities that may be sprinkled in a variety of places within its code; patching them as it finds them; a long, painful and tedious process when done retrospectively.

Think of it this way. A mouse is in your house. You search to find the hole in the floor and you plug it. Then you find another mouse. Again, you search for the hole and plug it. This can go on indefinitely. However, had you, during the building stage, put down a concrete floor, there would be zero chance of mice living under your house, and fewer ways they could get in.

"Understanding why and where to filter is more important than understanding how," Chris Shiflett, CTO of OmniTI explains. "It's important to appreciate just how easily a form submission can be spoofed, so that you realize that absolutely nothing about the client's request can be blindly trusted." He has written a good technical overview on input filtering if you are interested in learning more.

The Flip Side of the Coin: Output Escaping

Output escaping, much like input filtering, is an additional precaution that developers can take when creating Web applications.

According to Soderling, it effectively renders any malicious code that is stored in a database useless.

Rather than focus on plugging holes in the input one by one, Soderling suggest Twitter focus on escaping outputs, which is easier from a developer point of view because it effectively requires only five steps to implement.

So simple in fact, that PHP, a common programming language, has created htmlspecialchars to automate this process in the PHP world.

"All Twitter needs to do is code the script tags so they cannot execute in any browser," Soderling explained. "This particular type of attack is not entirely uncommon."

And while it is likely that the majority of sites in the world are vulnerable, Twitter, with its team of capable developers should be better locked down.

However, Twitter is not alone in this. Guillermo Rauch found a similar vulnerability in Digg today that he tested and quickly alerted Digg to (Digg has since fixed the bug). You can read about the process here.

Whether Twitter is dealing with this problem by focusing on input filtering or output escaping is still to be determined. We've sent them an e-mail in an attempt to find out more and will update this post as soon as we hear back.