SQL Injection Tutorial: Learn with Example
Data is one of the most vital components of information systems. Database powered
web applications are used by the organization to get data from customers. SQL is
the acronym for Structured Query Language. It is used to retrieve and manipulate
data in the database.
What is an SQL Injection?
SQL Injection is an attack that poisons dynamic SQL statements to comment out
certain parts of the statement or appending a condition that will always be true. It
takes advantage of the design flaws in poorly designed web applications to exploit
SQL statements to execute malicious SQL code.
In this Lesson, you will learn SQL Injection techniques and how you can protect web
applications from such attacks.
• How SQL Injection Works
• Hacking Activity: SQL Inject a Web Application
• Other SQL Injection attack types
• Automation Tools for SQL Injection
• How to Prevent against SQL Injection Attacks
• Hacking Activity: Use Havji for SQL Injection
How SQL Injection Works
The types of attacks that can be performed using SQL injection vary depending on
the type of database engine. The attack works on dynamic SQL statements. A
dynamic statement is a statement that is generated at run time using parameters
password from a web form or URI query string.
Let’s consider a simple web application with a login form. The code for the HTML
form is shown below.
<form action=‘[Link]’ method="post">
<input type="email" name="email" required="required"/>
<input type="password" name="password"/>
<input type="checkbox" name="remember_me" value="Remember me"/>
<input type="submit" value="Submit"/>
</form>
HERE,
• The above form accepts the email address, and password then submits them
to a PHP file named [Link].
• It has an option of storing the login session in a cookie. We have deduced this
from the remember_me checkbox. It uses the post method to submit data.
This means the values are not displayed in the URL.
Let’s suppose the statement at the backend for checking user ID is as follows
SELECT * FROM users WHERE email = $_POST['email'] AND password =
md5($_POST['password']);
HERE,
• The above statement uses the values of the $_POST[] array directly without
sanitizing them.
• The password is encrypted using MD5 algorithm.
We will illustrate SQL injection attack using sqlfiddle. Open the
URL [Link] in your web browser. You will get the following window.
Note: you will have to write the SQL statements
Step 1) Enter this code in left pane
CREATE TABLE `users` (
`id` INT NOT NULL AUTO_INCREMENT,
`email` VARCHAR(45) NULL,
`password` VARCHAR(45) NULL,
PRIMARY KEY (`id`));
insert into users (email,password) values ('m@[Link]',md5('abc'));
Step 2) Click Build Schema
Step 3) Enter this code in right pane
select * from users;
Step 4) Click Run SQL. You will see the following result
Suppose user supplies admin@[Link] and 1234 as the password. The
statement to be executed against the database would be
SELECT * FROM users WHERE email = 'admin@[Link]' AND password =
md5('1234');
The above code can be exploited by commenting out the password part and
appending a condition that will always be true. Let’s suppose an attacker provides
the following input in the email address field.
xxx@[Link]' OR 1 = 1 LIMIT 1 -- ' ]
xxx for the password.
The generated dynamic statement will be as follows.
SELECT * FROM users WHERE email = 'xxx@[Link]' OR 1 = 1 LIMIT 1 -- ' ] AND
password = md5('1234');
HERE,
• xxx@[Link] ends with a single quote which completes the string quote
• OR 1 = 1 LIMIT 1 is a condition that will always be true and limits the returned
results to only one record.
• -- ' AND … is a SQL comment that eliminates the password part.
Copy the above SQL statement and paste it in SQL Fiddle Run SQL Text box as
shown below
Hacking Activity: SQL Inject a Web Application
We have a simple web application at [Link] that is vulnerable
to SQL Injection attacks for demonstration purposes only. The HTML form code
above is taken from the login page. The application provides basic security such as
sanitizing the email field. This means our above code cannot be used to bypass the
login.
To get round that, we can instead exploit the password field. The diagram below
shows the steps that you must follow
Let’s suppose an attacker provides the following input
• Step 1: Enter xxx@[Link] as the email address
• Step 2: Enter xxx') OR 1 = 1 -- ]
• Click on Submit button
• You will be directed to the dashboard
The generated SQL statement will be as follows
SELECT * FROM users WHERE email = 'xxx@[Link]' AND password = md5('xxx')
OR 1 = 1 -- ]');
The diagram below illustrates the statement has been generated.
HERE,
• The statement intelligently assumes md5 encryption is used
• Completes the single quote and closing bracket
• Appends a condition to the statement that will always be true
In general, a successful SQL Injection attack attempts a number of different
techniques such as the ones demonstrated above to carry out a successful attack.
Other SQL Injection attack types
SQL Injections can do more harm than just by passing the login algorithms. Some of
the attacks include
• Deleting data
• Updating data
• Inserting data
• Executing commands on the server that can download and install malicious
programs such as Trojans
• Exporting valuable data such as credit card details, email, and passwords to
the attacker’s remote server
• Getting user login details etc
The above list is not exhaustive; it just gives you an idea of what SQL Injection
Automation Tools for SQL Injection
In the above example, we used manual attack techniques based on our vast
knowledge of SQL. There are automated tools that can help you perform the attacks
more efficiently and within the shortest possible time. These tools include
• SQLSmack - [Link]
• SQLPing 2
- [Link]
• SQLMap - [Link]
How to Prevent against SQL Injection Attacks
An organization can adopt the following policy to protect itself against SQL Injection
attacks.
• User input should never be trusted - It must always be sanitized before it is
used in dynamic SQL statements.
•
• Prepared statements –prepared statements to work by creating the SQL
statement first then treating all submitted user data as parameters. This has
no effect on the syntax of the SQL statement.
•
• Regular expressions –these can be used to detect potential harmful code
and remove it before executing the SQL statements.
•
• Database connection user access rights –only necessary access rights
should be given to accounts used to connect to the database. This can help
reduce what the SQL statements can perform on the server.
•
• Error messages –these should not reveal sensitive information and where
exactly an error occurred. Simple custom error messages such as “Sorry, we
are experiencing technical errors. The technical team has been contacted.
Please try again later” can be used instead of display the SQL statements that
caused the error.