Whenever you visit a website or use some kind of application, that website or app needs to pull data from a database.
For example, let’s say I visit Cybr.com. When I do that, I’m asking for the home page of that website.
That home page is made up of all sorts of data, so Cybr’s backend servers go “ok yeah, here’s what the home page looks like.”
The overall structure of the page comes from backend code, but most of the data you see like the text, courses listed, etc, comes from a database.
Prefer watching videos over reading? Here you go:
What is SQL?
For code to be able to access this data from a database, it has to use some sort of query language. For many types of relational databases, we can use the Structured Query Language, or SQL for short (also sometimes pronounced sequel).
SQL is a language that was designed specifically to interact with database engines.
For example, if I want to pull a list of the 5 latest courses to display on the home page, my code could use a query that looks a bit like this:
SELECT name, description, banner FROM Courses ORDER BY DatePublished LIMIT 5;
Sometimes, instead of hardcoding a query as we see here, we may need to use dynamic values that we can’t predict ahead of time. As an example, if we want to give visitors the option to search through a list of courses, we could do that by giving them a search box, where they can then type their search query.
That search query would then get used in an SQL query to search the databases:
Taking user-submitted data like this is often referred to as user input, user data, or (in the cybersecurity world) untrusted inputs.
How SQL Injections are made possible
Considering it untrusted is vital for security reasons, and here’s why:
If we do not treat input as potentially dangerous, then we can leave our database vulnerable due to SQL Injections.
The reason is because a malicious visitor could end up crafting an attack payload that completely changes the purpose and meaning of our original SQL query. Now, instead of our SQL query running a search against our database, an attacker could submit an SQL injection payload into the search query:
' UNION SELECT id, email, password FROM Users--
Which would instead turn our SQL query into this:
As you can see, this is a totally different query! We’ve allowed a complete stranger to change what our application is sending to our database, which could allow them to extract data from our database that they shouldn’t be able to see; such as passwords, emails, credit cards, etc…
Impact of SQL injections
Or, as I’ve demonstrated in my courses, it could be used to bypass admin login panels entirely.
It could even let you write your own data to the database, such as to create your own admin users, or make changes to its settings in order to completely compromise or break it.
SQL injections can have an extremely high impact if security controls aren’t properly implemented, and this is just one example of how that could happen.
Preventing SQL injections
With that said, if you have the right security controls, you can prevent this type of attack, and that’s why if enter the above SQL injection payload in a search box on this website, nothing bad happens and the user input is simply treated as regular text.
If you’d like to learn more about SQL injections like how to craft payloads and how to find vulnerabilities, or how to protect your code in order to make sure no one can do this to it, there are plenty of free resources that can help you learn! For example, OWASP has multiple free resources to explain what they are, and they even include resources that explain how to prevent and how to test for them.
If you enjoyed this post, check out our Explained YouTube playlist for more content like this. I’m also curious to hear if you’re reading this post to learn how to find SQL injections or to learn how to prevent them in your code, so leave a comment below with your thoughts!
Thanks for reading, and see you next time.