The entry points that are hardest to secure are the most prone to attack. Exploits attacking these points will be more successful than others, so according to the above rule they will be more common.

It can't be stressed enough that security should never be neglected at the entry points. Not only can proper "frontier security" prevent hassles elsewhere, it is also relatively easy to implement. Here the malicious code has no foothold, and is much more vulnerable. We will look at two different ways to guard entry points:

• Sanitizing all incoming data, rendering it somewhat harmless
• Validating input and accepting or rejecting data outright

Each of the above has advantages and disadvantages, and therefore best used together.

A common method used here is to sanitize the incoming data. The following is an effective way in PHP to negate some HTML tags:

$cleaned_itrsts = array();
foreach( $new_interests as $itrst ){
$cleaned_itrsts[] = htmlspecialchars($itrst);
}

In days before, this would suffice to eliminate the exploit code, of course, this does virtually nothing to make the input database-safe. To do this in PHP, you can either use functions like mysql_real_escape_string or PDO's prepare method:

$one_interest = $_POST[‘one_interest'];
$query = "SELECT * FROM interests WHERE itrst = ‘$one_interest'";
// Using db-native escaping
$query = mysql_real_escape_string($query);
// Or using PDO:
$pdo = new PDO();
$prepared_query = $pdo->prepare($query);

Recently though changes in the Web world have altered some things. For example, the rise of AJAX has meant an explosion in the use of JavaScript. An unfortunate consequence is that inexperienced developers use the notorious eval. While the code above is fine for destroying unwanted HTML, JavaScript code can still slip through. Even if you yourself haven't eval'd any JavaScript on the client, it's possible that for some reason you will down the road, or, more likely, another developer will come in and not know about eval's security flaws.

Since simply sanitizing input isn't enough, the problem has to be looked at as one of data validation. This is the second area of entry point security: validation and the choice of accepting or rejecting input. An interest that a user wants to add should be simple from a format point-of-view, just a few letters, digits, dashes, and some white space. Now, what is this reminiscent of...regexes of course!

The following is a Perl-style regex that only matches strings of alphanumeric characters, dashes, and white space.

/[A-Z0-9\-]+/i

We can go even further and have our regex only accept strings from three to 15 characters long, while adding quotes and exclamation marks for the more demanding users.

/[A-Z0-9\-\'\"\!]{3,15}/i

When it comes to simple pieces of data, such as lists of interests or tags, validation is a breeze. Unfortunately some things involve much more complex data. For features such as user reviews or "microblogs" we may need simple HTML functionality. Here, types of security more sophisticated than sanitation or validation are required. An embedded language, such as BBcode only allowing certain HTML tags, or assigning privileges are options here.

As good as our entry point security is we can't assume nothing will ever get through. New exploits may come up, fueled by ever-changing technologies and ideas. Like viruses, exploits continue to evolve; unlike viruses, exploits are changed by people who want them to work.

If our tagging app had tough outer security but lax internal checkpoints, it would be a perfect host for such new exploits. We should know that data in a complex application is rarely isolated, nor is external input the only way data changes. Even the acronym of RDBMS (relational database management system) implies that the data is interrelated. While usually very useful, those same data relationships, if not secured, provide highways for an invading code to spread.

Back to our tagging app with a hard outer shell but a soft core. Imagine a new exploit has managed to breach the perimeter. Eventually we may find out about the new exploit and make the appropriate fixes. This will only prevent new invasions; with weak inner security, there's nothing to stop the exploit inside. The code then spreads unhindered. Table 1 describes the two main types of data relationships, how they can spread the exploit, and how much risk they involve.

When a virus is successful enough, it often overtakes entire tissues, organs, even bodies. For example, the Ebola virus is so virulent the victim becomes saturated with pathogens just a week after infection. Every bit of tissue, every drop of blood has enough virus particles to infect countless more. In effect the person becomes a biological grenade.

A binary grenade is what a database can become if an exploit has gained a foothold and spreads using the data routes mentioned above. Exploits can be further propagated by actions done by users. For example, a particular piece of malicious code embedded in a Web site submission won't go very far if the submission isn't popular. However, if a particularly influential user likes the submission and sends it to many friends, the exploit will be unwittingly spread. User-driven propagation can be particularly crippling, since it's as dangerous as hard-coded data relationships but is driven by everyday social interactions. To fight this, users should only have highly restricted access to HTML, especially in tags that involve hidden requests to user-specified URLs (hint, the URL doesn't have to point to an image). When users share tags or submissions, try to use dynamic relationships where possible so every time something is shared, the exploit isn't physically copied.

Since JavaScript is used a lot to make rich interfaces, JavaScript-based exploits are gaining traction. These exploits spread using methods different than those listed above. One of the biggest vulnerabilities is the use of eval. Unless the application lets script tags through, the attacking JavaScript isn't invoked automatically by the browser and usually requires using eval to run it. Listing 1 illustrates some code for a feature that lets users view different submissions in an AJAX-ified way.

When eval runs the response it can't distinguish between what we, as developers, wanted to be run and the attacker's code. Of course the exploit would probably be much more elaborate than a simple alert. A likely case is that the code hijacks an AJAX method, and uses it to send the exploit code back to the server and possibly the database.