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

[Greg.Beeley at LightSys.org (Greg Beeley)]

Regarding the code snippet -- it does depend on the environment -- point well
taken.  But in this case (from what I can tell), unless you actually have the
file_exists() function *disabled* in php.ini, this is vulnerable to XSS.

- Greg

Sebastian Schinzel wrote, On 04/28/2010 04:03 AM:
> On Apr 28, 2010, at 7:10 AM, SneakySimian wrote:
> > <?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.
>
> So you suggest to actually perform n black-box tests where n is the set
> of all possible permutations of all variables in php.ini (hint: n will
> be very
> large)? This is certainly not feasible.
>
> Your code shows a very simple data flow, which may or may not be
> exploitable. But this is not the point. The point of software security
> is to
> increase the reliability of the software when under attack.
>
> Reliable software performs output encoding when user input is printed
> to HTML. This code does not perform output encoding and should therefore
> be fixed.
>
> The discussion about whether or not this is exploitable on which platforms
> is a waste of time. In many cases, you will find yourself spending a lot of
> time in trying to get a running exploit, whereas the actual fix for the
> code
> takes a fraction of the time.
>
> For me, penetration testing is solely a method to raise awareness and to
> gather new
> security requirements FOR a customer application FROM security researchers.
> Knowledge transfer from security researchers to the business is key here.
> It helps finding actual attacks but does not help the customer writing
> better
> code.
>
> Code audits (where automated or manual) are the way to go to improve
> reliability by pointing out dangerous coding patterns.
>
> My 0.02?...
>
> Cheers
> Sebastian
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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
> _______________________________________________