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