') 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. DROPTABLE 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”.
As for the sanitisation, it can take many forms. Either characters that don’t usually appear in the context for that field (in terms of names, you can usually scrub most parentheses, more than one hyphen in a row etc) can be removed; copy it to a known encoded field such as unicode to get rid of characters with unusual properties; and making sure bounds are enforced to avoid overflows.
It should mean that your data is exactly that - raw data, and not commands or operands for the interpreter to act upon.
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 tableanddelete "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
I still don’t understand it after all these years.
https://en.wikipedia.org/wiki/SQL_injection?wprov=sfla1 the “Root cause” section might explain it well for you.
')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”.The obvious parade here is to be semi-illiterate when you create your database and name your field “costumer”
Spot on.
As for the sanitisation, it can take many forms. Either characters that don’t usually appear in the context for that field (in terms of names, you can usually scrub most parentheses, more than one hyphen in a row etc) can be removed; copy it to a known encoded field such as unicode to get rid of characters with unusual properties; and making sure bounds are enforced to avoid overflows.
It should mean that your data is exactly that - raw data, and not commands or operands for the interpreter to act upon.
Parameterisation entirely solves the problem without needing to sanitise the string
Not entirely (I recall seeing some obscure CVEs some years ago), but it’s a hell of a lot better than what some coders try to get away with.
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 sayadd "Sally" to the users table and delete "Pizza" from the menu tableYou 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 tableand 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 becomesadd "Robert" to the users tableBut you’re now open to a hack. What if Robert sends his name as
Robert" to the users table and delete the entire users tableYou’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 tableThis 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
Or a more simpler approach.
It could cause a database to delete all customer information.
Even simpler: shotgun blasts the physical machine
It’s more fun and exciting too!