Introduction to SQL Injection Page 1 of 8

Introduction to SQL Injection

by: Lee Lawson, 06/06/2005

http://www.securitydocs.com/library/3348

Introduction
It is very hard to understand the conceptual idea of SQL injection without partially understanding the code that runs in the
background. With this paper I hope to explain, with the help of some examples, just how easy it is to exploit a system with SQL
injection and how to defend against it.

Basics
Structured Query Language (SQL) is used for many database systems including Microsoft SQL Server, Oracle, MySQL and
even Microsoft Access in a cut-down version. Because of its extensive use, SQL injection attacks have a widespread problem
throughout not only the internet, but also corporate LAN’s with bespoke database applications.

SQL is relatively easy to read, a little more difficult to write, but with some very rudimentary knowledge of how it is constructed
SQL injection attacks become child’s play.

There is a necessity to understand the different types of SELECT commands that are mostly used to retrieve information from
a database. Below are some examples of simple SELECT strings, where a result is retrieved based upon a user inputted
value.

Query

SELECT name FROM names WHERE name = ‘’

Database table names.

Name Phone E-mail

Lee J Lawson 0131 12345678 bigdaddy@SQL.com

This line will retrieve the contents of the data field name from the table names, where the input matches a record. Nothing will
be returned if no match is found. If, however, more than one match is found, multiple records will be retrieved.

Result if input = Lee J Lawson

Lee J Lawson

Query

SELECT name, phone, email FROM names WHERE email = ‘’

Databast table names.

http://www.securitydocs.com/link.php?action=detail&id=3348&headerfooter=no 6/6/2005
Introduction to SQL Injection Page 2 of 8

Name Phone E-mail

Lee J Lawson 0131 12345678 bigdaddy@SQL.com

This string is similar to the first although it will return multiple data fields from the record based upon the inputted value.

Result if input = bigdaddy@SQL.com

Lee J Lawson, 0131 12345678, bigdaddy@SQL.com

Query

SELECT * FROM customers WHERE name = ‘’ AND password = ‘’

Databast name customers.

Name Password Account Number

Lee J Lawson P@ssw0rd 123456789

This line is different in that it will return everything, as denoted by the * from the table customers, but only if the data field name
is matched with its related password field. If a match is found for name, but the related password field is not matched, then
nothing is returned.

Query.

SELECT * FROM customers WHERE name = ‘’ OR email = ‘’

Database table Customers.

Name Phone E-mail

Lee J Lawson 0131 12345678 bigdaddy@SQL.com

The above string is important as this is where SQL injection is born. This string will return everything from the table customers
if a match is found for name OR if a match is found for email.

Result if input = bigdaddy@SQL.com

Lee J Lawson, 0131 12345678, bigdaddy@SQL.com

Result if input = Lee J Lawson

Lee J Lawson, 0131 12345678, bigdaddy@SQL.com

Connection Properties
Each and every connection to a database has a number of properties associated with it; these may include the username and
password that the connection is running as. Although an attacker may not be able to see the properties of the connection,
whatever is typed into the user input field is processed at the level of those credentials. Here is an example connection string:

Provider=SQLOLEDB.1; Persist Security Info=False; User ID=SA; Password=D@tab@se;

Initial Catalog=CustomerRecords; Data Source=127.0.0.1; Workstation ID=win2kAccoun

http://www.securitydocs.com/link.php?action=detail&id=3348&headerfooter=no 6/6/2005
Introduction to SQL Injection Page 3 of 8

In the above connection string, the properties show that the users interface is using the SA account with a password of
D@tab@se. This is a massive security problem because of the account being used. The SA account is the System
Administrator, this is the most powerful account on a MS SQL server and is similar to the Administrator account on a Windows
box. Would any administrator allow unknown users on the internet to connect to one of their servers with the Administrator
account? That is exactly what is happening here but with the SA account. Because of this, any input via a web front for
example, would be processed as the most powerful account available. Therefore, if an attacker inputs malicious code, any
number of commands could be processed at administrator level credentials thereby opening a door into the internal corporate
LAN. Some commands can even traverse out of the SQL server application and start interrogating the Windows sub-system.

Manipulating the Input

Now that we have seen how query strings are supposed to work, let’s have a look at how we can manipulate the user input
field to pass commands to the database server. First we should look at how the full line of code is constructed in the
background. Imagine we are using a web front end to log onto a database server to retrieve information. We may have
something similar to the following log on prompt:

The point that needs to be understood is where the two user input fields, Username and Password fit into the SQL query. If
they are being used to directly build the query string, then the application is vulnerable to SQL injection. If the application is
using the SA account as its credentials, then the application is not only vulnerable, but vulnerable in the most extreme manner.

Below, I have given an example of a poorly devised string of code. This code will take the user input fields, and apply them to
a query to interrogate the database.

SELECT * FROM customers WHERE name = ‘ & name & ’ AND password = ‘ & password &

The input fields name and password are used directly inside the query so that the processed command looks like the
following:

SELECT * FROM customers WHERE name = ‘Lee J Lawson’ AND password = ‘P@ssw0rd

http://www.securitydocs.com/link.php?action=detail&id=3348&headerfooter=no 6/6/2005
Introduction to SQL Injection Page 4 of 8

This would work with no problems, but now let’s change the user input data…

SELECT * FROM customers WHERE name = ‘’ OR 1=1 --’ AND password = ‘’

The SQL injection script ‘ OR 1=1 -- may allow an attacker to bypass the security and retrieve information from the database
that should not be allowed.

It works as follows:

SELECT * FROM customers WHERE name = ‘’ OR 1=1--’ AND password = ‘’

‘ - Closes the user input field. OR - Continues the SQL query so that the process should equal what came before OR what
comes after. 1=1 - A true statement. -- - Comments out the rest of the line so that it will not be processed.

So if we look at what this actually means we can see the following:

Select everything from the table customers if the name equals ‘’ (nothing!) or if 1=1. Ignore anything that follows on this line.

Seeing as 1 will always equal 1, the server has received a true statement and is fooled into allowing an attacker more access
than they should have. The code that refers to the password input field is never run by the server and therefore does not
apply.

This is a very simplistic example of SQL injection, but more powerful commands exist which will allow a very quick
enumeration of the database.

SELECT name, phone, email FROM users WHERE name = ‘’ OR 23=23; SELECT * FROM *

‘’

‘ - Closes the user input field.

OR - Continues the SQL query so that the process should equal what came before OR what comes after
23=23 - A true statement.
; - Start a new SQL command.
SELECT - SELECT query
* FROM * - Retrieve every data field from every table in the database.
-- - Comments out the rest of the line so that it will not be processed.

Pretty much any SQL command will work in this instance. The reason that any command will work is because the user input is
used in the query string, instead of validating the input and then passing it to the query string, eg:

1 strname = name
strpassword = password

2 IF len(strname) > 20
THEN Strname = ‘’
Msgbox “The name is too long!”

http://www.securitydocs.com/link.php?action=detail&id=3348&headerfooter=no 6/6/2005
Introduction to SQL Injection Page 5 of 8

3 IF len(strpassword) < 8
THEN strpassword = ‘’
msgbox “The password is not long enough!”

4 Strsql = “SELECT * FROM customers WHERE name =‘ & strname & ’ AND password =‘ & strpassword &

The above code is written in Visual Basic and performs rudimentary validation on the two user input fields.

1. Two variables are populated with the contents of the user input fields.
2. A check is made on the length of the name, if it is longer than 20 characters the variable is blanked and a message box
appears stating that the name is too long.
3. A further check is then made on the length of the password, if it is less than 8 characters long a message box tells the
user and the variable is cleared.
4. After the basic checks have been conducted, the variables, not the user input are then passed to the SQL string and
are used to construct the query.

Of course the checks shown above are very basic and easily gotten around, although with stronger more resilient code, much
more can be done to check the user input is indeed valid and suitable to be passed to the server.

Example SQL Injection Scripts

Below are a few examples SQL injection scripts, many more can be found by doing a simple Google search for SQL injection.

‘ OR ‘a’=’a (Works on Microsoft Access.)

‘ OR 1=1 --
‘ OR 1=1 ; --
‘; SELECT * FROM * ; --

Any of the above scripts can be entered into a database front end like this:

http://www.securitydocs.com/link.php?action=detail&id=3348&headerfooter=no 6/6/2005
Introduction to SQL Injection Page 6 of 8

Extended Stored Procedures

Stored procedures are large pieces of code or very often run smaller pieces of code that are stored on the server and run by a
simple command. There are many reasons that stored procedures exist, one of which is that any code can be centrally
managed from the server. A bigger reason is by sending a command word to the server and receiving a result set, network
traffic has been massively reduced from the normal. Normally all of the code is stored on the client side application, i.e. web
browser and it is transmitted to the server for processing, then the results are sent back.

There are two types of stored procedures, user defined and extended. User defined, as the name suggests are created by the
database developers for the purpose of the application and data. Extended stored procedures are system defined by the SQL
server application. It is the extended stored procedures that are the most dangerous if an attacker has the ability to run them.

SP_WHO

This will display all users that are currently connected to the database.

XP_READMAIL,,,,,@PEEK=’FALSE’

MS SQL Server can be used as an email repository for mail servers. With the above command you can peek at the emails
stored there, to ‘peek’ means to read the email and leave the message flagged as unread.

XP_REVOKELOGIN{[@LOGINAME=]’SA’}

This command will prevent the SA account from logging onto the server, a powerful DoS attack.

XP_CMDSHELL

This will open a command shell on the victim server at the credentials of the connection, eg SA. This is a very powerful stored
procedure and will allow access to the operating system on the box that the SQL server application is installed on.

Vulnerable Systems
How do we know that a system is vulnerable? There are two ways to find out. The first is to look closely at the underlying code
and identify segments that may allow unauthorized access.

The second is to do exactly as a potential attacker would do. Simple type a single quote (‘) into a user input field and read the
error message. Going back to the SQL injection examples given earlier, if we place a single quote (‘) into the field we will
attempt to process the following:

SELECT name, phone FROM customers WHERE name = ‘’’

This will open a user input field, close it and then open another. As a user input field has been opened and not closed, the
SQL server will display something similar to the following message:

http://www.securitydocs.com/link.php?action=detail&id=3348&headerfooter=no 6/6/2005
Introduction to SQL Injection Page 7 of 8

Microsoft OLE DB Provider for ODBC Drivers

error ‘80040e14’
([Microsoft][ODBC Microsoft Access Driver] Extra )
In query expression ‘Username=’’’ AND Password =‘’
/_employees/login3.asp, line 49

The important item to note is the error number 80040e14. If this is the error that is returned, then the server is vulnerable to
SQL injection. There are other useful pieces of information in the above error message such as how the query string is
constructed (Username = ‘’ AND Password =’’), the web page and the line of code that the error occurred on. These could help
an attacker in compiling a buffer overflow attack against a system.

Defense & Counter-Measures

Defense of any system should be a layered blend of protection. This applies to database systems as it does to any network.

Robust network architecture design will aid in the defense of any enterprise. The following diagram shows a defensible
network design by utilizing a De-Militarized Zone (DMZ) to hold all ‘public facing’ servers.

Any attacker can easily make a connection to the SQL server as it has to be accessible to the internet and legitimate users.
The green arrow denotes an authorized connection from the attacker to the SQL server. If the attacker wants to penetrate
further into the network, they would have to evade the second firewall, this is not easily done with a good firewall system that is
configured correctly and kept up to date. The two firewall design has added an extra layer of protection to any sensitive
servers on the internal network.

Another defensive measure includes creating specific accounts on the server for specific tasks. For example, if a web front
end requires read only access, an account should be created with read only access to the database. If a front end requires full
control over the data, an account should be created with full control to the areas required; this should never be the SA

http://www.securitydocs.com/link.php?action=detail&id=3348&headerfooter=no 6/6/2005
Introduction to SQL Injection Page 8 of 8

account. When the full control access is no longer needed, the connection should be reverted to minimal access privileges.

With regard to the validation of user input, single quotes (‘) should not be allowed to be processed by the server as it can
identify the database as vulnerable to SQL injection. Maximum and minimum length of input fields should be considered. If a
username can be no longer that 20 characters, then do not allow any input longer than 20 characters, it goes the same for
minimum length of passwords.

It is also a very simple process to identify known SQL injection access to the database.

Verbose error messages such as the error that displays the This will help to disguise any vulnerable applications.

3 D’s
The 3 D’s refer to when database administrators and developers should think about security.

Design
During the design phase of any new application, consider how best to protect the back end with solid, robust code.

Default
The default settings for an application should have security factors considered.

Deployment
How to deploy and install a new product without compromising the back end, do you require the user to be a local
administrator for example.

Summary
Defense in depth is the key to securing any network; the same approach should be taken to securing a database back-end
and client side application. Robust network architecture, user input validation and good database administration all must be
adopted for a solid defense.

By following the defensive measures mentioned above, a database system can be protected so as to protect against a high
percentage of known attacks. The hacking communities are continually working to find new security flaws with any system and
may find wholes in any security layer designed to protect your system, with this in mind all users, administrators and
developers should keep their security skills up to date with training.

http://www.securitydocs.com/link.php?action=detail&id=3348&headerfooter=no 6/6/2005