At present, the parsing vulnerability exists mainly in three Web service programs, IIS, Nginx and Apache, respectively.
IIS6.0 under the main is that there are two parsing vulnerabilities, one is the directory parsing, such as/xx.asp/xx.jpg, the other is the file parsing, shaped like xx.asp; JPG, this vulnerability can be uploaded to the shell, the server is a great hazard.
The famous Nginx malformation parsing vulnerability. The lab has been experimenting with this loophole and will not repeat it.
Apache parsing vulnerability. This experiment is also a test of the vulnerability. Environment is Php+apache
Apache is from right to left to judge the resolution, if it is not recognized parsing, then left to judge. For example, Xxx.php.rar to Apache, RAR is not resolvable, so it will be parsed into xxx.php.
Prove Apache parsing vulnerability by simply uploading pages
Log in to the client, open the address in the browser http://10.1.1.31/upload/, which is the root directory of the upload directory, is also the file directory to be uploaded, is now empty
And then open http://10.1.1.31/upload.html, this is the upload page
Start testing now. Create a new Test.php.rar content in the client <?php phpinfo ();? > Then upload
See if the upload was successful. Visit for a try
Apache does not know the RAR suffix name, it will be regarded as test.php. Parse succeeded. In fact, the key to the entire loophole is the "legal suffix" of Apache is what, not the "legal suffix" can be exploited.
Defense by modifying the Apache configuration file
From the above, the http://10.1.1.31/upload/has successfully uploaded the Test.php.rar, and can be incorrectly parsed into PHP.
Now make the appropriate modifications to the Apache configuration file and add the following lines of code to the file
<filesmatch ". (php.| php3.| php4.| PHP5.) " >
Order Deny,allow
Deny from all
</FilesMatch>
Prohibit access to *.php.* files
Save and restart Apache. Now, test it again.
I can't see it in the catalogue.
Apache Parsing Vulnerability