A Q&A with Branden Williams, CTO of Marketing at RSA
SQL (Structured Query Language) is a standardized language for interrogating relational database systems, which are found in most companies for business applications (especially web-facing apps). SQL injection is one of the most common technical exploits used to perpetrate the theft of sensitive information. To understand a little bit more about how it works and how companies can prevent it, I spoke with Branden Williams, CTO of Marketing at RSA, the security division of EMC in Dallas, TX.
What is SQL injection, in layman’s terms?
If you look at the word “injection” and think about how it’s used medically that’s an easy enough analogy to start with. Basically, in this situation someone is looking at input fields in a website and “injecting” or typing in characters that will force the system/application to do things on the back end. They might use it to extract information from the web application or to execute other commands. They might codify information, delete information or create a backdoor to get into the database. Any field can be exploited any time there’s an opportunity to enter something. This is a malicious attack that can be performed with very little touch from a human being. It’s been going on for over a decade and it’s an easy way in, providing the developer has been sloppy and hasn’t covered all the bases. SQL injection is a significant threat, as far as remote attack threats go, due to the rapid nature by which software applications evolve; however, companies these days tend to be more concerned about threats from social engineering—data breaches with insider help.
How can I tell if my internet-facing applications are susceptible?
The easiest way to tell is to perform source code analysis and have a third party—a security firm or a consultant—take a look at penetrating the application. A penetration test alone can come up with certain telltale signs that the applications could be vulnerable. However, the challenge is that you can run into consultant analysis time issues. Someone on a delivery budget might not be looking at the site long enough to find the vulnerability, and analyzing the code versus in the context of a front end analysis is going to be faster and more effective. If you have a serious vulnerability on the site most tools can find it quickly, but it’s the problems that are buried deeper that might be harder to find. It can be an expensive review.
How can companies mitigate or prevent this threat exposure?
The best way—and unfortunately it kind of sounds really easy when it isn’t— is just performing input validation on any piece of data that comes in. Your applications should reject characters they don’t recognize. It’s helpful to know what special characters are out there—the apostrophe, for instance, is often used in SQL injection. Implementing validation can be done manually or through automated tools. There are advantages and disadvantages to both, depending on the system. In addition, companies are starting to deploy firewalls at the database level as an added layer of defense.
In conclusion…
Thanks, Branden. It’s very important for companies to recognize the threat and display some ongoing vigilance to hardening their internet-facing applications to prevent SQL injection since history has taught us it’s a favorite method for attackers who have successfully breached an untold number of major businesses to date—including TJX, Hannaford, 7-Eleven and Heartland Payment Systems (see story)—acquiring sensitive personal information about their customers. For more information, download Branden’s presentation from last year’s NetDiligence® Cyber Risk & Privacy Liability Forum called The Basics of SQL Injection – And How to Prevent It!
