Security Considerations 141 Security has to be taken
Security Considerations 143 While he confirmed our assumption that the script should be placed in a trusted environment, it shows some techniques that would make it a dangerous security leak if na ve users placed it into a publicly accessible directory. For a start, invoke it with Directory_Viewer.php3?dir=/etc.Nice,isn t it? You can browse any directory on the system from which PHP is allowed. But that s not enough:You can execute any command using that little script and easily gain root access to the server hosting it. The key section is this line: exec( ls -la $dir , $lines, $rc); The variable $dir, provided the user, is passed directly to exec().As you may know, you can concatenate shell commands with ; so what do you think will happen when $dir is equal to /etc; cat /etc/passwd ? If you want to pass this as an argument, you d need to URL-encode the string, of course, so the script would be called like this: Directory_Viewer.php3??dir=/etc%3B+cat+%2Fetc%2Fpasswd And yes, it would display the contents of /etc/passwd. Instead of the cat command, you could execute any other command, for example fetch, to get and install a Trojan horse from your own server. The remedy for this specific problem is to pass the $dir variable through EscapeShellCmd(), thus masking all critical characters that could be used to trick the shell to execute concatenated commands.Also,it may be a good idea to restrict it to list only subdirectories: $secure_dir = str_replace( . , , $dir); $secure_dir = $DOCUMENT_ROOT.dirname($PHP_SELF). /$secure_dir ; $secure_dir = EscapeShellCmd($secure_dir); The principle remains: Never trust variables provided by users. Of course, this is valid for all scripting languages,not just PHP.The same hole is present in ASP using the FileSystem object, or in Perl when executing user-defined commands. Tainted Variables We must stress this:All data coming from the user space is to be treated as tainted, untrustworthy,contaminated,potentially evil.The Internet is outside the application space in this case; in trust management, this is called a trust boundary.The application space is a trusted environment; the Internet is not. Passing data from your program to the client doesn t need much special attention (given that it gets its data from trusted systems for example, the database system must be on an equal trust level with the application itself).The only instance in which you have to take special precautions is when you want to guarantee that data is received only by one specific client, or that the client can be sure to retrieve the data from a specific instance (your server).With a normal HTTP transfer,these guarantees can t be enforced;you re advised to use SSL or an equivalent encryption layer in such a case.
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services