|
|
SQL DATABASE - INJECTION ATTACK
NIC-CIRT Advisory #2003-1
Incident Title: Poor input
validation leads to SQL Injection Attack
- Overview:
Because of poor input validation,
it is possible to submit unauthorized SQL code to an
application for execution on the server.
- Description:
SQL Injection is a technique for
exploiting the server through Web application, which uses
client-supplied inputs in SQL queries without stripping
harmful character first. An attacker creates or alters the
existing SQL command by inserting unintended / malicious data
to gain access or to execute system level command on the host.
Structured Query Language is a
textual language used by most popular scripting language as
ASP, JSP, PHP, CGI etc. to interact with relational databases
like Oracle, MySQL, MSSQL, DB2. Web based application interact
with database using SQL to dynamically built pages containing
required information for the user. The SQL 'query' is
generated by application from the set of inputs received from
the client and combining with static parameters. SQL 'query'
is a collection of statements that typically return a single
'result set'. SQL statements can modify the structure of the
databases and manipulate the contents of databases depending
upon the privileges.
If the input supplied is in such a
form that it results in executing a set of SQL statements,
which is not intended by the application, then the incident is
referred to as SQL Injection. Even if the application sends a
set of invalid command as SQL query to the
database, and the server responds, then also SQL Injection is
successful.
SQL Injection is caused in applications where the developer uses '
String- Building' technique to execute SQL code, without proper input
validation.. The attacker can exploit this and can get information about the
table and then retrieve or alter the contents of the table. The attacker can
execute system commands using stored procedures.
- Impact:
This vulnerability can lead to unauthorized access to the database and
illegal use of the server. Following damages can be caused by the
attacker:
Modifying the Table contents
Retrieving the Table contents
Concatenating SQL statements
Adding generic function calls and stored procedures
Bypassing Authorization
Creating illegal users with privileges to the extent of administrator
- Solution:
It is
important for the developer to thoroughly check input
validation. It is recommended that the administrator should
check their released application for SQL Injection
vulnerability.
Testing the application for
vulnerability
Since an
application is developed by a team rather than an individual. One vulnerable
script may expose the application to the SQL vulnerability. It is essential to
thoroughly check the Web application for input validation at client end as well
as at the server end before passing the query to SQL engine. Disable Error
Handling procedure before doing the vulnerability test.
Replace the
argument of each parameter with a single quote and a SQL keyword as "where".
Each parameters should be tested separately leaving all other parameters
unchanged and as expected.
Evaluating
Result In the above
test, if you get database server error message of any kind, SQL injection can
be successful.
Apart from
this, also search through the entire source of the returned page for the
keyword such as "ODBC", "SQL Server" or syntax errors as well as hidden
database error message in the header. If any such keyword is received in the
error message page, then SQL injection can be successful.
Preventing
the application from the Exploit. A. Input
Validation
- 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.
-
In multi tiered environment data should be validated before submitting to the SQL server. 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. The Developer should also make it a point to always restrict the
size of the input taken from the user. Developer should also check the type of
input.
-
If the input is a number verify the data type using ISNUMERIC or equivalent function or converting into an
integer 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,','')
-
Use stored procedures to abstract data access to avoid direct access to the table.
-
While using stored procedures, implement using command object as ADODB in case of ASP.
-
Stored procedures that are not being used may be deleted such as: master_xp_cmdshell, xp_sendmail,
xp_startmail, sp_makewebtask
-
Check the behavior of the application with errand and malicious input such as in case a user supplying the
content of MPEG file in place of the desired input.
-
Check the application in case a user supplies SQL command statements instead of the esired input in a text
field. Example DROP Table, UPDATE etc.
- Never
build transact SQL statement directly from the user input.
- Never
concatenate user input that is not validated. String concatenations are the
primary point of entry for script injection.
- Make
sure not to accept strings in feilds from which file name may be constructed as
AUX, COM, CON, LPT1 and PRN.
- Whenever
possible reject input that contains following potentially dangerous characters.
|
Input
Character
|
Meaning
in Transact-SQL
|
|
:
|
Query
delimiter
|
|
'
|
Character
data string delimiter
|
|
--
|
Comment
delimiter
|
|
/*
. */
|
Comment
delimiters. Text between /* */ is not evaluated by the server.
|
|
Xp_
|
Begins
the name of catalog extended stored procedures such as xp_cmdshell.
|
Also
filter out characters like slash, backslash, extended characters like NULL,
carry return, newline in all strings from user input and parameters from
URL.
- Data
Sanitization: All client supplied data needs to be cleansed and
filtered before passing into the queries. Striping codes (putting "\") and
filter the data with a default deny regular expression. Data sanitization
should be done at the server end.
If
symbols or punctuation of any kind is required, convert it to HTML substitutes
such as " "e;" or ">". For submitting email address allow
numbers, Letters, and only the symbols "@", "_",
"." and "-". In case of these
symbols, they should be first converted into their HTML substitutes.
B.
Special attention must be given for installation of Database Server. Default configuration should be modified
to suit requirements and to avoid usage of known parameters. For example user
'sa' account password may be changed, default sample databases like Northwind
may be removed. This is to avoid to unnecessary attempt to gaining database
information through SQL injection.
C.
Privileges of the user account used in the application for executing SQL statements on the database must be
defined.
Systems
affected: Immaterial of the server type, any application is vulnerable
to SQL Injection if it is poorly coded and without proper input validation.
This attack requires only port 80 open in the Web server. So if the proper
precaution is not taken while designing and developing the application, a well
patched and well secured Web server can also be attacked.
SQL injection
is possible in all type of SQL Server ( MySQL, Oracle, DB2, MSSQL ) with
varying degree irrespective of the Web Server Such as IIS , Apache etc. Supports
'INTO OUTFILE'
Runs often as
"roots"
Most modules
and libs do not support multiple-statements.
Subselects
possible
UNION
possible
Comes with
many stored procedure(utf_files!)
No
multiple-statements
Subselects
possible
UNION
possible
Stored
procedures
No
multiple-statements
Subselects
possible
UNION
possible
Stored
procedures
Multiple
statements are possible!
Many
dangerous default stored procedures(xp_cmdshell, sp_adduser)
-
Credit:
-
For First Time Reporting on NIC-CIRT:Cyber Security Division, NIC (Hq), N. Delhi
-
For release of Advisory / Incident Note: Arpita Burman and Snigdha Acharya, Cyber Security Division,
NIC (Hq), N. Delhi
Release
Details:
Original
release date: 18th July 2003
Last
revised: --
^
TOP ^
|
|