In this article:
- IIS6.0 parsing vulnerability
- CGI parsing vulnerability
note:
Chopper link 200, the file exists, but the chopper link is not up, the reason may be that the language type of the Trojan horse does not match.
Picture horses: sqp horses for asp and php horses for php. They cannot be passed between them. During the test, a horse cannot be connected.
1. IIS6.0 parsing vulnerability:
IIS6.0 parsing vulnerabilities, there are actually some features that are not as good as IIS6.0. Strictly speaking, only some default configurations are not vulnerabilities, but there are also some vulnerabilities.
IIS6.0 parsing vulnerability (1) [Not a vulnerability, but a problem with the default configuration, suitable for bypassing the blacklist mechanism].
IIS6.0 not only treats the ASP suffix as ASP, but also uses the file suffix names .asa, .cer, .cdx as asp to parse. This is because IIS6.0 sets .asa by default in the application extension. .cer .cdx will call asp.dll.
Solution: Delete the corresponding configuration directly.
IIS6.0 parsing vulnerability (2) [IIS5.1 and IIS7.5 have no such vulnerability]:
IIS6. When dealing with file paths that contain special matches, there will be a rough couple, resulting in a file parsing vulnerability:
text.asp; jpg It will be interpreted as asp.
";" Is used in many places to end.
However, the name of this file is still: a.asp; jpg.
IIS6.0 parsing vulnerability (3) [IIS5.1 and IIS7.5 have no such vulnerability]:
IIS6. When dealing with file paths that contain special conformances, there will be a rough couple, resulting in a file parsing vulnerability:
text.asp / 123.jpg It will be parsed as asp.
Request a.asp / x.jpg
This is equivalent to building a new file a.asp, all files in this folder will be executed with asp.
2. CGI parsing vulnerability:
What is CGI?
Simply put, it can be understood as the steward between the Web server and the independent program.
The server hands over the type a file to CGI, and the CGI hands over to the program that processes the type a file.
Nginx supports PHP parsing by CGI by default. The common practice is to set SCRIPT_FILENAME through regular matching in the Nginx configuration file.
When accessing the url www.xx.com/phpinfo.jpg/1.php, $ fastcgi_script_name will be set to "phpinfo.jpg / 1.php" and then constructed as SCRIPT_FILENAME (absolute path) and passed to PHP CGI, if enabled cgi.fix_pathinfo = 1 option.
As soon as CGI looks at the end of the php suffix, it will execute the php program. PHP will find the folder named "phpinfo.jpg". If it is not found, it will find the file "phpinfo.jpg" and execute it.
This default is 1, so if it is not set, it is turned on, then the following logic in PHP will be triggered:
php will think that SCRIPT_FILENAME (absolute path) is phpinfo.jpg, and 1.php is path_info, so phpinfo.jpg will be parsed as a php file,
The nature of the vulnerability:
There is no link for retesting.
This is a logical issue, so we can successfully bypass the parsing by adding /.php after the normal .jpg.
This is not a unique vulnerability of Nginx. Such parsing vulnerabilities often occur in Web containers such as IIS7.0, IIS7.5, and Lighttpd.
You can determine what web container it is through platforms such as Yunxi Assets and Weibu Community.
The user sends a request-Web container-php-CGI-to the PHP code to execute-return to the Web container-and then to the user.