Analysis and Prevention of web stored vulnerabilities (file name detection vulnerabilities)

This article provides a detailed analysis of web memory vulnerabilities and its principles and prevention methods (file name detection vulnerabilities). For more information, see the previous article: <浅谈web上存漏洞及原理分析、防范方法（安全文件上存方法）> The backend obtains the server variables, many of which are passed by the client. It is no different from the common get and post methods. The following describes common vulnerability codes.
1. check the file type and save it with the user's stored file name
The code is as follows:
If (isset ($ _ FILES ['IMG '])
{
$ File = save_file ($ _ FILES ['IMG ']);
If ($ file = false) exit ('failed to store! ');

Echo "stored successfully! ", $ File;
}
Function check_file ($ img)
{
/// Read the object
If ($ img ['error']> 0) return false;

$ Tmpfile = $ img ['tmp _ name'];
$ Filename = $ img ['name'];


/// Read the file extension
$ Len = strrpos ($ filename ,".");
If ($ len = false) return false;

// Get the extension
$ Ext = strtolower (substr ($ filename, $ len + 1 ));
If (! In_array ($ ext, array ('jpg ', 'jpeg', 'PNG ') return false;
Return true;
}
Function save_file ($ img)
{
If (! Check_file ($ img) return false;

// Format check OK. prepare to move the data
$ Filename = $ img ['name'];
$ Newfile = "upload/". $ filename;
If (! Move_uploaded_file ($ img ["tmp_name"], $ newfile) return false;

Return $ newfile;
}
?>

The above code also makes a judgment on the input type, and there is no problem. However, the problem occurs precisely in the detection of the obtained username variables. Directly obtain the input user name and save it as a file. Some friends will say: These file names exist in my computer, and the file name formats are limited by the operating system's definition of the file name. However, you must note that for $ _ FILES, the variables are obtained directly from the http request. It is the same as getting other get and post variables. Therefore, people with ulterior motives often simulate their own browsers and send a special file name to the server. Then, you can save the file in your own format.

In the past few years, "\ 0" is saved as a file in the string and the subsequent content is automatically truncated. For example, if $ filename is constructed as "a. php \ 0.jpg", what will happen?
$ Newfile = "upload/a. php \ 0.jpg" because, for extension verification, the rightmost "." is followed by a jpg character, which allows the image format. However, we save it as the file name. The disk will generate all characters after a. php and \ 0 under the upload directory and will be automatically truncated.

This vulnerability is popular. At that time, almost all websites stored on the website had vulnerabilities. At the moment, many platforms have disabled storage. In fact, the root cause is this. We get the file name and save it as the final generated file name. A good way is to randomly generate a file name + read extension. In this way, special characters can be entered, which are discarded or truncated during file storage.

This vulnerability can be exploited in the php4 era. in the php5 era, "\ 0" is automatically filtered out of the generated variable file name values, regardless of the special "\ 0" username constructed by the user, will be truncated. However, such vulnerabilities are currently available on sites such as asp and jsp. It often appears. Older versions of php sites also frequently appear.
Now, let's first go here today. There are two other common methods available later! Welcome!