Penetration Testing mailing list archives
RE: SQL Injection question
From: "Scovetta, Michael V" <Michael.Scovetta () ca com>
Date: Mon, 5 Jan 2004 14:51:39 -0500
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. --------------------------------------------------------------------------- ---------------------------------------------------------------------------- --------------------------------------------------------------------------- ---------------------------------------------------------------------------- --------------------------------------------------------------------------- ----------------------------------------------------------------------------
Current thread:
- Re: SQL Injection question, (continued)
- Re: SQL Injection question Jeff Williams @ Aspect (Jan 05)
- RE: SQL Injection question Yvan Boily (Jan 05)
- Re: SQL Injection question Adam Tuliper (Jan 05)
- Reverse Engineering thoughts n30 (Jan 07)
- Re: Reverse Engineering thoughts Riad S. Wahby (Jan 07)
- Re: Reverse Engineering thoughts johnny cyberpunk (Jan 07)
- RE: Reverse Engineering thoughts Brett Moore (Jan 07)
- Re: Reverse Engineering thoughts Adam Tuliper (Jan 07)
- RE: SQL Injection question Yvan Boily (Jan 05)
- Re: SQL Injection question Jeff Williams @ Aspect (Jan 05)
- RE: SQL Injection question Tibor Biro (Jan 05)
- RE: SQL Injection question Lachniet, Mark (Jan 05)
- RE: SQL Injection question Scovetta, Michael V (Jan 05)
- SQL injection question John (Jan 21)
- Re: SQL injection question .Saphyr (Jan 22)