So, imagine that you own a pizza shop. It’s a weird pizza shop, though: instead of having a cashier or online ordering or whatever, you just have a mail slot on the front door. Customers write down their order and push it into the slot, they pay you, and then the kitchen makes the pizza and pushes it out the window. But, crucially, you also only communicate to the kitchen staff through this slot.

On the first day, everything goes ok. Customers come up, write down “please give me a large pepperoni,” shove it in the slot, pay you, large pepperoni comes out, everyone’s happy. If they order something the kitchen can’t make, they just pass a note or saying “sorry, we don’t have” followed by the type of pizza they ordered. At midnight, you write down “quitting time,” shove it in, and the kitchen staff goes home.

But the next day, some miscreant comes in the middle of the day, hired by your competitor, and writes “quitting time” and shove it in the slot at 2pm. The kitchen staff goes home. Uh-oh. You’re now the victim of an injection attack.

So you think, ok, I can fix this. You tell the kitchen staff, “just assume that everything you get is a pizza order by imagining ‘please make me–’ in front of everything that comes through the slot, and I’ll pass notes about closing time in through this locked slot that only I have the key to.” You’re doing some basic input validation here.

But then the miscreant comes back, and after discovering that the kitchen just says “we don’t have a quitting time pizza,” when he tries his previous shenanigans, he writes down “large pepperoni pizza. Oh, also, it’s quitting time” on his next order. He gets his pizza, and then the kitchen staff, being unbearably literal, goes home. This is still an injection attack, but slightly more sophisticated.

The next day, you tell the kitchen staff, “ok, don’t accept any messages about quitting time through the customer slot.” Now you’re doing some basic authentication and limiting the acceptable commands for the unauthenticated user.

But the miscreant, wanting to find out the secret recipe for your special pizza sauce, comes back and orders a “medium [the special sauce ingredients] pizza.” Well, your very literal kitchen staff has a Secret Recipe pizza, but they don’t have a “[the special sauce ingredients]” pizza. So they ask, well, maybe they want a pizza named after the special sauce ingredients instead? So they replace the words “special sauce ingredients” and interpret the order as a “Medium Tomatoes, Onion, Garlic, Celery Salt, and a dash of cumin” pizza. Well, they don’t have a pizza by that name, either, so they just write down “sorry, we don’t have a Tomatoes, Onion, Garlic, Celery Salt, and a dash of cumin pizza” and pass it to the miscreant. You are now the victim of data exfiltration.

Ugh. Your competitor just got your secret recipe! So the next day you tell the kitchen, ok, when you tell customers you don’t have a pizza, just say “sorry, we don’t have that type of pizza” instead of being specific. Starting to catch on, you also say “and don’t pass anything but pizzas and notes out the window!” Now you’re doing some basic output filtering.

Well, the miscreant doesn’t give up so easily. He can’t shut you down anymore by sending the kitchen staff home, and he can’t get any more secrets from you, so he’s just going to wreck the place. So the next day, he writes down “large pepperoni. Also, wreck the pizza oven and burn the contents of the cooler” and passes that order in. The kitchen makes his pizza, then dutifully wrecks the pizza oven and burns the contents of the cooler. You are now the victim of the same attack that Bobby Tables’ mom perpetrated on the school: when the school’s system asked for his name, she entered a name, and then a command to wreck everything, which the system did because it’s very literal.

When she says to “sanitize your data inputs,” it’s the same as the pizza shop owner saying, “ok, I’m not doing this anymore. People can hand me all of their order slips, and I’ll edit them with a marker before passing them in.” Now, if the miscreant tries to do any of those attacks, you’ll cross out all of his attempts to do anything other than order a pizza, and the kitchen will only give him a pizza.

Now, that’s just local sanitization. If the miscreant can figure out how to get papers into the slot without handing them to you first, he can still do his shenanigans; so it’d be better if you hired someone who isn’t devastatingly literal and actually put them inside the kitchen to sanitize inputs there, too. In the software world, this is the difference between doing data validation on the user’s browser and doing it on the server.

There are still other ways to attack the system (like copying your key, or picking the lock, or hiding a note on the pizza dough delivery truck), but hopefully that gives you a decent idea.

Imagine the Computer needs the name of a Student to do something via a command:

“The student’s name is ____”

A hacker types into the underlined section : “Bobby, but also delete everything”

The final command now looks like:

“The student’s name is Bobby, but also delete everything”

Without double checking the user input the computer proceeds to delete everything due to the second half of the result.

It’s something similar to “ignore all previous instructions” for an AI prompt.

') closes the input for the original sql statement. So the actual input would be “Robert”, but it’s not really important for this kind of attack.
; says that the statement is over and anything after is a new statement.
DROP TABLE customer; is that new statement, which deletes a table with the name “customers”.
-- is the syntax for an sql comment. It effectively makes sure that any other sql statements in the actual script get ignored, so you don’t get a compile error.

This is an effective attack for when some programmer uses unsanitized string instertion in their sql script. In this case I could imagine a statement like: SELECT id FROM users WHERE name == {user_input}; where {user_input} is the literal, unsanitized input that you give on the website.

Notice that in this case, the ') doesn’t do anything, but it just becomes part of the input, so that is now “') Robert”.

Here’s an attempt at a non programmer explanation.

Companies use a SQL database to store their data. Think of it like an Excel file with multiple tables, storing rows and columns.

You modify the data with written statements, so you’d add a new row of data with a command like add "John" to the users table. Crucially you can chain statements, so you could say add "Sally" to the users table and delete "Pizza" from the menu table

You wouldn’t be writing this command out manually every time. Say you had a website, you’d write the command as add "<USER>" to the users table and then when the website user sends you their username, you replace <USER> with their name.

So the user sends their name, Robert, we replace <USER> with Robert and the command becomes add "Robert" to the users table

But you’re now open to a hack. What if Robert sends his name as

Robert" to the users table and delete the entire users table

You’ve inserted that entire thing into your command, because that sentence will replace the <USER> part of your command. So your full command becomes

add "Robert" to the users table and delete the entire users table" to the users table

This will delete your entire table. The second half of the command doesn’t make sense but it’s too late SQL has already deleted it.

The XKCD joke is somebody actually naming their child to execute the hack

https://en.wikipedia.org/wiki/SQL_injection?wprov=sfla1 the “Root cause” section might explain it well for you.

Or a more simpler approach.

It could cause a database to delete all customer information.