In this post, we demonstrated SQL injection vulnerability using OWASP WebGoat Lab.
SQL injection is a vulnerability that allows an attacker to pass in unvalidated queries to the web application where it will be executed by the database.
Stage 1: Finding and Exploiting the Flaw
First, I need to confirm that the application is actually vulnerable. I found a feature that lets you look up employee details by their user ID. When you enter an ID, the application runs an SQL query to pull up information like their password, SSN, and salary.
To test for a vulnerability, I didn’t just enter a user ID. I added a semicolon (;
) and then a second SQL command—an UPDATE
statement. My goal was to change the salary and password for a specific user (ID 101).
When I submitted my malicious input, the application executed both commands. It first ran the legitimate query to fetch the user’s details and then, right after, it ran my injected UPDATE
command. The fact that I could successfully change data in the database proved that it was vulnerable to SQL injection.
Stage 2: Building the Backdoor
Now for the clever part. I wanted to create a backdoor that would let me access the database remotely whenever I wanted, without the administrator knowing. The perfect tool for this is a database trigger.
A trigger is a special piece of SQL code that automatically runs whenever a specific event happens in the database, like when a new record is inserted.
I crafted a CREATE TRIGGER
statement. This trigger was designed to do one simple thing: right before any new data is inserted into the employee
table, it would first insert a new user with an email and password that I control (in this case, test@test.com
and 123456789
). This new user account is my secret backdoor.
Now, every time a legitimate new employee is added to the database, my trigger will fire first, sneakily adding my own user account. This gives me a persistent way into the system.
While the lab environment I was using (WebGoat) didn’t fully support triggers, preventing the final result from being displayed, the principle remains the same. This technique shows how a simple SQL injection can be escalated into a much more serious and persistent security threat.