SQL INJECTION

A Technical Seminar Report

in partial fulfillment of the degree

Bachelor of Technology

in

Computer Science & Engineering

by

CH.VIDYA (16K41A0510)

Submitted to

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

S R ENGINEERING COLLEGE (A), ANANTHASAGAR, WARANGAL

(Affiliated to JNTUH, Accredited by NAAC A Grade)

2019-2020


DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

CERTIFICATE

This is to certify that the Seminar Report entitled “ SQL INJECTION” is a record
of bonafide work carried out by the student CH.VIDYA bearing Roll No(s)
16K41A0510 during the academic year 2019-20 in partial fulfillment of the award
of the degree of Bachelor of Technology in Computer Science & Engineering by
the Jawaharlal Nehru Technological University, Hyderabad.

Seminar Incharge Head of the Department

S R ENGINEERING COLLEGE 2 16K41A0510



ACKNOWLEDGEMENT

I wish to take this opportunity to express my sincere and deep sense of respect to
our beloved principal Dr. V Mahesh, S R Engineering College for providing an
excellent academic atmosphere in the institution.

I express heartfelt thanks to the Head of Department, Computer Science &

Engineering Mr A. Srinvas for providing me with necessary infrastructure and
thereby giving me freedom to carry out the work.

I also thank the other staff members and friends who assisted me. Finally, I thank
my parents who inspired me always to do the best

S R ENGINEERING COLLEGE 3 16K41A0510



Table of Contents
1. Introduction
1.1. What is SQL Injection?
1.2. What is the impact of a successful SQL Injection attack?
2. Types of SQL Injection
2.1. In-band SQLi
2.2. Inerential (Blind) SQLi
2.3. Out-of-band SQLi
3. Classfication of SQL Injection attacks
3.1. Order Wise
3.2. Blind
3.3. Against Database
4. SQL Injecton Examples
5. How dangerous are SQL Injections?
6. How to detect SQL Injection Vulnerabilities?
7. Best Practices to prevent SQL Injection attacks

S R ENGINEERING COLLEGE 4 16K41A0510



INTRODUCTION

WHAT IS SQL INJECTION?

SQL injection is a web security vulnerability that allows an attacker to interfere with the queries that an
application makes to its database. It generally allows an attacker to view data that they are not normally
able to retrieve. This might include data belonging to other users, or any other data that the application itself
is able to access. In many cases, an attacker can modify or delete this data, causing persistent changes to
the application's content or behavior.

In some situations, an attacker can escalate an SQL injection attack to compromise the underlying server
or other back-end infrastructure, or perform a denial-of-service attack.

Structured Query Language (SQL) is a language designed to manipulate and manage data in a database.
Since its inception, SQL has steadily found its way into many commercial and open source databases. SQL
injection (SQLi) is a type of cybersecurity attack that targets these databases using specifically crafted SQL
statements to trick the systems into doing unexpected and undesired things.

The objective of SQL Injection Attack (SQLIA) is to shaft the database system into running harmful code
that can reveal confidential information. Hence we can say that Sql injection attack is an unauthorized
access of database. In this paper we tried an attempt to classify the type of SQL Injection Attacks in order
to enhance the security of database.

Actions a successful attacker may take on a compromised target include:

• Bypassing authentication
• Exfiltrating/stealing data
• Modifying or corrupting data
• Deleting data
• Running arbitrary code
• Gaining root access to the system itself

WHAT IS THE IMPACT OF A SUCCESSFUL SQL INJECTION ATTACK?

A successful SQL injection attack can result in unauthorized access to sensitive data, such as passwords,
credit card details, or personal user information. Many high-profile data breaches in recent years have been
the result of SQL injection attacks, leading to reputational damage and regulatory fines. In some cases, an
attacker can obtain a persistent backdoor into an organization's systems, leading to a long-term compromise
that can go unnoticed for an extended period.

S R ENGINEERING COLLEGE 5 16K41A0510



Types of SQL Injection

An SQL injection is a technique that attackers apply to insert SQL query into input fields to then be
processed by the underlying SQL database. These weaknesses are then able to be abused when entry
forms allow user-generated SQL statements to query the database directly.

To give you a typical scenario, take a typical login form consisting of a user/email field and a password
field. After the login info is submitted, it is combined with an SQL query on your web server.

1. In-band SQLi

The attacker uses the same channel of communication to launch their attacks and to gather their results.
In-band SQLi’s simplicity and efficiency make it one of the most common types of SQLi attack. There
are two sub-variations of this method:

• Error-based SQLi—the attacker performs actions that cause the database to produce error
messages. The attacker can potentially use the data provided by these error messages to gather
information about the structure of the database.
• Union-based SQLi—this technique takes advantage of the UNION SQL operator, which fuses
multiple select statements generated by the database to get a single HTTP response. This response
may contain data that can be leveraged by the attacker.
2. Inferential (Blind) SQLi

The attacker sends data payloads to the server and observes the response and behavior of the server to
learn more about its structure. This method is called blind SQLi because the data is not transferred from
the website database to the attacker, thus the attacker cannot see information about the attack in-band.

Blind SQL injections rely on the response and behavioral patterns of the server so they are typically
slower to execute but may be just as harmful. Blind SQL injections can be classified as follows:

• Boolean—that attacker sends a SQL query to the database prompting the application to return a
result. The result will vary depending on whether the query is true or false. Based on the result, the
information within the HTTP response will modify or stay unchanged. The attacker can then work
out if the message generated a true or false result.

• Time-based—attacker sends a SQL query to the database, which makes the database wait (for a
period in seconds) before it can react. The attacker can see from the time the database takes to

S R ENGINEERING COLLEGE 6 16K41A0510



respond, whether a query is true or false. Based on the result, an HTTP response will be generated
instantly or after a waiting period. The attacker can thus work out if the message they used returned
true or false, without relying on data from the database.

3. Out-of-band SQLi

The attacker can only carry out this form of attack when certain features are enabled on the database
server used by the web application. This form of attack is primarily used as an alternative to the in-
band and inferential SQLi techniques.

Out-of-band SQLi is performed when the attacker can’t use the same channel to launch the attack
and gather information, or when a server is too slow or unstable for these actions to be performed.
These techniques count on the capacity of the server to create DNS or HTTP requests to transfer
data to an attacker.

Classification of SQL Injection Attacks

S R ENGINEERING COLLEGE 7 16K41A0510



1. Order Wise
First Order Injection Attack:

First-order Injection Attacks are when the attacker receives the desired result immediately,
either by direct response from the application they are interacting with or some other response
mechanism, such as email etc.

Second Order Injection Attack:

Second Order injection Attack is the realization of malicious code injected into an application by
an attacker, but not activated immediately by the application. The malicious inputs are seeded by
the attacker into a system or database. This is used to indirectly trigger an SQLIA which is used
at later time. The attacker usually relies on where the input will be subsequently used and thus
crafts his attack. Second order injection leaves a ticklish job of detection and prevention. This is
because the point of injection is different from the point where the attack actually manifests it.

Lateral Injection Attack:

Lateral Injection Attack is a technique that is used to compromise Oracle databases remotely. The
attack exploits some common data types, including DATE and NUMBER, which do not take any
input from the user and so are not normally considered to be exploitable. The database can be
manipulated by an attacker just by using a bit of creative coding.

Classical SQL injection Attack

S R ENGINEERING COLLEGE 8 16K41A0510



The classical exploitation of SQL injection vulnerabilities provides an opportunity to merge two
SQL queries. This redeems the purpose to gain additional data from a certain table. To access
the information from the Database Management System would become easier with the help of
classical SQL injection.

2. Blind SQL Injection Attack

When web application is vulnerable to an SQL injection but the results of the injection are
hidden to the attacker, blind SQLA is used. The displayed page may be different from the original
one. This depends on the results of a logical statement injected into the legitimate SQL statement
called for that page. The blind SQLIA allows the threat agent to infer the construct of the
database through evaluating expressions that are coupled with statements that always evaluate to
true and statements that always evaluate to false.

The Blind SQL injection can further be classified as:

Standard Blind

Sometimes it is impossible to exploit an SQL Injection vulnerability using classical technique

that involves application of <union> operator and separator<”;”>. In this situation, Standard
Blind SQLIA is implemented. It allows one to write and read files and get data from tables
provided only the entries are read symbol-by-symbol.

This kind of attack can further be classified as:

Classical Based Blind SQL Injection

This attack is based on analysis of true/ false logical expression. If the expression is true,
then the web application will return certain content, and if it is false, the application will return
content.

Error-Based Blind SQL Injection

The error based blind SQL Injection is the quickest technique of SQL Injection exploitation. The
august of this method is that the valuable information of various DBMSs can be stored into the
error messages in case of receiving illegal SQL expression. This technique can be used if
any error of SQL expression processing occurred in the DBMS is returned back by the
vulnerable application.

Double Blind SQL Injection

S R ENGINEERING COLLEGE 9 16K41A0510



Double blind SQL Injection is a technique in which all error messages and vulnerable queries are
excluded from the page returned by the web application and the request results do not influence
the returned page. Exploitation of this kind of vulnerability uses only time delays under SQL
query processing; i.e., it is false if an SQL query is executed immediately, but if it is executed
with an N-second delay, then it is true.

3. Against Database

On the basis of attack against the database management system, SQL injection attack can be
classified as:

SQL Manipulation

The most common type of SQL Injection attack is SQL manipulation. The attacker attempts
to modify the existing SQL statement.

This SQL manipulation attack can be classified as:

Tautology

The aim of a tautology-based attack is to inject code in one or more conditional statements
such that the evaluation is always true. In this type of SQLIA, an attacker exploits an injectable
field that is used in a query’s WHERE conditional i.e. the queries always return results upon
evaluation of a WHERE conditional parameter. All the rows in the database table targeted by the
query are returned while transforming the conditional into a tautology. Example: In this example,
an attacker submits “ ’ or 1=1 - -” for the login input field (the input submitted for the other
fields is irrelevant). The resulting query is:

SELECT accounts FROM users WHERE

login=’’ or 1=1 -- AND pass=’’ AND pin=

The code injected in the conditional (OR 1=1) transforms the entire WHERE clause into a
tautology.

Inference
In this attack, the query is being modified into the form of an action which is executed based
on the answer to a true/-false question about data values in the database. In this type of
injection, attacker try to attack a site that is enough secured not to provide acceptable
feedback via database error messages when an injection has succeeded. The attacker must
use a different method to obtain the response from the database since database error messages are

S R ENGINEERING COLLEGE 10 16K41A0510



unavailable to him. In this situation, the attacker injects commands into the site and then
observes how the function/response of the website changes. By carefully observing the changing
behavior of the site , attacker can extrapolate not only vulnerable parameters, but also additional
information about the values in the database. Researchers have reported that with these
techniques they have been able to achieve a data extraction rate of 1B/s .

Example:

Consider two possible injections into the login field. The first being “legalUser’ and 1=0 - -” and
the second, “legalUser’ and 1=1 - ”.These injections result in the following two queries:

SELECT accounts FROM users WHERE login=’legalUser’

and 1=0 -- ’ AND pass=’’ AND pin=0

SELECT accounts FROM users WHERE login=’legalUser’

and 1=1 -- ’ AND pass=’’ AND pin=0

In the first scenario, the application is secure and the input for login is validated correctly. In this
case, both injections would return login error messages, and the attacker would know that the
login parameter is not vulnerable. In the second scenario, application is insecure and the login
parameter is vulnerable to injection. The attacker submits the first injection and, gets a login
error message, because it always evaluates to false. However, the attacker does not know if
this is because the application validated the input correctly and blocked the attack attempt or
because the attack itself caused the login error. The attacker then submits the second query, which
always evaluates to true. If in this case there is no login error message, then the attacker knows
that the attack went through and that the login parameter is vulnerable to injection.

Basic Union Queries

With this technique malicious user tricks the server to return data that were not intended to be
returned by the developers. In this attack, an attacker exploits a vulnerable parameter to change
the data set returned for a given query. Attackers do this by injecting a statement of the form:
UNION SELECT <rest of injected query>.Since the attacker control the second/injected
query completely, they can use it to retrieve information from a specified table. The result
of this attack causes the database to returns dataset that is the union of the results of the original
first query and the results of the injected second query.

Piggy-Backed Queries

S R ENGINEERING COLLEGE 11 16K41A0510



In this SQLIA, attackers do not aim to modify the query instead; they try to include new and distinct
queries into the original query. This result database to receive multiple SQL queries and can be
proved extremely harmful. Example: If the attacker inputs “’; drop table users - -” into the pass
field, the application generates the query:

SELECT accounts FROM users WHERE login=’doe’

AND pass=’’; drop table users -- ’ AND pin=123

After execution of first query, the database would recognize the query delimiter (“;”) and
proceed for the injected second query. The execution of second query would lead to drop table
‘users’, which would likely damage valuable information.

Code Injection

Code injection attacks attempt to add additional SQL statements or commands to the existing
SQL statement. This type of attack is frequently used against Microsoft SQL Server
applications, but seldom works with an Oracle database.

This attack can be classified as:

LIKE Queries

The attacker attempts to manipulate the SQL statement using like queries. Consequently, user
input incorporated into a LIKE query parameter can subvert the query, complicate the LIKE
match, and in many cases, prevent the use of indices, which slows a query substantially. With a
few iterations, a compromised LIKE query could launch a Denial of Service attack by
overloading the database.

Example:

$sub = mysql_real_escape_string (“%something”); // still %something

mysql_query (“SELECT * FROM messages WHERE subject LIKE ‘{$sub}%’”)

Column Number Mismatch

To accumulate the knowledge of this type of injection, consider a random example. Let the
original query is:

SELECT product_name FROM all_products WHERE product_name like '&Chairs&'

Then the attack would be:

SELECT product_name FROM all_products WHERE product_name like ''

S R ENGINEERING COLLEGE 12 16K41A0510



UNION ALL

SELECT 9,9 FROM SysObjects WHERE ‘’ = ‘’

Above query would give errors that indicate that there is mismatch in the number of columns and
their data type in the union of SysObjects table and the columns that are specified using 9. The
error “Operand type mis-match” is mainly because the data type mis-match in the Union clause
caused by the injected string. Another error we might see is “All queries in an SQL Statement
containing a UNION operator must have an equal number of expressions in their target list” is
because the number of columns is not matching.

After multiple trial and errors a statement like this may succeed.

SELECT product_name FROM all_products WHERE product_name like ''

UNION ALL

SELECT 9,9, 9,’ Text’, 9 FROM SysObjects WHERE ‘’ = ‘’

Result set of the above query will show all the rows in the SysObjects table and will also show
constant row values for each row in the SysObjects table defined in the query.

Additional WHERE clause

The case arises where there may be additional WHERE condition in the SL statement that gets
added after the injected string.

SELECT firstName, LastName, Title from Employees

WHERE City = ’ “& strCity &” ‘ AND Country = ‘INDIA’ “

On the first attempt after injecting the string the resulting query would look like:

SELECT firstName, LastName, Title from Employees

WHERE City = ‘NoSuchCity’

UNION ALL

Select OtherField from OtherTable

WHERE 1 = 1 AND Country = ‘USA’

Above query will result in a Error Message like this: Invalid column Name ‘Country’ because
‘OtherTable’ does not have a column called ‘Country’. In case the backend is MS SQL Server,
the problem can be solved using “;--“ to get rid of the rest of the query string.

S R ENGINEERING COLLEGE 13 16K41A0510



Insert – Subselect Query

The use of advanced insert query can help the attacker to access all the records of the database.

Example:

INSERT INTO tableName values (‘ “ ‘ + (SELECT TOP 1 Fieldname FROM tableName ) + ’ ‘ ,

‘xyz@xyz.com’ , ‘240402364’).

Where ever this information displayed to the user typically places like pages where the users are
allowed to edit user information. In the above attack the first value in the FieldName will be
displayed in place of the user name. If TOP 1 is not used , there will be an error message
“subselect returned too many rows”. Attacker can go through all the records using NOT in
clause.

Functional Call Injection

Function call injection is the insertion of database functions into a vulnerable SQL statement.
These function calls can be used to make operating system calls or manipulate data in the
database.

This can be classified as:

Role Foundation

Press Releases are provided through their portal in many companies. Typically the user
requests for a press release would look like:

http://www.somecompany.com/PressRelase.jsp?PressRealeaseID=5

The corresponding SQL statement used by the application would look like:

Select title, description, releaseDate, body from pressRelease

WHERE pressRelaseID=5

All the information requested corresponding to the 5th press release is returned by the database
server. This information is formatted by the application in an HTML page and provided to the
user.

If injected string is 5 AND 1 = 1 and application still returns the same document then application
is susceptible to SQL injection attack.

System Stored Procedures

S R ENGINEERING COLLEGE 14 16K41A0510



In this type of SQLIAs the attacker tries to execute stored procedures present in the database. If
the running backend server is known, the attacker perpetrates his attack to exploit the stored
procedure. If he is able to inject SQL string successfully then stored procedures are no safer. The
access to the system store procedures depends on the access privileges of the application user on
the database. Most of the time, output may be absent on the screen as would in case of a normal
SQL statement when a stored procedure is executed successfully.

Buffer Overflow

In several databases Buffer overflows have been identified. Some database functions are
susceptible to buffer overflows that can be exploited through a SQL injection attack in an unpatched
database. Most application and web servers are unable to handle the loss of a database connection
due to a buffer overflow. Usually, the web process hangs until the connection to the client is
terminated, thus making this a very effective denial of service attack.

SQL injection examples:

There are a wide variety of SQL injection vulnerabilities, attacks, and techniques, which arise in different
situations. Some common SQL injection examples include:

• Retrieving hidden data: where you can modify an SQL query to return additional results.
• Subverting application logic: where you can change a query to interfere with the application's
logic.
• UNION attacks: where you can retrieve data from different database tables.
• Examining the database: where you can extract information about the version and structure of the
database.
• Blind SQL injection: where the results of a query you control are not returned in the application's
responses.

How dangerous are SQL injections?

If completed successfully, SQL injections have the potential to be incredibly detrimental to any business or
individual. Once sensitive data is compromised in an attack, it can be difficult to ever fully recover.
Databases are commonly targeted for injection through an application (such as a website, which requests
user input and then does a lookup in a database based on that input), but they can also be targeted directly.

How to detect SQL injection vulnerabilities?

The majority of SQL injection vulnerabilities can be found quickly and reliably using Burp Suite's web
vulnerability scanner.

S R ENGINEERING COLLEGE 15 16K41A0510



SQL injection can be detected manually by using a systematic set of tests against every entry point in the
application. This typically involves:

• Submitting the single quote character ' and looking for errors or other anomalies.
• Submitting some SQL-specific syntax that evaluates to the base (original) value of the entry point,
and to a different value, and looking for systematic differences in the resulting application
responses.
• Submitting Boolean conditions such as OR 1=1 and OR 1=2, and looking for differences in the
application's responses.
• Submitting payloads designed to trigger time delays when executed within an SQL query, and
looking for differences in the time taken to respond.
• Submitting OAST payloads designed to trigger an out-of-band network interaction when executed
within an SQL query, and monitoring for any resulting interactions.

Best Practices to prevent SQL Injection Attacks

To keep your database safe from the SQL Injection Attacks, you can apply some of these main prevention
methods:

1. Using Prepared Statements (with Parameterized Queries)

Using Prepared Statements is one of the best ways to prevent SQL injection. It’s also simple to write and
easier to understand than dynamic SQL queries.

This is where the SQL Command uses a parameter instead of inserting the values directly into the command,
thus prevent the backend from running malicious queries that are harmful to the database. So if the user
entered 12345 or 1=1 as the input, the parameterized query would search in the table for a match with the
entire string 12345 or 1=1.

2. Using Stored Procedures

Stored Procedures adds an extra security layer to your database beside using Prepared Statements. It
performs the escaping required so that the app treats input as data to be operated on rather than SQL code
to be executed.

The difference between prepared statements and stored procedures is that the SQL code for a stored
procedure is written and stored in the database server, and then called from the web app.

If user access to the database is only ever permitted via stored procedures, permission for users to directly
access data doesn’t need to be explicitly granted on any database table. This way, your database is still safe.

S R ENGINEERING COLLEGE 16 16K41A0510



3. Validating user input

Even when you are using Prepared Statements, you should do an input validation first to make sure the
value is of the accepted type, length, format, etc. Only the input which passed the validation can be
processed to the database. It’s like checking who is at the door of your house before you open it and let
them in.

But remember, this method can only stop the most trivial attacks, it does not fix the underlying vulnerability.

4. Limiting privileges

Don’t connect to your database using an account with root access unless required because the attackers
might have access to the entire system. Therefore, it’s best to use an account with limited privileges to limit
the scope of damages in case of SQL Injection.

5. Hidding info from the error message

Error messages are useful for attackers to learn more about your database architecture, so be sure that you
show only the necessary information. It’s better to show a generic error message telling something goes
wrong and encourage users to contact the technical support team in case the problem persists.

6. Updating your system

SQL injection vulnerability is a frequent programming error and it’s discovered regularly, so it’s vital to
apply patches and updates your system to the most up-to-date version as you can, especially for your SQL
Server.

7. Keeping database credentials separate and encrypted

If you are considering where to store your database credentials, also consider how much damaging it can
be if it falls into the wrong hands. So always store your database credentials in a separate file and encrypt
it securely to make sure that the attackers can’t benefit much.

Also, don’t store sensitive data if you don’t need it and delete information when it’s no longer in use.

8. Disabling shell and any other functionalities you don’t need

Shell access could be very useful indeed for a hacker. That’s why you should turn it off if possible. Remove
or disable all functionalities that you don’t need too.

S R ENGINEERING COLLEGE 17 16K41A0510