i’m doing a simple thingy in php and i wonder how i can test if the variable $path contains the following structure ../
so i’ll simply have a ?path=somepath structure in my url, and if anybody would enter ../ it allows him to go one directory up. I know of course that that’s not the best solution, however for my little thingy it’s enough if i just test the $path variable for a string of “../” in it. if so die();
i’m not sure what’s the best way to test that!
regards matt
to answer your question:
if(strpos($path,'../') !== false){
// looks like someone 's trying to hack here - simply
// do nothing (or send an email-notification to yourself
// to be informed and see how often this happens)
}else{
// here comes the magic
}
but: you really shouldn’t do so. if you want an easy solution, use a switch-statement for every possible $path and include the relevant file (or whatever you have to do).
Answer：
Instead of doing that, you could just call realpath() on it and check if the path it’s supposed to be in is a prefix of that.
Even better, why not keep a whitelist and reject anything not in it?
Answer：
I’s an alternative solution that allow you to customize the url….
<?php
$arr= array(
"register" => "register.php",
"login" => "userlogin.php",
"admin" => "adminlogin.php",
"etc" => "otherpage.php",
);
if ( isset ( $_GET['path'] )
if ( array_key_exists( $_GET['path'] , $arr) ){
//do some stuff...
include( $arr[$_GET['path']] );
}
else
echo 'Page Not Found!';
else
echo 'Required Field Empty!';
?>
So calling index.php?path=admin page adminlogin.php will be included….
Answer：
one of the easier ways is to harden your php.ini config, specifically the open_basedir directive. Keep in mind, some CMS systems do actually use ..\ quite a bit in the code, and when there are includes outside the root folder this can create problems. (i.e. pear modules)
Another method is to use mod_rewrite.
Unless you are using an include file to check each and every URL for injection from $_GET and $_SERVER['request_uri'] variables, you will open doors for this kind of attack. for example, you might protect index.php but not submit.php. This is why hardening php.ini and .htaccess is the preferred method.
Tags: phpphp
