mailing list archives
Re: SQL injection attacks
From: "Steven" <steven () slashmail org>
Date: Tue, 6 Mar 2007 14:07:29 -0500 (EST)
Good papers out there addressing SQL injection in general and especially
blind(folded) SQL injection:
There seems to be some level of incomprehension as to the nature of SQL
injection based attacks.
It is possible to exploit SQL using injection methods without detailed
error messages. It is not however possible to attack the SQL server
without either detailed insider knowledge or a minimal reaction of the
server. Web based SQL injections rely on the response from the server.
There is a form of more complex SQL attack known as Blind SQL Injection.
This attack is not as is suggested totally blind. This is an attack
against a forms based web server and associated database which has the
SQL server error messages suppressed. The more standard SQL injection
attack is reliant on the SQL server error messages. These are used by
the attacker to craft packets targeted towards the specific SQL server.
To make an SQL injection work the attacker must first identify the
system being targeted. The attacker must first establish some sort of
indication regarding errors in the system or other indicators which will
enable the identification. In blind SQL injection, an analysis of the
responses is used in place of the (easier) method of analysing the
It is necessary that some information is returned to the attacker. The
process involved separating valid requests from invalid requests on the
server which enable the attacker to identify these responses.
Error responses include monitoring the HTTP 500: Internal Server Error
messages, 'Internal Server Error' messages (which are still linked to
valid 200 Ok responses) and any application handles errors generated by
the SQL server.
To exploit the SQL injection, it is necessary to have identified the
specific database in use. Normal SQL injection testing techniques, such
as adding SQL keywords (OR, AND, etc.), and META characters (such as; or
') rely on the knowledge of the system that the attacker has gained in
the afore mentioned stages.
Without the knowledge of the system, it is not possible to determine the
database, the entity names, relationships or any other database field.
This is important as the attacker has to craft the Select statement
along the lines of valid input fields. An example would be:
(1) SELECT * FROM EmployeeID WHERE DeptID = 'Accounts'
(2) SELECT * FROM EmployeeID WHERE DeptID = 'A' + 'ccounts'
Select ... Where ... and other statements used to enact the injection
will not work on non-existent data fields and entities. Knowing not only
the name of the entity and relations, but also the database instance is
crucial to the success of this attack.
It has been common to speculate in the industry about injection attacks
over input streams other than the web. There are valid reasons for this.
Direct access to TCP port 1433 (for MS SQL) allows the attack to
function without web access. All these attacks require an interactive
response form the SQL server.
In cases where the database is "accessed" non-interactively, such as a
phone IVR system (which uses speech to text technologies), Forms based
OCR input and other "feed and forget" systems, the attacker gains no
response and thus is supplied with no information in regards to the
Without this information, the attacker can not hope to "guess" the
database and entity names. Blank entries on a form do nothing to help
identify either a database instance used or the naming structure in
So the next time that somebody tries to tell you that your
"non-interactive" database is not safe, ask them how the attacker gets
information on the server. If the response is the web, well than the
server is interactive and the attack will also follow this format. If
the only access is (for instance) an OCR'd form with no user feedback,
than just nod politely.
It has been asked "But what if the command is to drop a database? In
that case there was never any intention of receiving data back, it's a
malicious vandalism of your database.". remember that the attacker needs
to know the details of the database. Although this is not a good
security measure (security by obsurity) and that correct controls on the
database are essential, the lack of this knowledge makes the attack
unlikely. I will not state impossible, as the chance is always there
(just as in there is a chance of randomly tapping away at a keyboard and
just happening to find the AES key associated with some of the internet
backbone routers). Risk is a probabilistic measure however, and events
which happen - nearly never - rarely should not be made a great concern.
Dr Craig S Wright DTh MNSA MMIT CISA CISM CISSP ISSMP ISSAP G7799 GCFA
Nam et ipsa scientia potestas es - Knowledge is power. (Sir Francis
Manager - Computer Assurance Services
BDO Chartered Accountants & Advisers
Level 19, 2 Market Street,
Sydney, NSW 2001
Telephone: +61 2 9286 5555
Fax: +61 2 9993 9705
Direct: +61 2 9286 5497
<Mailto:CWright () bdosyd com au>
Liability limited by a scheme approved under Professional Standards
Legislation in respect of matters arising within those States and
Territories of Australia where such legislation exists.
The information contained in this email and any attachments is
confidential. If you are not the intended recipient, you must not use or
disclose the information. If you have received this email in error, please
inform us promptly by reply email or by telephoning +61 2 9286 5555.
Please delete the email and destroy any printed copy.
Any views expressed in this message are those of the individual sender.
You may not rely on this message as advice unless it has been
electronically signed by a Partner of BDO or it is subsequently confirmed
by letter or fax signed by a Partner of BDO.
BDO accepts no liability for any damage caused by this email or its
attachments due to viruses, interference, interception, corruption or