Apache suffix name parsing vulnerability analysis and defense methods

We all know that if there is a directory like xxx.asp in the directory structure, all files in that directory, regardless of the extension, will be parsed as asp. We generally call this vulnerability windows2003+ iis6.0 directory resolution vulnerability. What you may not know is that the apache server has a similar parsing vulnerability.

Let's do the experiment. I have built a local apache+php test platform:

phpinfo.php phpinfo.php.a, let's go to phpinfo.php.a:

http://192.168.99.110/phpinfo.php.a

You can parse it. You can still do it with other suffixes.

No matter what the end of the file suffix is, as long as it is at the end of the.php.*, it will be parsed into the php file by the Apache server. The problem is that if the last x3 extension is not defined in the mime.types file, in the case of x1.x2.x3, it will be parsed into the second to last x2 extension. So xxx.php.rar or xxx.php.111 which are not defined in mime.types by default will be resolved to php. Also, if it is cgi or jsp, it will be the same...

So if it comes to the upload page of web program, if the file name of the upload is what we can define, then we can upload one webshell with the name xxx.php.jpg, apache will still be resolved as php, so let's test jpg again.

Defense: apache configuration file.php is not allowed.

<Files ~ "\.(php.php3.)">

Order Allow,Deny

Deny from all

</Files>

Save it, since apache, let's look at it again.

OK, that's the defense.