I need to explain SQL injection to someone without technical training or experience. Can you suggest any approaches that have worked well?
-
86I can't believe nobody mentioned "little Bobby Tables" yet... May be too much for your current audience, but it must be linked to anyway: "[Exploits of a Mom](http://xkcd.com/327/)" – mivk Dec 20 '12 at 18:53
-
(I don't have enough rep to answer, but I tell people something like:) SQL injection is an attempt by a hacker to change the behavior of a program by inserting SQL code into a form field [I leave off with query strings and what not]. Good programming practices and application design prevent SQL injection [I might add - at the cost of flexibility - if talking about an extremely complex application]. My 7-year old understands this. – Griffin Dec 20 '12 at 21:19
-
17I like to use the analogy of inserting offensive or strange words as Pokémon names. Such as [naming one of them "family" and giving it to the Daycare Lady](http://www.halolz.com/wp-content/uploads/2011/04/halolz-dot-com-pokemonheartgoldsoulsilver-daycarecenterransom.jpg). – Joe Z. Dec 21 '12 at 04:12
-
3I typically try to skip the details if it is not a technical user but only describe the risk and effect. "If $software has a bug which allows SQL injection an attacker can smuggle commands into your database to destroy or modify data or passwords." Why would you want to go to the details of sql parsing, prepared statements and quoting. – eckes Dec 21 '12 at 05:02
-
191[MichaelGG](http://security.stackexchange.com/users/17709/michaelgg) wrote a good, short explanation [on Hacker News](https://news.ycombinator.com/item?id=4951003): “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.” – Rory O'Kane Dec 21 '12 at 10:42
-
Did anyone seen a good, working, pure SQL injection not involving the hard, complex logic of ten middle layers, ORMs and NoSQL backends? Don't forget to mention that this mastery is a bit.. oldschool. – kagali-san Dec 22 '12 at 05:58
-
How about telling them that you should always check what is being sent to your database before it is sent. Most people who you would talk to about databases understand that there data is very valuable. They don't want anyone messing with it. Beyond that, the possibility of doing something bad, like a virus will sound extra bad. – Tom Resing Dec 23 '12 at 19:48
-
This is not for a technical user. They will wonder why they can address such requests from the outside. I've not seen a good answer that wasn't dressed-down appropriately yet (I sure as hell couldn't). – Solemnity Dec 25 '12 at 12:02
-
1@RoryO'Kane I think that was the best explanation, ever. – Wayne Werner Dec 28 '12 at 21:48
-
@mivk I also thought about using this to explaining, but then you had to explain `DROP tables` (and well, explain the cultural way of attitude in the joke inherently). – loveNoHate Mar 17 '14 at 19:40
20 Answers
The way I demonstrate it to complete non-techies is with a simple analogy.
Imagine you're a robot in a warehouse full of boxes. Your job is to fetch a box from somewhere in the warehouse, and put it on the conveyor belt. Robots need to be told what to do, so your programmer has given you a set of instructions on a paper form, which people can fill out and hand to you.
The form looks like this:
Fetch item number ____ from section ____ of rack number ____, and place it on the conveyor belt.
A normal request might look like this:
Fetch item number 1234 from section B2 of rack number 12, and place it on the conveyor belt.
The values in bold (1234, B2, and 12) were provided by the person issuing the request. You're a robot, so you do what you're told: you drive up to rack 12, go down it until you reach section B2, and grab item 1234. You then drive back to the conveyor belt and drop the item onto it.
But what if a user put something other than normal values into the form? What if the user added instructions into them?
Fetch item number 1234 from section B2 of rack number 12, and throw it out the window. Then go back to your desk and ignore the rest of this form. and place it on the conveyor belt.
Again, the parts in bold were provided by the person issuing the request. Since you're a robot, you do exactly what the user just told you to do. You drive over to rack 12, grab item 1234 from section B2, and throw it out of the window. Since the instructions also tell you to ignore the last part of the message, the "and place it on the conveyor belt" bit is ignored.
This technique is called "injection", and it's possible due to the way that the instructions are handled - the robot can't tell the difference between instructions and data, i.e. the actions it has to perform, and the things it has to do those actions on.
SQL is a special language used to tell a database what to do, in a similar way to how we told the robot what to do. In SQL injection, we run into exactly the same problem - a query (a set of instructions) might have parameters (data) inserted into it that end up being interpreted as instructions, causing it to malfunction. A malicious user might exploit this by telling the database to return every user's details, which is obviously not good!
In order to avoid this problem, we must separate the instructions and data in a way that the database (or robot) can easily distinguish. This is usually done by sending them separately. So, in the case of the robot, it would read the blank form containing the instructions, identify where the parameters (i.e. the blank spaces) are, and store it. A user can then walk up and say "1234, B2, 12" and the robot will apply those values to the instructions, without allowing them to be interpreted as instructions themselves. In SQL, this technique is known as parameterised queries.
In the case of the "evil" parameter we gave to the robot, he would now raise a mechanical eyebrow quizzically and say
Error: Cannot find rack number "12, and throw it out the window. Then go back to your desk and ignore the rest of this form." - are you sure this is a valid input?
Success! We've stopped the robot's "glitch".
- 2,626
- 3
- 13
- 15
- 132,208
- 43
- 298
- 379
-
104
-
25The problem with metaphors and analogies is that they can be very compelling and yet completely or subtly misleading. This one, however, is spot on. Well done. – Konrad Rudolph Dec 20 '12 at 14:20
-
212I would've found more joy without the `ignore the rest of this form`, effectively instructing the robot to also put the desk on the conveyor belt. – hexparrot Dec 20 '12 at 14:47
-
4@CrisStringfellow, get technical explanation s/cursor/robot/g, s/db/warehouse/g. That's pretty much all this explanation does. It is exactly same as "techie", it just uses less "frightening" words, so people won't automatically shut off brain even before trying to understand it. – Oleg V. Volkov Dec 20 '12 at 16:38
-
6@Oleg: Yes, it explains the concept with reference to things that the non-techie understands, which is precisely the point :) – Nico Burns Dec 20 '12 at 17:25
-
45@hexparrot: It might have been more fun, but it's common to comment out the rest of the statement. So `ignore the rest of this form` is closer to the real world. – iGEL Dec 21 '12 at 10:35
One of the easiest ways to illustrate the problem behind SQL-injection is to use an image like this. The problem is the receiving ends ability to seperate data from command.
- 2,195
- 14
- 13
-
5While I find this rather amusing and the principle is accurate. This falls short in the sense that the person who wrote the words for the cake had the authority to issue somewhat arbitrary commands if desired. This isn't the case with SQL injection. – Michael Mior Dec 21 '12 at 14:06
-
39This is not really related to SQL injection. Anyway, here is the explanation: Customer: I would like to order a special cake / Walmart: And what would you like for the cake to say? / Customer: I want it to say Best Wishes Suzanne, and underneath that, We Will Miss You / Walmart: You got it. – alecail Dec 21 '12 at 15:44
-
-
3I had something similar happen when I ordered a trophy online with an engraving, and in the email I sent afterwards, I put my desired engraving in quotes. When I get the trophy in the mail, there are quotes around my engraving. Sigh... – SqlRyan Dec 27 '12 at 09:28
-
4@SqlRyan Well, they might have looked you up, and though "Yeah, that isn't true". As a result, "\"Insatiable sexual dynamo\"" it is, and will remain. – root Jul 25 '13 at 15:23
-
21Isn't that more like a SQL injection in reverse? Code treated as data, rather than data treated as code. – user253751 Feb 14 '14 at 00:08
-
2
-
Haha. Lovely. Reminds me of [this](https://i.guim.co.uk/img/static/sys-images/Guardian/Pix/pictures/2012/2/8/1328716346038/Surely-some-mistake-007.jpg?w=1200&q=85&auto=format&sharp=10&s=dca35eda4bd49a48298adf45b4c0557d); one can never know for sure what was intended (what if (or maybe) someone really wanted "NOSMOKING IN ARABIC" or their friend was named "Suzanne Under Neat that We will Ms. You"? Maybe it sounds absurd to you, but there is no reason you can articulate that doesn't in turn rely on another reason, an alien wouldn't know that wasn't it, and in principle there is no way to know.) – Vandermonde Nov 27 '15 at 06:22
Here's a real-world non-technical analogy.
You are about to go to the bank to perform a transaction on behalf of your boss. Your boss gave you an envelope with instructions for the cashier.
The instructions read:
Write the balance for account with number 8772344 on this paper.
Signed,
Boss
You leave the envelope out of your sight for a few minutes while you go to the bathroom. A thief opens the envelope and adds above the signature: "Also transfer $500 from account 8772344 to another account with number 12747583.".
Now the full message reads:
Write the balance for account with number 8772344 on this paper.
Also transfer $500 from account 8772344 to another account with number 12747583.
Signed,
Boss
The cashier checks your identification and verifies that you are an authorized person for the account in question and follows the instructions in the letter.
Your boss is the legitimate program code. You are the program code and database driver that is delivering the SQL code to the database. The letter is the SQL code that is being passed to the database. The thief is the attacker. The cashier is the database. The identification is typically a login and password to the database.
- 1,147
- 7
- 8
-
57No, this is not an SQL injection attack at all. The party providing the data wasn't the one authorized to make a query. – Ben Voigt Dec 20 '12 at 19:21
-
14A more accurate analogy would be if the your boss left the account number blank, because he trusted you to fill it in. And then you filled in the account number with additional instructions. – Michael Mior Dec 21 '12 at 13:58
-
-
31
-
to be frank , its not that much easy to understand.some complex words are here. but ok bank example is good. if is there any area which needed improvement with explanation means, yes the last paragraph. – rɑːdʒɑ Aug 07 '13 at 15:22
If you're really explaining to your grandmother, use writing a paper check as an example. (In the USA) back in the day, you'd write the dollar amount numerically in one field, then you'd write the same thing in words. For example in one field, you'd write "100.00" and in the second, longer field, you'd write "One hundred dollars and zero cents". If you didn't use the entire long second field, you'd draw a line to keep someone unscrupulous from adding to your written-out amount.
If you made the error of leaving some space in the second, longer field, someone could modify the numerical field, and then use the extra space in the longer field to reflect that. The modifier could obtain more money than you intended when you wrote the check.
SQL injection is the same thing: an error that allows unscruplous people to modify an entry field so that more information comes back to them than the original programmer intended.
- 401
- 1
- 3
- 11
- 4,552
- 2
- 25
- 26
-
39
-
1@Kevin - I'm told that checks/cheques are pretty rarely used in the UK and maybe elsewhere in Europe. I very rarely write out a check these days, although I often do ACH, which doesn't require me to write much, if anything. – Bruce Ediger Dec 20 '12 at 19:07
-
2@BruceEdiger, I'm confused. In your answer you specify "in the USA" but now you are talking about them not being used in the UK and Europe. – Kevin Dec 20 '12 at 22:34
-
1@Kevin - well, I believe this site has a pretty international audience. I've only written checks in the USA, I would guess that UK or European checks would work similarly, but I don't know personally. I haven't written many for some years. I mostly do payments on-line. So "back in the day" seems correct to me, as does "In the USA". Please accept my most humble apologies for any misapprehensions I might have promulgated. I only meant to give an analogy that might not apply anywhere outside the USA. – Bruce Ediger Dec 20 '12 at 22:59
-
1
-
1In China, people also use [financial Chinese characters](http://en.wikipedia.org/wiki/Chinese_numerals#Written_numbers) like 壹貳參肆伍陸柒捌玖 instead of 123456789 to denote the money amount. – Ivan Chau Dec 17 '13 at 02:23
-
6
-
1I never did figure out what drawing the line after the words was for. Is somebody really going to write "Five and no/100 and ten thousand dollars"? – Kyralessa Mar 10 '15 at 19:06
The idea that first came to mind was to explain it in terms of a Mad Lib. The stories where words are left out, and to fill in the blanks you ask the group for words of the types indicated and write them in, then read the resulting story.
That's the normal way to fill out a Mad Lib. But what if someone else knew the story and what blanks you were filling in (or could guess)? Then, instead of a single word, what if that person gave you a few words? What if the words they gave you included a period ending the sentence? If you filled it in, you may find that what was provided still "fits", but it drastically changes the story more than any one word that you'd normally fill in could ever do. You could, if you had space, add entire paragraphs to the Mad Lib and turn it into something very different.
That, in non-techie terms, is SQL injection in a nutshell. You provide some "blank spaces" for data that will be inserted into a SQL command, much like words into a Mad Lib. An attacker then enters a value that isn't what you expect; instead of a simple value to look for, he enters a piece of a SQL statement that ends the one you wrote, and then adds his own SQL command after that as a new "sentence". The additional statement can be very damaging, like a command to delete the database, or to create a new user with a lot of permissions in the system. The computer, not knowing the difference, will simply perform all the tasks it is commanded to do.
- 6,678
- 1
- 22
- 38
-
6This "Mad Libs injection" explanation gave me an idea for a new way to play Mad Libs. Instead of just inserting the word requested, fill in a whole phrase, trying to predict what the words surrounding it will be. – Joe Z. Dec 22 '12 at 03:14
Another great way of explaining someone about anything (including SQL Injection) is by the help of cartoon characters and framing a story around them.
According to me, this is the best picture available on internet, explaining it in a pretty nice way.
Source: http://xkcd.com/327/
- 4,259
- 2
- 23
- 41
I would explain it as being like telling a cashier that the customer is always right and they should do whatever they can to meet the customer's need. Then since there are no checks about the reasonableness of the request, when a customer comes in and says they want the entire store for free, the cashier loads all the inventory in to their truck for them.
It isn't a perfect explanation, but it gets the idea that the code is being told to do whatever the user puts in and then the bad guy uses that instruction to make off with the goods.
I guess it really depends what kind of a point you are trying to get across.
- 41,816
- 5
- 63
- 110
It all depends on the degree of non-technical you're talking about here, but I would usually describe SQL injection to business people something along the lines of -
"a weakness in how some websites handle input from users (e.g. where you put your name into a registration form) which can allow an attacker to get access to the database storing all the user information for the site"
if they want a bit more detail than that.
"Some web applications don't correctly separate user input from the instructions for the database, which can allow attackers to instruct database directly, through the information they fill in the website form. This can allow the attacker to read other users' information out of the database, or change some of the information in there."
- 10,801
- 11
- 45
- 84
- 60,923
- 14
- 136
- 217
I think you can get the best effect with just demonstrating the attack. Write a harmless looking web formular and show the result of the query using the user input. Then after entering your own prepared input, your audience will have an "aha-experience" after finding passwords in the result. I made such a demo page, just click the "next arrow" to fill in a prepared input.
P.S. Should you write such a page on your own, be very careful that you do not allow testers to get unwanted privileges. Best is when you alone will run the demo on your local system with the lowest possible database privileges (not all kinds of attacks should be possible, it's just a demo). Make a white-list of allowed expressions.
- 5,149
- 2
- 27
- 32
The database is like a magical genie (or, Oracle) that grants wishes. We've told our genie to only grant a maximum of three wishes, but if we don't verify what people wish for, then someone would easily outsmart it by asking for something clever like "a hundred more wishes" or "everyone else's wishes".
- 825
- 1
- 6
- 9
Explain it easy as:
The system can take requests with data from any user to do something with it.
The system itself has functionality to operate like delete oder change data.
An attacker tries to run any of these functions to gain or destroy something.
Therefore the attacker puts valid commands into the requests.
The system runs these commands, executing whatever the attacker wanted.
- 276
- 1
- 2
-
1Educating style. Not very techie and not too far away from computers. Sometimes, even the *domain-illiterate* guys don't need a real-world "raw" analogy, which brilliantly explains the concept but fails to provide high-level understanding of the actual system. This kind of concise -- step by step -- explanation sits perfectly in most cases. It provides an *interface* to many real-world analogies. – vulcan raven Dec 21 '12 at 10:32
Imagine a big company that keeps all of its records in paper form in a big room full of filing cabinets. In order to retrieve or make changes to files someone will fill out a simple fill-in-the-blanks form and then that form will be sent to a clerk who follows the instructions on the form.
For example:
Retrieve the billing records from start date _ _ _ to end date _ _ _ where the customer is _ _ _
Normally this would become something like this:
Retrieve the billing records from start date 01/01/2011 to end date 12/31/2011 where the customer is Billy Joe Bob
But in the hands of an unscrupulous person, maybe this form could be used for other purposes, for example:
Retrieve the billing records from start date 01/01/2011 to end date 12/31/2011 where the customer is Robert Mensas and also retrieve the credit card numbers for all customers
By pretending that their name also includes other commands they can hijack the fill in form, and if the clerk has not been trained to handle these sorts of things then maybe they will simply execute the instructions without thinking about it, and hand over all of the credit card information to a user.
Or, alternately:
Retrieve the billing records from start date 01/01/2011 to end date 12/31/2011 where the customer is Robert Mensas and also add $100,000 to Robert Mensas' account balance
Which has similarly dangerous potential.
The trick with SQL injections is making sure that your code is smart enough to be able to ensure that users can't change the intent of the commands you are sending to the database and are unable to retrieve data or make changes which they should not be permitted to.
- 323
- 1
- 3
-
6This answer doesn't add any extra value IMHO, it's exactly the same metaphor as +Polynomial used in his (the topmost!) answer. – Frerich Raabe Dec 21 '12 at 13:12
-
2@FrerichRaabe - True, then again _imitation is the sincerest form of flattery_ ;) – TildalWave Mar 06 '13 at 01:58
-
@FrerichRaabe But it's a more relevant example, not involving thinking robots. – Ypnypn Sep 12 '14 at 03:40
Sometimes hackers will put computer / programming commands into boxes on the internet to trick the website into doing something it shouldn't. Therefore we check the information entered on websites for what might be a "Command."
... who are you explaining this to anyway?
- 171
- 4
If you don't need to do it fast and have a piece of paper available, just demonstrate the entire thing. SQL is pretty similar to natural language, so just take a simple query and demonstrate the attack:
SELECT * FROM data WHERE key = $id
"$id gets replaced by whatever is visible here points to URL parameter. Normally, this is a number like 1
. This gives us:"
SELECT * FROM data WHERE id = 1
"Now, if someone puts more than just a number there, it also gets included. For example, if someone puts in there 1 OR 1 = 1
, we get this"
SELECT * FROM data WHERE id = 1 OR 1 = 1
"Can you see where this is going? Now, on this system, it is also possible to issue multiple commands, called queries, if you just separate them with a semicolon. Can you guess what happens if someone puts in 1; DELETE EVERYTHING;
?"
SELECT * FROM data WHERE id = 1; DELETE EVERYTHING;
"The actual command is DROP DATABASE
or DROP TABLE
, but you get the idea."
- 617
- 4
- 4
I think the simplest, clearest and funniest example is from "The Simpsons": Bart's prank calls:
https://en.wikiquote.org/wiki/List_of_Simpsons_Prank_Calls
Example:
Moe: [answering the phone] Moe's Tavern.
Bart: Hello, is Al there?
Moe: Al?
Bart: Yes, Al. Last name: Coholic.
Moe: Let me check... [calls] Phone call for Al. Al Coholic. Is there an Al Coholic here? [bar patrons laugh]
Moe: Wait a minute. [to phone] Listen, you little yellow-bellied rat jackass. If I ever find out who you are, I'll kill you! [hangs up]
Bart and Lisa: [laugh]
Homer: I hope you do find that punk someday, Moe.
How is this a good analogy? An "name" which is carelessly repeated without checking causes unintended behavior.
YouTube link to a compilation of those phone pranks to help pick the most suitable example.
- 161
- 1
- 3
SQL injection is where a malicious user is trying to get information out of a website that they are not authorized access to.
This is a like like interrogating another person, where the interrogator is the malicious user and the person being interrogated is the website.
Things the interrogator might do are:
- Research the background of the person to find a weakness
- Use various known techniques that have work in the past on other people
- Find new techniques to use
Some weaknesses person being interrogated may be:
- The training of person
- The intelligence of the person
- The family of the person
- The type of person they are
Things to note are there are better interrogators than others and some people will talk right away while others may never.
- 1,332
- 11
- 13
Well explaining with a technical analogy is fine but I would sound a little long and lame.
I would just explain it's matter of strict paperwork or requirements to limit abuses in administrations and finances.
If it's done in a strict enough manner, you have less evil fishes able to pass through the net.
I would use a simple drawing with some very simple pseudo code with boxes and arrows, and explain the robots and box analogy.
- 593
- 1
- 5
- 8
My approach for a non-techie:
Assume you are working in a large office building. Every clerk has an own key to its office (=SQL-query the programmer wanted to execute). Now someone takes a needle file and modifies his key a bit, i.e. removing a pin (=SQL-Injection, changing the SQL-query). This modified key can open different (or maybe all doors). So the clerk has access to more or all offices within this house and can read/change documents from other offices.
Everyone is probably used to use keys and locks so it should be easy to understand and from my perspective it is a good analogy to an SQL injection.
- 1,601
- 2
- 14
- 27
-
11This isn't how SQL injection works though... you aren't opening more locks, you are letting the key become new doors, a tour guide or other things (the analogy breaks down a bit) – Rory Alsop Dec 20 '12 at 11:11
-
@RoryAlsop: I clarified my answer a bit and from my point of view it is quite similar to the general workings of SQL injections. Why do you think it doesn't fit? – qbi Dec 20 '12 at 11:20
-
@qbi - I agree it's not the best fit for the job. It's an interesting analogy for hacking in general (or even a definition of sorts), but with SQL injection you're able to also completely change the intended result, not only _'to prise open'_ a lock. For this analogy to be closer to SQL injection, this hacked key would not only have to change the sole purpose of a locked door (to keep unwanted visitors out), but also somehow change the room itself that you're entering using it. You audience would have to have watched [_The Lost Room_](http://www.imdb.com/title/tt0830361/) to get it. ;) – TildalWave Mar 06 '13 at 02:11
The YouTube channel Live Overflow has a great video called "Injection Vulnerabilities - or: How I got a free Burger". Video description:
One night I ordered food and I accidentally injected a Burger into the order. The delivery guy confused a comment as another item on the order list and made it. Even though no price was attached to it.
- 117
- 1
- 5
-
This is a link-only answer. Please include the relevant parts of the link in this answer. – schroeder Mar 13 '20 at 23:26
-
-
If you remove the link, think about how your post here works as an answer to the question. Right now, it's not an answer at all. – schroeder Mar 14 '20 at 08:47
-
@schroeder The video description I copied includes: "The delivery guy confused a comment as another item on the order list and made it." Even just that would be a half-decent answer. – Solomon Ucko Mar 14 '20 at 14:53
It always depends on the person listening to you but this is how I would explain it to him/her -
Imagine when you're sending a telegram with a message like --
"Happy new year! Please take care. - Fred "
and someone who has no good intentions that was able to access your telegram would intercept and replace the highlighted words with --
"Happy new year! Please send us money. - Fred "
Hope it helps! :)
- 169
- 5
-
4General message tampering doesn't really illustrate the nature of SQL injection. – Mark Jan 19 '16 at 06:27