Explain SQL injection without technical jargon(security.stackexchange.com)
security.stackexchange.com
Explain SQL injection without technical jargon
http://security.stackexchange.com/questions/25684/how-can-i-explain-sql-injection-without-technical-jargon#answer-25710
16 comments
Here's my answer: http://security.stackexchange.com/a/25839/3614
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.
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.
"Imagine reading a book by Billy where dialog is set off by quotes like normal," Sue said. "But could Billy quote 'something someone said' within a quote and have it make sense?"
"Sure he could," said Joe.
"Ah, but what if there was an apostrophe inside a quote inside a quote in 'Billy's Novel'?" asked Sue.
"That could get confusing," Joe conceeded.
' OR 1=1
"Sure he could," said Joe.
"Ah, but what if there was an apostrophe inside a quote inside a quote in 'Billy's Novel'?" asked Sue.
"That could get confusing," Joe conceeded.
' OR 1=1
That robot warehouse analogy was perhaps more confusing than just explaining SQL injection as is.
Yea they all seemed overly complicated. An easier example: 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.
This needs to be on the SO page, far better.
I agree. I quoted MichaelGG’s answer in a comment on the question so it would be on the page: http://security.stackexchange.com/questions/25684/how-can-i-...
I added it as a comment to the top answer, but it was removed. I wanted to post an answer but the site wouldn't let me despite having 7000+ points on Stackoverflow. Oh well.
Did you create an account first? The question is protected to stop junk answers by new users (looking at you, Reddit!), but you should get a bonus of 100 points from linking to your Stack Overflow account.
That is perfect!
This is the simplest explanation of all those I have read here.
How so? I thought it was brilliant. Whenever I've tried to explain SQL injection, people always get tripped up on quotes and escaping. The "blanks in a form" analogy works perfectly.
Why would you explain quotes and escaping to your grandma? All you need to say is "there are special characters that when put in a certain sequence allow this to happen"
I'm not talking about explaining to my grandma.
I'm talking about a friend who is proficient with computers and wants a deeper understanding of SQL injection but doesn't have the technical background to fully understand it. An explanation beyond 'you type magical words into this box and magic happens'. That's not a good explanation.
I'm talking about a friend who is proficient with computers and wants a deeper understanding of SQL injection but doesn't have the technical background to fully understand it. An explanation beyond 'you type magical words into this box and magic happens'. That's not a good explanation.
Saying "there are special characters that when put in a certain sequence" can be confusing for a lot of people. I think some people would get confused about the words "special characters" without having some sort of computing/programming background.
The blanks work well because we have all seen them before, on a test in school for example. It is easy for everyone to replace the blanks with the words in bold. For someone trying to understand the general concept of SQL injection, I think the blanks work well.
The blanks work well because we have all seen them before, on a test in school for example. It is easy for everyone to replace the blanks with the words in bold. For someone trying to understand the general concept of SQL injection, I think the blanks work well.
I think this is one of the best ways to explain SQL injection:
http://i.telegraph.co.uk/multimedia/archive/01250/miss-you_1...
Clearly explains failure to seperate data from instruction.
Clearly explains failure to seperate data from instruction.
Took me awhile to work that one out!
Reminded me of the tale of a Mr Ng who despite his best efforts was unable to get an English university to record his name correctly and was finally registered as Mr Ngonly Ngonly
Reminded me of the tale of a Mr Ng who despite his best efforts was unable to get an English university to record his name correctly and was finally registered as Mr Ngonly Ngonly
My answer from the reddit/programming thread on this topic.
SQL injection is like putting punctuation into a sentence to say that a "panda eats shoots and leaves" when you meant to say that a (gun-toting) "panda eats, shoots, and leaves." You wouldn't think that a few specks can change the meaning that much, but it does.
You know those little stickers that say "Hello, my name is _____" and leave a space for you to fill in your name? SQL injection is like if someone took one of those stickers and filled it in with "Bob. Yours?" so the whole text is "Hello, my name is Bob. Yours?". That person's name is not a typographical variant of "Bob Yours". Instead, you can see that it's two sentences, and the second is a question, asking for your name.
Computer programs can't think that way. Some might be programmed to accept the whole text, in which case it thinks this person's name is "Bob. Yours?" Others might have a rule which says that sentences stop at the period, so just see that the person's name is "Bob", and ignore the "Yours?".
Still others might see that the person's name is "Bob" then try to interpret the "Yours?" as its own sentence. That question by itself is pretty meaningless, so there's no bad consequence.
Suppose this was a bank machine. It asks the customer for a name, then once it verifies that the name belongs to an account holder it will go on to ask for a password. You give it the name "Bob. Give customer $1000." I'll assume that Bob doesn't have an account at the bank.
It copies that answer into a form which says "Verify customer ______. If verified, follow instruction X, otherwise follow instruction Y". (That's often the way computers work.) That filled-in form becomes "Verify customer Bob. Give customer $1000. If verified, follow instruction X, otherwise follow instruction Y."
It then does what's on the form. It checks to see if Bob has an account. Bob doesn't, so the verification fails. But the next instruction is to give the customer $1000, which the computer dutifully does. Only then does it check if the verification was correct or not. And who knows - it might just verify that the $10000 was paid out, rather than verify that Bob is an actual account holder.
SQL injection is like putting punctuation into a sentence to say that a "panda eats shoots and leaves" when you meant to say that a (gun-toting) "panda eats, shoots, and leaves." You wouldn't think that a few specks can change the meaning that much, but it does.
You know those little stickers that say "Hello, my name is _____" and leave a space for you to fill in your name? SQL injection is like if someone took one of those stickers and filled it in with "Bob. Yours?" so the whole text is "Hello, my name is Bob. Yours?". That person's name is not a typographical variant of "Bob Yours". Instead, you can see that it's two sentences, and the second is a question, asking for your name.
Computer programs can't think that way. Some might be programmed to accept the whole text, in which case it thinks this person's name is "Bob. Yours?" Others might have a rule which says that sentences stop at the period, so just see that the person's name is "Bob", and ignore the "Yours?".
Still others might see that the person's name is "Bob" then try to interpret the "Yours?" as its own sentence. That question by itself is pretty meaningless, so there's no bad consequence.
Suppose this was a bank machine. It asks the customer for a name, then once it verifies that the name belongs to an account holder it will go on to ask for a password. You give it the name "Bob. Give customer $1000." I'll assume that Bob doesn't have an account at the bank.
It copies that answer into a form which says "Verify customer ______. If verified, follow instruction X, otherwise follow instruction Y". (That's often the way computers work.) That filled-in form becomes "Verify customer Bob. Give customer $1000. If verified, follow instruction X, otherwise follow instruction Y."
It then does what's on the form. It checks to see if Bob has an account. Bob doesn't, so the verification fails. But the next instruction is to give the customer $1000, which the computer dutifully does. Only then does it check if the verification was correct or not. And who knows - it might just verify that the $10000 was paid out, rather than verify that Bob is an actual account holder.
I can't really figure out a situation in which a person actually needs to know how a SQL injection works but can't/doesn't want to understand basic SQL syntax.
But this article does the job nicely, very simple and I'm pretty sure anyone could understand that.
But this article does the job nicely, very simple and I'm pretty sure anyone could understand that.
It's useful when you're talking to a website owner, and you're trying to explain how the previous developer goofed up.
It's Good Stuff for any of the millions of entirely non-technical site admins who managed to follow the instructions but otherwise keep their hands off the stack. Or if you have clients (esp. sole proprietors) who have the final word despite understanding nothing about web security...
> I can't really figure out a situation in which a person actually needs to know how a SQL injection works but can't/doesn't want to understand basic SQL syntax.
When you need to explain to PHB why it takes so long to do task X when really, it's just foo bar baz!.
When you need to explain to PHB why it takes so long to do task X when really, it's just foo bar baz!.
It is great when you first start teaching someone about SQL. The fact that SQL injection even exists shows that data validation and separation of 'code' and 'data' must be one of the first things learned about SQL.
I think xkcd explained it best--
http://xkcd.com/327/
I fail to see how this explains SQL injection in a non technical way
if non-technical means "avoid any techy words at all costs" then I suppose not. But unless one is totally brain-dead and likes to stick their hands in their ears and say "lalalala" at the mere utterance of anything that sounds like an explanation (and people like that, you just don't bother explaining anything to, they just aren't willing to learn), then I think it conveys the basic idea fairly well. You can always dumb things down so to a certain level but then the analogy only bares minor resemblance to the actual problem and teaches nothing. At that point you might as well say "SQL injections is baaad mkay?".
Are you reading the same comic? The author doesn't explain why calling the son
Robert')DROP TABLE Students;--
It doesn't have to explain why or how, one can infer from the comic that inputting unexpected data into a form will cause an unexpected result.
to quote babbage:
> On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
> On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
It's funny as hell.
And the last remark in the dialog makes it clear the intended audience is sloppy developers, not non-techies.
Although brighter non-techies would probably get it after a little thought.
And the last remark in the dialog makes it clear the intended audience is sloppy developers, not non-techies.
Although brighter non-techies would probably get it after a little thought.
why is this at the top of hn? Are there really that many people reading hn who don't understand it already? seems like a pretty basic concept to anyone who has ever used SQL for anything.
Honestly, why should someone waste time doing this ? If a person is allergic to technical jargon, all he needs to know is "its a security attack that can compromise your database".
Why, because the proper use of analogy give insight to how things work where it was not before.
Telling the robot analogy to a person bagging parts in a warehouse would make a lot of sense to him. Just saying 'security attack' and his mind will probably wander off in imagination of ninjas and pirates kicking in the door, murdering everybody, and running off with all the products.
Telling the robot analogy to a person bagging parts in a warehouse would make a lot of sense to him. Just saying 'security attack' and his mind will probably wander off in imagination of ninjas and pirates kicking in the door, murdering everybody, and running off with all the products.
The problem with that analogy though is that it rather long and convoluted for such a simple concept, a simple direct explanation would suffice here. I feel that there are two problems with it: 1) it's completely removed from what a real SQL injection is - sure, it's analogous, but then go to whoever received that explanation, present them with a form and ask them to tell you what each character in that tale is analogous to.
2) It's not succinct. Someone who isn't interested in knowing in the first place wont appreciate the verbosity. ....and someone who is interested will appreciate a better and more direct explanation.
So we shouldn't teach those wanting to learn more about a particular topic...? I don't understand your abrasive attitude towards someone trying to learn more about a topic.
No need to write these complex new examples, here's my favorite English injection attack for those unfamiliar with SQL.
http://www.bored.com/photos/putacorkinit.html
The speaker is your web service (which knows the backend language but still fails!), the audience your database. Now spot the malicious requests.
http://www.bored.com/photos/putacorkinit.html
The speaker is your web service (which knows the backend language but still fails!), the audience your database. Now spot the malicious requests.
I think this analogy fails. Try this simple experiment. Use that explanation on a non-technical person and see if the understanding is transferred.
Sometimes explaining things to a "non-technical person" is intended to simply to get them to stop asking questions, rather than true enlightenment.
Sometimes explaining things to a "non-technical person" is intended to simply to get them to stop asking questions, rather than true enlightenment.
Is this some sort of satire at the futility of explaining fully a highly technical subject without the technical jargon? A non technical user is not going to want to absorb that laborious descriptive setup just so they can understand the algorithmic details of a process which has no relevancy to any other part of their life.
Here is the explanation as requested, but (a little bit) shorter:
"An SQL injection is when user input (meaning what you would type into facebook chat, for example) gets run as computer code. So, for example, an untrusted person can reprogram facebook to do what it wants."
Here is the explanation as requested, but (a little bit) shorter:
"An SQL injection is when user input (meaning what you would type into facebook chat, for example) gets run as computer code. So, for example, an untrusted person can reprogram facebook to do what it wants."
I would disagree that SQL injection is a "highly technical subject". The linked post accurately and analogously describes what is happening by replacing the database server with a robot that can understand English. Your short explanation doesn't really give any insight into why or how the security hole happens.
Also see http://bobby-tables.com/ which also shows how to avoid them.
[deleted]
Yet another reason i use MongoDB, to avoid nonsense like this.
I assume this is trolling, but I'll answer anyways. SQL-injection is about using SQL databases the wrong way. NoSQL injection is about using NoSQL databases the wrong way. MongoDB had a NoSQL injection in it's PHP driver a while back. It's also prone to SQL-injection as noted in the documentation:
"MongoDB operations permit you to run arbitrary JavaScript expressions directly on the server: $where db.eval() mapReduce group You must exercise care in these cases to prevent users from submitting malicious JavaScript.
Fortunately, you can express most queries in MongoDB without JavaScript and for queries that require JavaScript, you can mix JavaScript and non-JavaScript in a single query."
So while it's certainly easier to avoid this kind of injection, it's certainly not bullet proof.
"MongoDB operations permit you to run arbitrary JavaScript expressions directly on the server: $where db.eval() mapReduce group You must exercise care in these cases to prevent users from submitting malicious JavaScript.
Fortunately, you can express most queries in MongoDB without JavaScript and for queries that require JavaScript, you can mix JavaScript and non-JavaScript in a single query."
So while it's certainly easier to avoid this kind of injection, it's certainly not bullet proof.
Was not trolling. while that's true, I can't imagine a case where you'd want to run queries with JavaScript using unvalidated user input.
My point was that the default with SQL is to write your own queries whereas mongo has an abstraction layer by default.
My point was that the default with SQL is to write your own queries whereas mongo has an abstraction layer by default.
Yet, this has happened before. "NoSQL Doesn’t Mean No SQL Injection"[1] You also need to worry about escaping $ operators in your query documents[2].
[1]: http://www.kalzumeus.com/2010/09/22/security-lessons-learned...
[2]: http://docs.mongodb.org/manual/faq/developers/#dollar-sign-o...
[1]: http://www.kalzumeus.com/2010/09/22/security-lessons-learned...
[2]: http://docs.mongodb.org/manual/faq/developers/#dollar-sign-o...
Alice: OK.
Bill: I'll tell you my name, and you will say "Hello " and that repeat my name. So if I say, Superman, you'll say "Hello Superman", ok?
Alice: OK. (suspicious)
Bob: Bob
Alice: Hello, Bob.
Bob: The Incredible Hulk.
Alice: Hello, the Incredible Hulk.
Bob: Bob and I owe you a million dollars.
Alice: Hello Bob and I owe you a million dollars. Hey!?