[WEB SECURITY] Re: What do you like better Web penetration testing or static code analysis?

[cwysopal at veracode.com (Chris Wysopal)]

There is no reason the php.ini and other framework or app server configuration files can't be taken into account in a 
static analysis.  Veracode performs static analysis of an application in its final executable form.  So for compiled 
languages that is a binary executable, for managed languages it is the compiled bytecode and for interpreted languages 
it is the source code.  If there are standard configuration files that are part of the run time environment for 
frameworks or app servers they are be considered part of the final executable version of the app. If the configuration 
files are missing then a worst case analysis is performed.

Of course the php.ini submitted to the static analyzer might not match the one running in production but you can have 
the same issue doing dynamic testing on a staging environment. 

It can be a goal for both static and dynamic testing to have the analysis come as close as possible to what will be in 
production.  

-Chris


-----Original Message-----
From: SneakySimian [mailto:sneaky.simian at gmail.com] 
Sent: Wednesday, April 28, 2010 1:10 AM
To: Andre Gironda
Cc: websecurity; Secure Coding; Adam Muntner; Arian J. Evans
Subject: Re: [WEB SECURITY] Re: [SC-L] What do you like better Web penetration testing or static code analysis?

I couldn't let this one go.

Having done both source code analysis and blackbox testing, I see
merits in both. The failure that was the Debian SSL bug is a prime
example of why I prefer blackbox testing. That's not to say things
can't go wrong in blackbox testing, because they do, but not all code
behaves the same way in the same environment, so if you actually test
it in the environment it is running in, you can then understand why
the code behaves the way it does. Oversimplified example:

<?php
$file = $_GET['file'];

if(file_exists($file))
{
     echo $file;
}

else
{
    echo 'File not found. :(';
}

Ignoring the other blatant issues with that code snippet, is that
vulnerable to XSS? No? Are you sure? Yes? Can you prove it? As it
turns out, it depends on a configuration setting in php.ini. The only
real way to know if it is an issue is to run it in the environment it
is meant to be run in. Now, that's not to say that the developer who
wrote that code shouldn't be told to fix it in a source code analysis,
but the point is, some issues are wholly dependent on the environment
and may or may not get caught during code analysis. Other issues such
as code branches that don't execute or do execute in certain
environments can be problematic to spot during normal source code
analysis.

That all said, I do enjoy reading code, especially comment coding from
other developers. :P



On Tue, Apr 27, 2010 at 2:29 PM, Andre Gironda <andreg at gmail.com> wrote:
> On Tue, Apr 27, 2010 at 4:08 PM, Arian J. Evans
> <arian.evans at anachronic.com> wrote:
> > I think everyone would agree that you definitely want to apply
> > additional (deeper?) degrees of analysis and defensive
> > compensating-control to high-value and high-risk assets. The tough
> > question is what ruler you use to justify degree of security
> > investment to degree of potential Risk/Loss.
>
> That requires information sharing and trend analysis, something that
> our classic vulnerability management programs have also not solved
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA