[Owasp-delhi] SQL Injection
dhruv.soi at torridsecurity.com
Wed Mar 7 03:27:12 EST 2007
Interesting mail from Craig..thought to share..
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 errors.
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
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 server.
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 play.
So the next time that somebody tries to tell you that your "non-interactive"
database is not safe from remote exploit, 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-delhi