SQL Injection is an attack that exploits a vulnerability in software code where the query is constructed dynamically via String concatenation. SQL Injection is one of the oldest Injection attacks out there dated back to 1998 when it was discovered by Rain Forest Puppy.

I imagine back in 1998, SQL Injection was one of the easiest attacks with the most bang out of the hacker’s buck. They would go and use the famous 1′ or ‘1’ =1 or someting and boom….lots of goodies.

Although there is a lot more awareness now for SQL Injection compared back to 1998. Amazingly SQL Injection still tops OWASP’s Top 10 as #2 in the list among other injection attacks like command injection, header injection…etc

Wait, but you just said that there is more awareness now regarding SQL Injection attack compared to 1998 for example?

Exactly, I will explain that later. Preventing against SQL Injection attacks is simple:

  • If you are using queries, Use parameterized queries.
  • If you are using stored procedures, use parameterized stored procedures.

This is absolutely no exhaustive list of SQL Injection prevention list. This simple changes seems to be almost eliminating SQL Injection vulnerabilties in the code implementing them. Seems obvious and easy enough, right? Why the heck is it then that SQL Injection is still #2 on OWASP’s top 10 list and SANS top 20 list?

  • Because developers think that threat comes only from users’ input, they don’t think that threat can come from things like their own database, internal configuration files or from other data read from XML streams. Developers associate risk with human beings only, they don’t associate risks with machines or other systems their code interact with.
  • What are you saying here? I am saying that my guess is that the reason SQL Injection is still that high of a risk because developers should parameterize everything in their queries and not only fields coming from the request or from a form.
  • Don’t think that just because the data is loaded from internal configuration file or from your own database that it is safe. Unless developers has 100% control over the machine on which the code will be deployed and he is an expert in network security and guards this machine 24/7, don’t trust ANY input that you are using in your SQL query.
  • OK, I have done that, now what? ….Validate your input. Why, it is irrelevant now, right? What if you made a mistake and didn’t follow through, unintentionally ofcorse, all the best practices, wouldn’t you like an extra net to fall into, it is like the car warranty for a new car, you know you almost wouldn’t use it but it is just good to be there. What if attackers were smarter than you are and exploited a vulnerabilitiy in the database driver you are using. Now you know what I mean? 🙂

Here are some of the best articles that covers the basics of SQL Injection, an article by SecuriTeam, MSDN and lots of SQL Injection tricks here. Jermiah Grossman’s article about SQL Injection is really cool too, check it out.

White Paper - Proving Adherence to Software Security Best Practices

White Paper - Proving Adherence to Software Security Best Practices

Industry standards and the best practices for developing secure software. Please provide your email and name to receive your copy.

Success! Your copy is on the way.