No secret to stopping XSS and SQL injection attacks

SQL injection attacks and cross-site scripting exploits just won't die.

The most recent and high-profile incident was a mass webpage attack on more than 100,000 pages, which included victims as diverse as The Wall Street Journal, TomTom, and the UK's Strathclyde police.

There was a teetering stack of exploits involved in this hit: cross-site scripting that involved a banner-ads module on top of IIS using ASP.net, and malicious JavaScript on the site that users were redirected to. The initial weakness that made this mass attack possible allowed a set of SQL injection exploits to be run against the targeted websites.

But none of it would have been possible if the sites involved had been more resilient to SQL injection attacks. This signals a lack of awareness among developers — but we shouldn't just be pointing the finger at them. The problem also comes back to a lack of awareness among testers, who really should be actively testing applications for common security holes as a matter of course.

But the problem goes even deeper than that. The current emphasis on unit testing among developers has produced a myopic attitude to testing, in which integration testing — which would help to expose certain security flaws — is seen as too troublesome to bother with.

The frustrating thing about SQL injection attacks in particular, though, is that they're so easy to prevent in the first place — and easy to test for, of course.

Take the following query. Let's say we run a travel website where somebody searches for hotels in Blackpool. The query, constructed in your server code, would look something like:

SELECT * FROM hotels WHERE city = 'Blackpool';

In the search form, the user would enter a town/city. The server component extracts this value from the submitted form, and places it directly into the query.

Giving effectively free access to the database opens up all sorts of potential for sneaky shenanigans from unscrupulous exploiters. All the user has to do is add their own closing single-quote in the search form, plus some additional gubbins to turn it into a valid query:

Blackpool'; --

Everything after the -- is treated as a comment, so the door to your data is now wide open. How about if the user types into the search form:

Blackpool'; DROP TABLE hotels; --

Your server-side code will faithfully construct this into the following SQL, and pass it straight to the database, which in turn will chug away without question, just following orders:

SELECT * FROM hotels WHERE city = 'Blackpool'; DROP TABLE hotels; --';

Depending how malicious the attacker is, they could wreak all sorts of havoc or (worse, in a way) build on the "base exploit" to extract other users' passwords from the database. There's a good list of SQL injection examples here.