SQL Injection Lab: Bypass a Login Without the Password

This article describes an interactive lab demonstrating SQL injection through a vulnerable login page that concatenates user input directly into SQL queries. The lab teaches how attackers can bypass authentication by injecting SQL syntax—specifically using quotes and comments—to alter query logic without knowing credentials. SQL injection remains prevalent in real-world applications and appears in major breaches, making this a foundational vulnerability that every security learner should understand.

• How the vulnerable login query worksMiniMail builds its login query through string concatenation: SELECT * FROM users WHERE username='[your input]' AND password='[your input]'. User input sits directly inside single quotes within the SQL code, meaning the database cannot distinguish between developer-written SQL and attacker-supplied input once the string is assembled.
• The injection attack mechanismAn attacker enters a single quote in the username field to close the developer's quote early, followed by a SQL comment marker (two dashes and a space). This transforms the query to match the admin user while the comment syntax causes the database to ignore the password check and remaining query text, allowing login without credentials.
• Why string concatenation causes the vulnerabilityThe core problem is that user input is joined into a single string with SQL code before the database processes it. Once combined, the database cannot tell which characters are intended as data versus SQL commands, allowing an attacker's quote to end strings and their comments to remove logic the developer wrote.
• Real-world impact and prevalenceSQL injection has driven some of the largest breaches on record and remains in the OWASP Top 10. A 2023 example involved SQL injection in MOVEit Transfer file-sharing product, which was exploited at mass scale and affected thousands of organizations, demonstrating the vulnerability's continued practical relevance.
• Parameterised queries as the primary defenseThe article identifies parameterised queries (prepared statements) as the real fix, sending user input as parameters separate from SQL code rather than concatenating strings. Using an ORM or query builder correctly, without raw string queries, also provides protection, whereas blocklists of quotes or keywords are unreliable because attackers can bypass them.
• Additional security measuresRunning the database account with least privilege provides secondary defense by limiting what an attacker can do even if injection succeeds. However, the article emphasizes this is not a replacement for proper input handling.
• Connection to other injection vulnerabilitiesThe article notes that understanding SQL injection transfers directly to prompt injection, suggesting the underlying principle—user input altering code logic—applies across different contexts and attack surfaces.

Bottom line: SQL injection remains a critical vulnerability because developers concatenate user input into SQL queries, allowing attackers to alter query logic using quotes and comments rather than knowing actual credentials. The definitive defense is using parameterised queries so input always stays data, never code—a principle that also applies to preventing prompt injection and other injection attacks.