The best method for preventing this is to use eval sparingly and when it's easier to check for invalid input. Descriptions of any sort are usually more complex than a username or password, and thus harder to force into a particular regex to validate with. One way to solve this problem is to drop the use of eval, create a JavaScript function specifically for this task, and have the server send JSON. Any number of JSON parsers can be used here, but the example in Listing 2 uses the Prototype framework's evalJSON. PHP's json_encode function is available in all recent versions of PHP5 (to check, do a phpInfo() and make sure json capabilities are included).

Creating a solid set of internal defenses for our application is a kind of insurance policy. Effort is now exerted to minimize potential damage in the future. Unfortunately, if an exploit broke through, it broke through, and it may be impossible to prevent its spreading. If the exploit has gained a solid enough beachhead, internal replication is not the only concern.

Remember the proviruses at the beginning of this piece? Once they start replicating in a cell, there's no way that cell can be saved. In fact, if the immune system detects any sign that a cell is acting as a virus factory, it immediately kills the cell, destroying both it and the viruses inside. This may sound extreme, but it saves hundreds of other good cells from being invaded.

While we probably (and hopefully) won't have to scuttle our entire application because of exploit attacks, those exploits don't have to stay in our app. One of the many trends today is the mashup, combining outside data to provide new services. It would be beneficial to provide an API for the tagging application and encourage developers to use it in their own work. Such APIs often lead to interesting and quite successful spin-offs that bring new users to our own tagging app.

The problem is that the API still uses the same data as the rest of the application and shares the same risks. An exploit that is happily jumping around in the database can just as easily take a ride out of our application, through the API, and begin attacking some poor mashup. Now, after working on the whole application, and then spending nights and weekends fixing the security, an exhausted developer may ask, why bother sanitizing data that is going outside? It will never affect us. To answer: not cleaning outgoing data is like sneezing into someone's face, with no effort to cover your mouth.

Sure outgoing data is not much of an actual security threat to our application. It is a threat in a business and public relations sense. If people hear our API spews out exploits, the whole market of third-party developers and applications will quickly dry up. Worse, not cleaning up outgoing data shows that we have a serious lack of concern for those who use our services. It doesn't matter that the problem is only the API, our application will carry the stigma of being insecure for both users and potential business clients. In short, while a public API can provide many benefits, releasing data without cleaning it will write disaster in giant letters all over our application.

The simple solution is to use the same measures taken to stop exploits elsewhere. That way an exploit can be stopped thanks to an update that prevents it from coming in.

We have now covered how exploits can invade, spread, and break out of our tagging application, along with ways to bolster security at each level. It may be a great deal of work, but that is because security should be considered an integral part of every system, not just something to add on at the end. However, things can be greatly simplified by following some basic programming practices.

One such practice is to use the same security methods wherever they are relevant. This does not mean copying and pasting the code. Instead, all security should be packaged up and localized as much as possible. An example of a validation class is shown in Listing 3.

When needed, we would simply add static function calls to this class. The advantages are that it keeps code uncluttered and prevents maintenance problems down the road. Imagine the nightmare of having several validation functions strewn all over the place, and then having to find and update each one because we just found out there was an issue. With the never-ending battle of security versus attacker, such updates are likely to be quite common. Keeping security code
in one place means that we only have to update the code once.

Certain practices should also be observed for incoming and outgoing data. For incoming data, try to keep reasonable restrictions on what users can type in. For example, usernames should not need any characters other than letters, digits, and underscores. Longer pieces of input, such as the item descriptions or microblogs mentioned before, should be more flexible, allowing text that people use every day. See the discussion on entry point security for more specifics. Remember to clearly inform users of what characters they can and cannot use or they'll become frustrated.

Outgoing data is easier to control since it's up to us what kind of format it is in. Though we still have to make sure that format can be easily used. When constructing the content to be sent out, be sure to separate the data from the structure. So, if using XML, use a hard-coded template and clean up all the dynamic data before it goes in the XML. Also try to encapsulate the code that sends out the data, keeping it localized just as with the validation class above. This will lead to both cleaner code and a more standardized output system, which will make API users happy.

When I look at the world today, subjects such as physics and mathematics seem to be favorites of code geeks. Biology seems to be relegated to "other stuff." Yet it provides fascinating and sometimes scary parallels with the application world. Pieces of exploit code can spread through data and applications much like biological viruses spread through cells and people. But every time you see someone getting over a cold or the flu, you see that these viruses can be beaten. We can take not just a page, but whole volumes from such defeated viruses, and use that knowledge in the world of Web app security. So, next time you find out about a new exploit, make sure you respect the power and havoc that such a little thing can cause. Then you can go about writing the code that will tear that exploit to shreds.