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.sim...@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 <and...@gmail.com> wrote: > On Tue, Apr 27, 2010 at 4:08 PM, Arian J. Evans > <arian.ev...@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 _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates _______________________________________________
