nginx是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务，有 开源，内存占用少，并发能力强，*模块化，支持epoll模型，可限制连接数，支持热部署，简单灵活等等优点。。。。。。
能提供web服务、负载均衡反向代理、web cache服务
nginx也是个跨平台服务器
一个简单新手介绍安装 作者taiyonghai https://www.cnblogs.com/taiyonghai/p/9402734.html
先说点题外话：关于反向代理（也是常常说到的一个小知识点），都用nginx做反向代理，那么啥是反向代理
三句话+一张图说明，绝不啰嗦
第一句话：正向代理，代理的是客户端，为了向服务端隐藏客户端信息；反向代理，代理的是服务端，为了向客户端隐藏服务端信息
第二句话：正向代理，处理请求的服务端是明确的，但对于服务端来说，客户端具体由哪台客户机发起请求是不明确的；反向代理，发起请求的客户端是明确的，但对于客户端来说，服务端具体由哪台服务器处理请求是不明确的
第三句话：正向代理，代理服务器与客户端可视为一个部分，对服务端透明；反向代理，代理服务器与服务端可视为一个部分，对客户端透明
一张图：
言归正传
先声明一个概念FastCGI
FastCGI是一种可伸缩的、高速的在HTTP server和独立进程之间通信的协议。FastCGI被众多脚本语言支持，包括PHP。FastCGI是从CGI发展而来的。FastCGI接口方式采用C/S结构，可以将HTTP服务器和脚本解析服务器分离开，
同时在脚本解析服务器上启动一个或多个脚本解析守护进程。Nginx并不支持对外部程序的直接调用或解析，所有外部程序都要通过FastCGI接口来调用。FastCGI接口在脚本解析服务器上启动一个或多个守护进程动态解析脚本，这也成
为FastCGI进程管理器，spawn-fcgi与PHP-FPM就是两个进程管理器
借用知乎用户Code Diy 的比喻（https://www.zhihu.com/question/30672017）
把服务器看作餐厅，用户请求看作来用餐的顾客，服务器处理请求看作解决顾客的就餐问题（响应输出一份饭）。
服务器上静态资源看作已做好的饭，只要放到餐盒里就可以返回给顾客，动态资源需要厨房大厨现成做份再放到餐盒里返回给顾客。
php_mod这个大厨有个特点，看见有顾客进门就点火，不管顾客要不要现做的，有点浪费资源
php_fpm这个大厨有好多小弟一直点着火（多个处理进程），等有顾客说要现做，大厨就安排小弟做份返回给客户
cgi也是个大厨，不过他等到顾客要现做，他才点火，做饭，然后熄火。等待下一个要现做的到来
fastcgi呢就是个大厨雇了一帮小弟，专门做需要现场做的饭，大厨只管分派任务，小弟真正操锅做饭
1.nginx解析漏洞
任意文件名后加 /xxxxx.php(xxxxx处可添任意字符)，可将文件作为PHP解析
常见利用方法就是你搞个图片马a.jpg，上传，（知道绝对路径）浏览器访问图片马后面加个/lcx.php，变成 https://xxxxxxx.xxxxx/xxxxxx/a.jpg/lcx.php这种格式，然后菜刀连，OK（玩烂了没啥新意不截图了）
假装有图.jpg
此漏洞是与nginx配置相关的，不是nginx版本的问题，或者更确切地说是nginx 中PHP配置不当才有此漏洞
与Apache不同，当Apache看到a.jpg/lcx.php这种文件会先判断lcx.php文件是否存在，而nginx看到.php会直接把文件交给PHP处理（此漏洞产生的最初原因，梦开始的地方），PHP就找这个lcx.php文件，那肯定是找不到的，因为文件名是我瞎写的
这又涉及到另一个东西cgi.fix_pathinfo=1（漏洞产生的第二个原因）
上图为PHP配置文件php.ini中的截图
从名字就可以看出来，这个值是一种对于文件路径的fix（修复），1表示开启
开启后，PHP看到不认识的路径就删，删到认识为止，a.jpg/lcx.php找不到不认识，删，a.jpg找得到认识，停。把a.jpg当成要执行的文件（什么，不执行？不执行传给我干嘛），仔细看了看a.jpg的脸，产生两个选项：
A.我认得你，你就是php文件，即使你叫jpg，你的心还是php的
B.我不认你，你就是jpg文件，不是php文件，不执行，access denied！
要是B选项，那就利用失败了，必须产生A选项才行。要想产生A选项，php-fpm.conf中有security.limit_extensions（漏洞产生的第三个原因）来限制文件解析类型，啥也不写的话，默认就是按照PHP执行，就会出现A选项中的情况
不过一般都是写成
security.limit_extensions=.php的，意思就是你只有是.php我才承认你是一个php文件，我按照PHP来执行。你明明写做.jpg，不是.php，你说你是php，对不起我不同意
所以，要想这个洞能在实战中复现成功还是挺难的（苦笑），然而一旦有就是可以批量日穿一堆的（废话）
防御的话，从第三点来说，用高版本PHP就是security.limit_extensions=.php了，就不会出现上述问题
从第二点来说，要么cgi.fix_pathinfo=0 ，要么cgi.fix_pathinfo=1但禁止上传目录脚本执行权限
2.nginx空字节任意代码执行漏洞
nginx版本0.5.*, 0.6.*, 0.7 <= 0.7.65, 0.8 <= 0.8.37受到影响
原理是啥？在使用PHP的FastCGI执行php的时候，URL里面在遇到%00空字节时与FastCGI处理不一致，导致可在非php文件中嵌入php代码，通过访问文件来执行其中的php代码
举例来说：
我上传一个图片，a.jpg，里面写<?php phpinfo();?> 上传，之后访问绝对路径下的a.jpg，burp抓包，改成a.jpg..php，将Hex第一个.的编码改成00，传过去，返回了执行结果phpinfo（cgi.fix_pathinfo=0也拦不住，XX说的）
防御，不要用这几个版本
3.CVE-2013-4547(nginx文件名逻辑漏洞)
nginx版本 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7受到影响
这个东西，实际上是一种错误的URL解析
正常来说nginx发现 .php文件 ，扔给PHP fastcgi解析，在nginx.conf中
啊，通常是有各种配置的，我这里没有配置
nginx.conf中常见配置类似
location ~ \.php$ {
include fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/html$fastcgi_script_name;
}
这种
如果我们请求a.jpg[0x20][0x00].php这种（hex下的 空格 和 \0），也匹配到了正则.php$，进入这个location块，但fastcgi查询的时候被\0所截断，于是nginx认为文件名是a.jpg[0x20]（是a.jpg空格），把他经fastcgi发出去了
于是我们可以做到让 a.jpg空格 这种格式的文件被当做PHP解析
于是乎，还是第2点的例子，传图片a.jpg，里面写<?php phpinfo();?>，上传，访问绝对路径下的a.jpg，burp抓包，文件名改成a.jpg...php，把前两个.的hex码由2e 2e改成20 00，发包，返回了执行结果phpinfo
其实。。。在现在，基本都有各种重命名，各种路径找不到，2、3两个点如果有遇到那还真是幸运啊（苦笑）
防御不用这些版本或者改代码
4.nginx错误配置漏洞
（1）CRLF注入
如果在nginx.conf里面location中有这样一行
那就要注意了
这是一个强制跳转的功能，让http请求跳转到https上
nginx会将$uri解码，如果传入%0a%0d，就是进入换行符，造成一个CRLF注入
然后就是老套路了
访问什么http://xxxx.com/%0a%0d%3Cimg%20src=1%20onerror=alert(/xss/)%3E 随便插点什么setCookie也成
一般会在回包的Location下面出现插入的东西
毕竟代码里常常这么写 header("Location: ". $_GET["url"]);
防御 换成 return 302 https://$host$request_uri; 试试，直接把完整的URL扒下来，不再解码，也就没事了
（2）目录穿越漏洞
nginx配置别名Alias时，忘记加/，会造成此漏洞
我这没有别名，没截图
location /files {
autoindex on;
alias c:/xxxxxxx/xxxxxx/home/;
}
类似这种（这个例子是把/files 等同于/home），访问/files../也是访问/home../
防御的话改成这种
location /files/ {
autoindex on;
alias c:/xxxxxxx/xxxxxx/home/;
}
或者这种
location /files {
autoindex on;
alias c:/xxxxxxx/xxxxxx/home;
}
（3）目录遍历漏洞
这样的，autoindex为on
访问主页就好，就能看到很多有的没的，该看的不该看到的东西
防御 将autoindex改成off
随便转载，请标明作者出处