File parsing vulnerability summary -Nginx

Nginx Parsing Vulnerability

Principle: add back any file name as the file will /*.php,nginx as a php file type, to execute php to resolve
cases: xx.jpg, which is the source; <php phpinfo ()?? >
Access xx when .jpg, behind xx.jpg add /xx.php, you can achieve nginx parsing vulnerability, the xx.jpg resolve to execute php

We will above an experiment: I am using here is the integrated environment phpstudy
Here Insert Picture Description
browser to access:
Here Insert Picture Description
Here Insert Picture Description
return to the Access denied, which is why?
Let's take a carding process again, Nginx see xx.jpg, according to mime.types, know that it is the type of picture, on to the picture to deal with; Nginx see xx.jpg / xx.php, see .php, know it is the type of php, php go on to deal with, php see xx.jpg / xx.php suffix is .php, on the implementation of xx.jpg / xx.php this document, there is no discovery xx.php execution, delete / xx.php, continue to look forward, found xx.jpg, but not php php type .jpg found he knew, not to execute php, it returns the Access denied.

Why can encounter php delete it, this was because the php.ini configuration: cgi.fix_pathinfo = 1, usually the default is 1, when he was 1, it means that open the php file path repairs, assuming see when php when the aa.xxx/aa.yyy/aa.zzz this file, php file not found aa.xxx/aa.yyy/aa.zzz this (remember, aa.xxx / aa.yyy / aa.zzz is full! ), delete the back /aa.zzz, detects whether aa.xxx/aa.yyy this file exists, if there is, and php recognize it, resolve to execute php (return not know Access denied.), if not, delete /aa.yyy, detection aa, xxx file exists, and so on
Note: All articles experiments, all enabled by default php repair function (cgi.fix_pathinfo = 1)

When testing above xx.jpg / xx.php, cgi.fix_pathinfo is on, why I still can not resolve it, as stated above, php do not know this type .jpg, you need to configure http-fpm.conf in security.limit_extensions empty (the need to restart after configuration nginx)
Example: security.limit_extensions default configuration for ;security.limit_extensions = .php .php3 .php4 .php5
Here Insert Picture Description
this What does it mean? This representation allows security.limit_extensions resolve other file types as php, my understanding is that the provisions of type php suffix know what (limit it), which is why php do not know .jpg, you know, whenever know php suffix type , php format to be analyzed and executed , beginning security.limit_extensions only recognize .php .php3 .php4 .php5, now replaced by blank, php suffix recognize any type, that there are questions, some people say I set security.limit_extensions = empty, I can directly access xx.jpg, xx.jpg not been resolved php execution, Why? In fact, security.limit_extensions = empty indeed represent any file extension parsed as php execution, but you know, first of all is to go through the file Nginx judge, like this xx.jpg, Nginx know him, directly judge him as a picture, you to picture processing, and execute php after it has been repaired wheel, so in order to perform repair xx.jpg to php, first Nginx over that hurdle, such as the use xx.jpg / xx.php or xx.jpg / xx .php / xx.xxoo (from right to left to determine whether Nginx know), use .php deceive Nginx, tell him, this is my php file, php to go.
You can look IIS7.x parsing vulnerabilities have the same purpose file parsing vulnerability summary -IIS
If you want xx.jpg can parse php, you can configure nginx.conf, like the apache configuration httpd.conf in AddType (of course this is my guess, may have no, nginx may only be in the url, in Add /xx.php xx.jpg back to the xx.jpg to resolve php execution, after all, everyone is different middleware Well)

So sum up, Nginx exploit the conditions are:
the suffix (1) Nginx of the http-fpm.conf security.limit_extensions = empty or other designated php to parse executed
(2) php open file repair: php.ini in cgi.fix_pathinfo = 1

Then we can reproduce the vulnerability were talking about the process
xx.jpg Source:
Here Insert Picture Description
use a: xx.jpg / xx.php, Nginx from right to left to find understanding suffix, see .php, will xx.jpg /xx.php to execute php to repair and found xx.jpg / xx.php does not exist, delete /xx.php, continue to repair when php repair, found xx.jpg exist, it will xx.jpg resolve to execute php
Here Insert Picture Description
use two: xx.jpg / xx.php / xx.xxoo, Nginx from right to left to find understanding suffix, see .xxoo, do not know, see .php know, the xx.jpg / xx.php / xx.xxoo to execute php to repair and found xx.jpg / xx.php / xx.xxoo does not exist, delete /xx.xxoo, continue to repair and found xx.jpg / xx.php does not exist, delete / xx when php repair. php, repair continues, found xx.jpg present, will resolve php xx.jpg to perform
Here Insert Picture Description
defensive approach:
(. 1) provided in the php.ini = 0 cgi.fix_pathinfo
(2) is provided php-fpm.conf security.limit_extensions = .php, allowing only php .php suffix to resolve execution

Note: I wrote laboratory linux, windows is another matter, and not all the same, for example, there are no windows php-fpm.conf profile, you can directly use nginx parsing vulnerability, the picture will be displayed when accessing source code will not return pictures and more.
The article I was using phpstudy take an integrated environment, some file path and directly inconsistent with agnix online environment or docker said path.
Some things have to use the original, this directory traversal ready to write, configuration parameters or environment can not reproduce, there may be home - I do not use phpstudy

Published 148 original articles · won praise 61 · views 60000 +

Guess you like

Origin blog.csdn.net/qq_41617034/article/details/105091033