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 _______________________________________________