PHP security - file system spanning

File system spans

No matter how you use the file, you have to specify the file name somewhere. In many cases, the file name will be used as an argument to the fopen() function, and other functions will call the handle it returns:

The vulnerability occurs when you include contaminated data as part of the file name:

Since in this case the path and the leading and trailing parts of the file name cannot be manipulated by the attacker, the attack possibilities are limited. However, keep in mind that some attacks use NULL (represented as %00 in the URL) to terminate the string, thus bypassing any file extension restrictions. In this case, the most dangerous attack method is to use multiple ../ to access the upper-level directory to achieve file system spanning. For example, imagine that the value of filename is specified as follows:

http://www.php.cn/ ... neither/path/to/file

As is the case with many attacks, using tainted data when constructing a string gives an attacker the opportunity to change the string, causing your application to behave in a way you do not intend. If you develop the habit of using only filtered data to create dynamic strings, you can prevent many types of vulnerabilities, including many that you are unfamiliar with.

Since the leading static part of the filename called by fopen() is /path/to, the above attack involves more upward directory crossings than necessary. Because the attacker cannot view the source code before launching the attack, a typical strategy is to repeat the ../ string too many times. Using the ../ string too many times will not destroy the above attack effect, so there is no need for the attacker to guess the depth of the directory.

In the above attack, the fopen() call is made to run in a way you don't want. It is simplified and equivalent to:

After becoming aware of the problem or experiencing an attack, many developers make the mistake of trying to correct potentially malicious data, sometimes without checking the data first. As mentioned in Chapter 1, the best approach is to think of filtering as a checking process and forcing users to follow the rules you set. For example, if legal file names contain only letters, the following code would enforce this restriction:

There is no need to escape the filename value because this data is only used in the PHP function and will not be transmitted to the remote system.

The basename() function is very useful when checking whether there are unnecessary paths:

This process is less secure than allowing only letters in file names, but you're unlikely to be that strict. A better prevention-in-depth process is to combine the above two methods, especially when you use regular expressions to check the legality of the code (instead of using the function ctype_alpha( )).

When the entire tail of the file name is composed of unfiltered data, a high-risk vulnerability occurs:

Giving attackers more flexibility means more vulnerabilities. In this example, an attacker can manipulate the filename parameter to point to any file in the file system, regardless of the path and file extension, because the file extension is part of $_GET['filename']. Once the WEB server has permission to read the file, processing will be directed to the file specified by the attacker.

If the leading part of the path uses contaminated data, this type of vulnerability will become even larger. This is also the subject of the next section.

The above is the content of PHP security-file system spanning. For more related content, please pay attention to the PHP Chinese website (www.php.cn)!