[Webappsec] Automatically detecting injections

[Jim Manico]

 >  yes, but there is no *way* you can make such a claim after 
performing only that sort of check.

I thinkJeff is correct. It is impossible to perform a SQL Injection on a 
Java program of any kind if the programmer is using the 
PreparedStatement class AND binding all untrusted/user-driven variables 
to the query like so:

PreparedStatement ps = conn.prepareStatement("UPDATE Messages SET description = ?, author = ? WHERE id = ? AND seq_num = ?");
ps.setString(1,description);
ps.setString(2,author);
ps.setInt(3,id);
ps.setInt(4,seqNum);
ps.executeUpdate();

This is a rather easy pattern to code review for.

PraparedStatement alone will not secure your code from SQL Injection. 
It's the combonation of the PreparedStatement AND binding of data from 
untrusted sources. Queries created from String concatenation where 
variables come from untrusted sources are injectable.

If you can find a way to inject the code sample above, you would be the 
first to do so and should publish a paper.

- Jim


> On Mon, Apr 28, 2008 at 8:08 AM, Jeff Williams <jeff.williams at owasp.org> wrote:
>   
>>> Valid concerns. That said, I would imagine a decent fuzzer will always
>>>       
>>  > be faster than the best of source code auditors to identify whatever
>>  > types of bugs it is targetting. Obviously there are disadvantages and
>>
>>  You imagine wrong.
>>
>>  You can easily verify that an application with hundreds of thousands of
>>  lines of code doesn't have SQL injection in a matter of minutes. And you'd
>>  be accurate. You just check to make sure it only uses a parameterized
>>  database interface, like PreparedStatement.
>>     
>
> eh?
>
> no. that won't work. that will give you some information, yes, but
> there is no *way* you can make such a claim after performing only that
> sort of check.
>
>
>   
>>  As you start thinking up attack variants and encodings, you'll see a
>>  combinatoric explosion in the fuzzer. Scans that used to take a few minutes
>>  for a short list will start taking hours or days. And they're wildly
>>  inaccurate.
>>
>>  This is true of many classes of security holes, but not all of them. XSS is
>>  something that the tools have better luck with because it has to show up in
>>  the response and it's relatively simple. But they still have trouble with
>>  XSS that is stored in one place and retrieved in another, and complex XSS
>>  that requires special tricks or encoding.
>>
>>  I recommend you choose the most cost-effective approach (speed, accuracy,
>>  coverage) for verifying each security area. For SQL injection, it's hard to
>>  beat looking at the code. In fact, it's pretty hard to beat code review for
>>  most problems. You'll hear lots of tool vendors claiming that code review is
>>  so expensive. Keep in mind that it's possible they have an agenda.
>>
>>
>>  --Jeff
>>
>>  Jeff Williams, Chair
>>  The OWASP Foundation
>>  work: 410-707-1487
>>  main: 301-604-4882
>>
>>  OWASP AppSec NYC 2008 is coming...  are you ready?
>>     
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/webappsec/attachments/20080428/7048bca3/attachment-0001.html