File system security in PHP

PHP is controlled by the security mechanisms of most server systems. these security mechanisms are generally based on file and directory licensing. This allows you to control which files in the file system can be read. PHP is controlled by the security mechanisms of most server systems. these security mechanisms are generally based on file and directory licensing. This allows you to control which files in the file system can be read. Pay special attention to all globally readable files. ensure that all users accessing the file system can read them securely.
Because PHP is designed to allow user-level access to the file system, you can write a PHP script to read/etc/passwd and change your Ethernet connection, it is entirely possible to send heavy printer tasks. There are some obvious associations here. you must ensure that you read and write the correct files.
In the following script, a user wants the script to delete a file in their home directory. This only assumes that a php web interface is usually used for file management. Therefore, Apache users are allowed to delete files in their home directories.
Example 15-1. a weak variable test will result in ......
Because user names can be sent from user forms, they can submit a user name and files belonging to others so that these files can be deleted. In this case, you need to use another form for authorization. Consider what will happen if the submitted variables are "../etc/" and "passwd? At this time, the code can be understood as: Example 15-2. a file system attack
There are two measures you must take to avoid these problems.

Only limited permissions are granted to php web users.
Test all submitted variables.
The following is an improved script: Example 15-3. more secure file name verification
$ Homedir = "/home/$ username ";
$ File_to_delete = basename ("$ userfile"); // strip pathsunlink ($ homedir/$ file_to_delete );
$ Fp = fopen ("/home/logging/filedelete. log "," + a "); // log the deletion $ logstring =" $ username $ homedir $ file_to_delete "; fputs ($ fp, $ logstring ); fclose ($ fp );
Echo "$ file_to_delete has been deleted! ";?> However, the script still has some problems. If your authorization system allows users to establish their own user logon, and a user selects "../etc/", the system will be exposed again. Based on this, you may be more willing to write a better test: Example 15-4. safer file name verification
If (! Ereg ('^ [^./] [^/] * $', $ userfile) die ('Bad filename'); // die, do not process
If (! Ereg ('^ [^. /] [^/] * $ ', $ username) die ('bad username'); // die, do not process/etc...?> Depending on your operating system, you need to consider a variety of files, including device projects (/dev/or COM1), setting files (/etc/files and. ini file), the common file storage area (/home/, My Documents), etc. Based on this, it may be easier to establish a policy to prohibit all actions except your explicit authorization.