From: Scovetta, Michael V (Michael.Scovetta@ca.com)
Date: Mon Jan 05 2004 - 14:51:39 EST
Sasa,
:steps onto soapbox:
You should also be wary of negative checking, and do positive checking
instead. Sanitization is difficult to get exactly right, and often
becomes an ugly regexp that's susceptible to code rot. Depending on the
environment, something like Java's PreparedStatement can be useful to
remove any chance of SQL Injection.
I've also written a validation filter (for Java) that sanitizes input
based on data from an XML input file on the server. I think Jakarta's
Commons:Validator project is a bit more robust. As far as other
languages go, I'm not sure what's available for which ones, but if you're
expecting the user to enter their age, better to:
try {
$x = int($x); //positive check, must be an integer
} catch(exception) {
// did not pass
}
rather than:
if ($x ~= /[^0-9]/) {
// did not pass // negative check, must not contain a non-integer
}
In my experience, datatype checking should ONLY be performed postively, and
if there's no datatype-checking required, then you're storing text/binary,
and you should be storing it in an appropriate manner. Doubling or escaping
quotes/etc isn't robust enough in my opinion, because you have to make sure
you're sure perfectly in sync with the database vendors unescaping procedures.
Michael Scovetta
-----Original Message-----
From: Jeff Williams @ Aspect [mailto:jeff.williams@aspectsecurity.com]
Sent: Monday, January 05, 2004 1:56 PM
To: pen-test@securityfocus.com
Subject: Re: SQL Injection question
Sasa,
The only way you're ever going to know is if you review the code. The 500
may be the result of a validation mechanism that detects malformed input and
generates the error. Or it may be the result of a database call that is
failing and throwing an exception that is handled by a generic error
handler.
You can waste a lot of time trying various injections and combinations to
get a more detailed error message, but you'll never know for sure unless you
check the code. For SQL injection in particular, it's far more efficient to
check to make sure that all SQL query parameters are validated or sanitized
properly in the code.
--Jeff
Jeff Williams
Aspect Security
http://www.aspectsecurity.com
----- Original Message -----
From: Sasa Jusic
To: 'pen-test@securityfocus.com'
Sent: Monday, January 05, 2004 7:53 AM
Subject: SQL Injection question
Hi group,
I am conducting a Pen test for a customer, and last few days I have been
struggling with their Web application running on Apache/mod_ssl Web Server
using CGI interface. During the initial assessment I found several Web forms
using POST method, so I began searching for SQL Injection Vulnerabilities.
The problem is that forms are well protected, and they are only accepting
numeric values, so I can't insert any malicious characters to test for SQL
vulnerabilities. Then I discovered that the form input validation is done
with JavaScript code on the client side, so I used the Paros proxy tool for
intercepting and modification of submitted form values. In this way I
managed to submit the arbitrary data to the server, and the server response
was "500 Internal Server Error" without any useful information about the
error reason or underlying database structure. I tried various combinations
typical for SQL Injection assessment, but the response was always the same.
On several places I have red that this type of error is one of the possible
indicators of SQL Injection problems, so I would like to examine this
problem more carefully.
How can I know if this is really a SQL Injection problem or some other
error? Is there any way I can elicit some more information about the
structure of the database or any other useful information I can use for
further testing?
I don't have much practical experience with SQL Injection so I would really
appreciate any help.
Best regards,
Sasa.
---------------------------------------------------------------------------
----------------------------------------------------------------------------
---------------------------------------------------------------------------
----------------------------------------------------------------------------
---------------------------------------------------------------------------
----------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:44 EDT