[Webappsec] Automatically detecting injections

[Ray Foo]

Sorry for jumping/splitting the thread here.  I'm confused (or uneducated in
this aspect for now ;)  at Jim's statement below:

It's the combonation of the PreparedStatement AND binding of data from
untrusted sources.

What's the difference between a PreparedStatement with and without binding
of data?  Even if we just used ps.setString() for all the parameters, the
strings (malicious or not) would be SQL-encoded anyway, isn't it not?

Regards,
Ray

On Mon, Apr 28, 2008 at 6:34 PM, Jim Manico <jim at manico.net> wrote:

>  >  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> <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?
>
>
>
>
> _______________________________________________
> Webappsec mailing list
> Webappsec at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/webappsec
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/webappsec/attachments/20080429/35bcce39/attachment.html