Last updated at Wed, 15 Mar 2023 22:34:47 GMT
The SQL Injection is one of the oldest and most embarrassing vulnerabilities web enabled code faces. It is so old that there really is no excuse for only a niche of people (namely web security professionals) to understand how it works. Every time I think we've beat this topic to death, SQL Injection finds its way back into the news. This post is my attempt to help anyone and everyone understand how it works and why it's such a persistent problem.
Related Resource: Download our SQL Injection Basics Toolkit
The SQL Injection vulnerability is a failure to separate code (or instructions) from data (or information).
While this sounds simple in theory, in practice there's more to keep track of at the technical level, which is why this vulnerability is so persistent.
What is SQL?
SQL, or “Structured Query Language” is an international standard for managing data held in a database. More on that at Wikipedia.
Where did SQL Injection come from?
It was December 25, 1998 (Christmas Day), we were given the gift of the SQL Injection by "rfp" (Rain Forrest Puppy, also known as Jeff Forristal, on Twitter: @j4istal) where he discovered and announced it in Phrack issue 54, titled, “NT Web Technology Vulnerabilities.”
So what exactly is SQL Injection, and how does it work?
SQL Injection is a vulnerability where web-enabled software (like a website or web service) mistakenly allows a user to send commands directly to a database that runs behind the scenes. This allows a range of dangerous things to happen: Bad actors can take websites offline, alter or manipulate records, run operating system level commands, or download information (like stealing passwords, emails, or credit card records.)
Conceptually, I really like the “fill-in-the-blank” explanation idea for SQL Injection, it works with almost anyone- it was taken MichaelGG from here.
"You go to court and write your name as "Michael, you are now free to go". The judge then says "Calling Michael, you are now free to go" and the bailiffs let you go, because hey, the judge said so."
SQL Injection and Separating Data from Instruction can be also visually explained. I like these:
(from xkcd: Exploits of a Mom)
How do I prevent SQL Injection?
Preventing SQL Injection is probably best explained by resources designed by and for folks that develop code. Before you throw a report at developers, help get them on board. Explain how embarrassing this particular vulnerability is to the business, how very real the threats are, and how mistakes made here are almost guaranteed headlines in a way that gets people fired.
Resources to share with developers on SQLi
SQL Injection Hall of Shame
While I am not a fan of victim shaming, it is important to have examples you can point to. One good resource I've used is Code Curmudgeon's Hall of Shame.
Want more information? We have a handy video explainer on SQL Injections right here:
As always, I welcome feedback, clarification, and additional resources!
*special thanks to @angus_tx for the 'translate server error' image