SQL Injection: What’s On Top and Under the Hood
By M. Crawley
SQL injection makes a lot more sense once you see what happens on both the frontend and the database itself.
When I studied SQL injection for my certification exams, the explanations always felt vague. You'd get a definition about how attackers can manipulate database queries through user input, maybe see a sanitized example, then move on to the next topic. I understood the concept in theory, but I didn't really get it.
So I built a vulnerable web application on purpose, connected it to an Azure database, and tested SQL injection attacks to see what happens on both the frontend and backend. Apparently, it is simpler and more impactful than I imagined.
What Actually Happens
SQL injection works because applications build database queries by combining SQL commands with user input directly. When the application doesn't validate or sanitize the input, that's when an attacker can inject their own SQL commands into the query.
Here's a basic example: a login form might build its query like this:
SELECT * FROM Users WHERE username = 'admin' AND password = 'password123'
That looks fine if someone enters legitimate credentials. But what if someone types this into the username field: 'admin' OR '1'='1'--
The query sent back to the database then becomes:
SELECT * FROM Users WHERE username = 'admin' OR '1'='1'--' AND password = ''
That -- comments out everything after it, and the OR '1'='1' is always true. So the query returns all users, and the application logs you in as the first user returned, resulting in a successful authentication bypass.
Testing This in Practice
I built a bookshop web application with intentional vulnerabilities for my portfolio project. Nothing too complex, just a basic e-commerce setup with user accounts, product listings, and orders. I wanted to see how SQL injection actually manifests outside of textbooks and YouTube videos.
The first thing I tested was authentication bypass on the login pages. I used that admin' OR '1'='1'-- payload, and got access to user accounts without knowing any passwords. When the injection attack worked and I confirmed that both the regular and admin login panels were really vulnerable, that was my "holy crap, this really works" moment.
Then I moved to the search functionality in the books catalog. This is where it got interesting because I found out I could do much more than just bypass authentication. I began extracting data from the database using UNION SELECT statements. This let me query other tables without much resistance.
I enumerated the database structure first to see what tables existed. Then I extracted user data like names, emails, and passwords (not hashes, remember I said vulnerable web app). Then I started pulling the fake payment card information I stored in the database, including CVV numbers that should never be stored according to PCI DSS. Imagine if this were a real environment, the attacker just hit the jackpot!
All of this took me about 1 hour once I understood the vulnerability. There were no sophisticated tools involved, just basic SQL injection payloads.
Why This Still Matters
After testing this myself, I checked OWASP's Top 10 web application security risks and found that injection attacks rank at number 3. That's not some obscure vulnerability that rarely happens. It's consistently one of the most common and exploitable web application flaws.
The reason it ranks so high is because of how common it is in poorly secured applications and how devastating the impact can be. Authentication bypass can give attackers administrative access and data extraction exposes customer information. In some cases, attackers can even modify or delete database contents!
My testing environment was intentionally vulnerable, but I reviewed the Azure audit logs afterward to see what this looks like from a defender's perspective. The malicious SQL code showed up clearly in the logs. That tells me that, with proper monitoring, organizations can detect SQL injection attempts, but you need to know what to look for and have monitoring actually set up.
The Gap Between Theory and Practice
Building and testing this vulnerability myself gave me a practical understanding that complements my theoretical understanding. The cert exams teach you that SQL injection exists and that parameterized queries prevent it. True, but vague, and intentionally so.
This exercise helped me understand why developers need to use parameterized and you also get a clearer understanding of why input validation matters.
What This Means for Learning
If you're studying cybersecurity and SQL injection feels abstract, build a vulnerable test environment. It does not need to rival any company's production environment or be complex, just a local setup where you can safely test these attacks. Actually typing those SQL injection payloads and seeing the results teaches you a lot and sets off a light bulb.
Use tools like Wapiti or sqlmap to see how automated scanning finds these vulnerabilities, then compare those results to what you found manually. Understanding both the manual techniques and how automated tools work makes you much more effective.
Most importantly, don't just learn that SQL injection exists. Learn how it breaks things, what it exposes, how to detect it in logs, and how to actually prevent it in code. That way, when you're working in the field, you understand the gravity of this vulnerability and how critical remediation attempts are.