Explain SQL injection without technical jargon

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

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.

"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

Clearly explains failure to seperate data from instruction.

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.

But this article does the job nicely, very simple and I'm pretty sure anyone could understand that.

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.

Sometimes explaining things to a "non-technical person" is intended to simply to get them to stop asking questions, rather than true enlightenment.

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