
Explain SQL injection without technical jargon - justhw
http://security.stackexchange.com/questions/25684/how-can-i-explain-sql-injection-without-technical-jargon#answer-25710
======
teyc
Bill: Hi Alice, want to play a game?

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!?

~~~
Sodel
This is probably the most succinct and intuitive analogy for SQL injection
that I've ever seen.

~~~
marshray
More succinct:

"Knock knock."

------
InclinedPlane
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.

------
lubujackson
"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

------
jayfuerstenberg
That robot warehouse analogy was perhaps more confusing than just explaining
SQL injection as is.

~~~
MichaelGG
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.

~~~
grandpoobah
This needs to be on the SO page, far better.

~~~
roryokane
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-...](http://security.stackexchange.com/questions/25684/how-can-i-
explain-sql-injection-without-technical-jargon#comment42222_25684)

~~~
MichaelGG
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.

~~~
m_myers
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.

------
eoftedal
I think this is one of the best ways to explain SQL injection:
[http://i.telegraph.co.uk/multimedia/archive/01250/miss-
you_1...](http://i.telegraph.co.uk/multimedia/archive/01250/miss-
you_1250350i.jpg)

Clearly explains failure to seperate data from instruction.

~~~
barking
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

------
dalke
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.

------
dromidas
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.

~~~
yen223
It's useful when you're talking to a website owner, and you're trying to
explain how the previous developer goofed up.

------
mullingitover
I think xkcd explained it best-- <http://xkcd.com/327/>

~~~
coin
I fail to see how this explains SQL injection in a non technical way

~~~
mung
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?".

~~~
yen223
Are you reading the same comic? The author doesn't explain _why_ calling the
son

    
    
        Robert')DROP TABLE Students;--
    

would cause the records to disappear. Which is fair enough: it's meant to be
humourous, not explanatory.

~~~
mung
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.

~~~
chii
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.

------
thefreeman
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.

~~~
tkxxx7
It's about explaining it to people who generally _aren't_ on HN and/or have no
programming experience.

------
easternmonk
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".

~~~
pixl97
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.

~~~
mung
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.

------
lostnet
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.

------
wglb
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.

------
JohnsonB
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."

~~~
fragsworth
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.

------
draegtun
Also see <http://bobby-tables.com/> which also shows how to avoid them.

------
hayksaakian
Yet another reason i use MongoDB, to avoid nonsense like this.

~~~
eoftedal
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.

~~~
hayksaakian
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.

~~~
saurik
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...](http://www.kalzumeus.com/2010/09/22/security-lessons-learned-from-
the-diaspora-launch/)

[2]: [http://docs.mongodb.org/manual/faq/developers/#dollar-
sign-o...](http://docs.mongodb.org/manual/faq/developers/#dollar-sign-
operator-escaping)

