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@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
_______________________________________________
