I’m starting an eight-part series on SQL injection in Microsoft SQL Server. Most of the topic applies to other database vendors, but SQL Server is my specialty, so that’s the product I know best. For the next four weeks, I’ll put up two posts a week: on Tuesdays and Thursdays. Part 8 will wrap things up and include links back to the entire series.
This post is meant as nothing more than a basic introduction to the topic. SQL injection is the insertion of SQL code into what should be a parameter, causing unexpected (for the developer) behavior. For example, suppose you have a text box on a webpage which populates a SQL parameter @Parameter. This parameter is then used in a SQL query to do a lookup on a table. An example of SQL injection is when some bad guy overloads @Parameter to perform some unexpected operation.
This is a very basic description of SQL injection, and I will dig much deeper into how to do it in later posts. First, though, I think I should spend a few moments on the “Why?” part. Why discuss SQL injection at all? The reason is just how ubiquitous SQL injection is. By 2006, web application vulnerabilities had become more popular than buffer overflows, with cross-site scripting #1 and SQL injection #2. Since then, SQL injection has jumped to the #1 spot. According to Imperva, “From 2005 through today, SQL injection has been responsible for 83% of successful hacking-related data breaches,” and an average of 71 SQL injection attempts per hour were logged on web applications they observed over a 9-month period.
If you can prevent SQL injection attacks, you have gotten one step closer to a secure network and have made it that much more likely that your CISO’s face will not show up on the nightly news. And trust me: CISOs hate showing up on the nightly news… But the only way to prevent an attack is to know how the attack operates. That’s why, in part 2, we’ll go into My First SQL Injection.