Common Topics

Recent Articles

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.

That leads us to the next problem: the insular nature of modern multi-tier architectures has produced a territorial approach to software testing. DBAs are writing and testing their stored procs, middleware developers writing and testing their entities and session beans, and front-end developers coding up the web interface, immersed in PHP and JavaScript libraries. The developers in each of these territories need to talk to each other more — and, of course, they need to get their tests talking to each other more.

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. ®