[Webappsec] Automatically detecting injections

[silky]

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?

-- 
http://lets.coozi.com.au/