In this part of my cybersecurity learning journey, I worked through a PortSwigger Web Security Academy lab about getting hidden data using SQL injection techniques.
They used the example of a shopping application that shows products in different categories. You click on a category and it shows you the contents of that category:
We’re interested here in the query string at the end of the URL. In this case it’s
?category=AccessoriesThat gets sent to the backend where the application uses it to query a database. The lab explained the SQL query may look something like this:
SELECT * FROM products WHERE category = 'Accessories' AND released = 1To be completely honest, as a beginner, I did wonder:
How would I know about the “AND released = 1” part just from looking at the query string?
The answer is: I probably wouldn’t know from the query alone… But hey-ho. I guess it’s just for the purposes of showing us a simplified version of what goes on behind the scenes. In a real-world situation we’d probably be testing the application’s behaviour and making guesses based on its responses.
So to break it down, that SQL query runs like this:
Hey database! SELECT everything FROM the products table
WHERE the category is Accessories
AND WHERE released is equal to 1. K thx bye.Suspending the disbelief that I would know about the released=1 condition for a moment (and assuming that released=0 is for unreleased products let’s assume that the app doesn’t have any defense against SQL injection at all. We can try and attack it by changing that query string to something like:
?category=Accessories'--
You can see we how have another product showing called “Cheshire Cat Grin”. Basically we made an alteration to the SQL query that the application would send. Now it would be something like this:
SELECT * FROM products WHERE category = 'Accessories'--' AND released = 1Notice that double dash? In SQL, that indicates what follows next is a comment and should be ignored. Therefore it’s completely removed from the query. So now we’re gettling all the accessories!
We can also do something similar for get absolutely everything by changing the query string to:
?category=Accessories'+OR+1=1--That gives us the SQL query:
SELECT * FROM products WHERE category = 'Accessories' OR 1=1--' AND released = 1The key part here is:
OR 1=1This works because 1=1 is always true. So now we’re saying:
Hey database! SELECT everything from the products table
WHERE the category is 'Accessories'
OR you know... Whatever. K thx bye.This works because we are now asking for a catergory called ‘Accessories’ OR any category that is true. This basically means it contains any value except false or 0. This makes it output everything in the products table and it also clears the lab!
Important warning
One thing the lab points out is that even a simple-looking injection like:
OR 1=1can be dangerous!
It might seem harmless when you are only retrieving products from a test shop, but some applications use the same input in multiple database queries.
If that injected condition reached an UPDATE or DELETE statement, it could potentially modify or delete far more data than intended.
So this is something to practise only in safe, legal environments like PortSwigger Web Security Academy labs, deliberately vulnerable apps, or your own test systems.
What I learned
The main thing I took away from this lab is that SQL injection is not magic. It is about understanding how user input can accidentally become part of a database query.
The category value in the URL looked harmless, but because the application trusted it too much, it was possible to change the logic of the SQL query.
That is why secure applications need to validate input properly and, more importantly, use safe database queries rather than directly building SQL strings from user input.
Later, we’ll look at ways to mitigate these problems, but not before exploring more SQL injection vulnerabilities! So thanks for sticking around and learning. Until the next time, until the next tutorial: Catch you later! Bye bye!