No secret to stopping XSS and SQL injection attacks
Read, test, communicate, repeat
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.
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:
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.
Sanitized for your protection
Protecting against this type of attack isn't simply a case of "sanitizing" the single-quotes, as this excludes valid names such as "Brer O'Hare", in which a quote is a perfectly valid character.
Depending on which language/platform/database you're using, there are plenty of libraries whose creators have thought through all the possible combinations of "problem characters". You just have to make sure you use one — and, of course, make sure you have an integration test that confirms this protection is working.
In fact, an often-neglected aspect of security awareness is integration testing — that is, ensuring that the disparate parts of the system fit together without any glaring (or subtle) security holes.
The trouble is, testing a system for security weaknesses after it's developed is like building a warship and only then thinking about water-level hatches where enemy frogmen might potentially be able to sneak in. Security testing really needs to be incorporated into the development process, not just as an "after-the-event" phase; the mantra "test early" is espoused in The Art of Software Testing by Glenford Myers, for example.
But herein lies another problem: you'd think an "utterly" test-driven process would help improve security — yet with the advent of Test Driven Development (TDD), programmer-led testing has become a case of "does this minute software function work while I feed it simulated inputs and fence off external calls using mock objects?" rather than "does this system work correctly when the pieces are joined together?"
There's a difference between zooming in on individual components and testing those, or kick-starting the whole Rube Goldbergesque end-to-end interaction and confirming that the results displayed on the user's screen are as expected. Integration testing across system boundaries such as firewalls or third-party components is a good way to reveal security flaws.
Developers should also be keeping an eye on the SANS top cyber security risks page, and OWASP, and XSSed, and thinking about automated tests they can write — which can usually be shared among projects or components — to verify that the system isn't vulnerable to these kinds of attacks.
Otherwise, high-profile attacks and exploits won't just not die, they'll pop up with increasing regularity. ®