Explain SQL injection without technical jargon

http://security.stackexchange.com/questions/25684/how-can-i-explain-sql-injection-without-technical-jargon#answer-25710

by justhw • 14 years ago

121 49 14 years ago

security.stackexchange.com

dromidas• 14 years ago

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.

evoxed• 14 years ago

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

yen2232• 14 years ago

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

pixl972• 14 years ago

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.

lloeki• 14 years ago

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

mullingitover• 14 years ago

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

coin• 14 years ago

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

mung3• 14 years ago

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

est• 14 years ago

http://www.schneier.com/blog/archives/2008/04/sql_injection_...

http://gizmodo.com/5498412/sql-injection-license-plate-hopes...

teyc• 14 years ago

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• 14 years ago

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

marshray• 14 years ago

More succinct:

"Knock knock."

jayfuerstenberg2• 14 years ago

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

benesch2• 14 years ago

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.

noahc• 14 years ago

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"

MichaelGG2• 14 years ago

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.

jayfuerstenberg2• 14 years ago

That is perfect!

grandpoobah• 14 years ago

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

jeltz• 14 years ago

This is the simplest explanation of all those I have read here.

lubujackson• 14 years ago

"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

wglb• 14 years ago

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.

easternmonk• 14 years ago

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

pixl972• 14 years ago

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.

mung3• 14 years ago

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.

hadem2• 14 years ago

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.

hayksaakian2• 14 years ago

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

eoftedal2• 14 years ago

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.

hayksaakian2• 14 years ago

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.

JohnsonB• 14 years ago

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• 14 years ago

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.

thefreeman• 14 years ago

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.

TannerLD• 14 years ago

I'm pretty sure it is at the top more for the creativity of the explanation.

tkxxx7• 14 years ago

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

eoftedal2• 14 years ago

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.

barking• 14 years ago

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

draegtun• 14 years ago

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

InclinedPlane• 14 years ago

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.

dalke• 14 years ago

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.

lostnet• 14 years ago

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.

Explain SQL injection without technical jargon

Related Stories