Nginx 中间件渗透总结

简介

Nginx（engine x）是一个高性能的 HTTP 和反向代理 web 服务器，同时也提供了 IMAP/POP3/SMTP 服务器 Nginx 是由伊戈尔开发，因为它的稳定性、丰富的功能集、实例配置文件和低系统资源的消耗而闻名。

Nginx 是一款轻量级的 Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，在 BSD-like 协议下发行，其特点是占用内存少，并发能力强，事实上 nginx 的并发能力确实在同类型的网页服务器中表现较好

中国大陆使用 nginx 的网站用户有：百度、京东、新浪、网易、腾讯、淘宝

Nginx 适用于高并发、可以做负载均衡服务器和 HTTP 服务器、具有代码特点、可以作为代理服务器

【一>所有资源获取<一】1、200 份很多已经买不到的绝版电子书 2、30G 安全大厂内部的视频资料 3、100 份 src 文档 4、常见安全面试题 5、ctf 大赛经典题目解析 6、全套工具包

Nginx 可以用作以下

1. 静态服务器

首先，Nginx 是一个 HTTP 服务器，可以将服务器上的静态文件（HTML、图片等）通过 HTTP 协议展现给客户端

Nginx 是一款轻量级的 Webserver/反向代理 server 以及电子邮件代理 server。并在一个 BSD-like 协议下发行，特点是占用内存小，并发能力强，Nginx 相较于 Apache/lighttpd 具有占用内存少，稳定性高等优势，并且依靠并发能力强，丰富的模块库以及友好灵活的配置而闻名

Nginx 本身也是一个静态资源的服务器当只有静态资源的时候，就可以使用 Nginx 来做服务器，同时现在也很流行动静分离，可以通过 Nginx 来实现动静分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来动静资源做好了拆分以后，我们可以根据静态资源的特点将其作为缓存操作，这就是网站静态化处理的核心思路

2. 反向代理服务器

客户端本来可以直接通过 HTTP 协议访问某网站应用服务器，网站管理员可以在中间加上一个 Nginx，客户端请求 Nginx，Nginx 请求应用服务器，然后将结果返回客户端，此时 Nginx 就是反向代理服务器

用户 A 向反向代理的命名空间（name-space）中的内容发送普通请求，接着反向代理将推断向何处（原始 server）转交请求，并将获得的内容返回给 client。而用户 A 始终认为他访问的是原始 server 而不是 nginx。因为防火墙作用，仅仅同意 nginx 进出，防火墙和反向代理的共同作用保护了院子内的资源---原始 server

如果服务器可以直接 HTTP 访问，为什么要在中间加一个反向代理，下面的负载均衡、虚拟主机等都基于反向代理实现，当然反向代理的功能也不仅仅是这些

3. 负载均衡

当网站访问量非常大，网站站长开心赚钱的同时，也摊上事了。因为网站越来越慢，一台服务器已经不够用了。于是将同一个应用部署在多台服务器上，将大量用户的请求分配给多台机器处理。同时带来的好处是，其中一台服务器万一挂了，只要还有其他服务器正常运行，就不会影响用户使用 Nginx 可以通过反向代理来实现负载均衡

负载均衡的意思就是分摊到多个操作单元上进行执行，例如 Web 服务器、FTP 服务器、企业关键应用服务器和其它关键任务服务器等等，从而共同完成工作任务，简单而言就是当有 2 台或以上服务器时，根据规则随机的将请求分发到指定的服务器上处理，负载均衡一般都需要同时配置反向代理，通过反向代理跳转到负载均衡，而 Nginx 目前支持自带 3 种负载均衡策略，还有 2 种常用的第三方策略

4. 虚拟主机

有的网站访问量大，需要负载均衡。然而不是所有的网站都如此出色，有的网站由于访问量太小，需要节省成本，将多个网站部署在同一台服务器上

例如将 www.aaa.com 和 www.bbb.com 两个网站部署在同一台服务器上，两个域名解析到同一个 IP 地址，但是用户通过两个域名却可以打开两个完全不同的网站，互不影响，就像访问两个服务器一样，所以叫两个虚拟主机

5. 正向代理

正向代理是一个位于用户 A 和原始 server 之间的代理 server ，为了从原始 server 取得内容，用户 A 向代理 server 发送一个请求并指定目标（原始 server）。然后代理 server 向原始 server 转交请求并将获得的内容返回给用户，用户必须进行一些特别的设置才能使用正向代理

用途：在防火墙内的局域网用户提供访问 Internet 的途径。还能够使用缓冲特性降低网络使用率

从安全角度讲：

正向代理同意用户通过它访问任意站点而且隐藏用户自身，因此你必须采取安全措施以确保仅为经过授权的用户提供服务。

正反向代理对外都是透明的。访问者并不知道自己访问的是一个代理。

6. Nginx vs Apache

Nginx 环境

Nginx 渗透

文件解析漏洞

漏洞简介：

​ 对于任意文件名，在后面添加 /xxx.php（xxx 为任意字符）后，即可将文件作为 php 解析

漏洞范围：

​ 该漏洞是 nginx 配置所导致，与版本无关。

漏洞复现：

1.jpg 后面加上 /xxx.php ，会将 1.jpg 以 PHP 解析

注意下图中的访问链接

该漏洞是 Nginx 配置所导致，与 Nginx 版本无关，下面是常见的漏洞配置：

server {   location ~ \.php$ {     root /work/www/test;     fastcgi_index index.php;     fastcgi_param SCRIPT_FILENAME   $document_root$fastcgi_script_name;     include fastcgi_params;   fastcgi_pass unix:/tmp/php-fpm.sock;   } }

当攻击者访问 /1.jpg/xxx.php 时，Nginx 将查看 URL，看到它以 .php 结尾，并将路径传递给 PHP fastcgi 处理程序.Nginx 传给 php 的路径为 C:/phpStrudy/WWW/1.jpg/xxx.php ，在 phpinf 中可以查看 _SERVER["ORIG_SCRIPT_FILENAME"] 得到

PHP 根据 URL 映射，在服务器上寻找 xxx.php 文件，但是 xxx.php 不存在，又由于 cgi.fix_pathinfo 默认是开启的，因此 PHP 会继续检查路径中存在的文件，并将多余的部分当作 PATH_INFO 。接着 PHP 在文件系统中找到.jpg 文件，而后以 PHP 的形式执行.jpg 的内容，并将 /xxx.php 存储在 PATH_INFO 后丢弃，因此我们在 phpinfo 中的 $_SERVER['PATH_INFO'] 看到的值为空（no value），如果继续添加后缀则蠢顺势显示后缀

最后整理一下思路：cgi.fix_pathinfo

php 的一个选项：cgi.fix_pathinfo，该选项默认开启，值为 1，用于修理路径的

例如：当 php 遇到文件路径 /yxc.jpg/xxx.php/yxc.sec 时，若 /yxc.jpg/xxx.php/yxc.sec 不存在，则会去掉最后的 /yxc.sec ，然后判断 /yxc.jpg/xxx.php 是否存在，若存在则将 /yxc.jpg/xxx.php 当作文件 /yxc.jpg/xxx.php/yxc.sec ，若 /yxc.jpg/xxx.php 仍不存在，则继续去掉 xxx.php ，以此类推

修复建议：

1. 配置 cgi.fix_pathinfo(php.ini 中)为 0，并重启 php-cgi 程序

2. 如果需要使用到 cgi.fix_pathinfo 这个特性（例如：wordpress），那么可以禁止上传目录的执行脚本权限或将上传存储的内容与网站分离，即站库分离

3. 高版本 PHP 提供了 security.limit_extensions 这个配置参数，设置 security.limit_extensions = .php

目录遍历

Nginx 的目录遍历与 Apache 一样，属于配置方面的问题，错误的配置可导致目录遍历与源码泄露

先去 www 目录下随便新建一个文件夹，然后进行访问

修改 C:\phpstudy\nginx\conf\nginx.conf，在下面标示位置中添加 autoindex on ;

重启 nginx，再次访问即可

修复建议：on 改为 off 即可

空字节任意代码执行漏洞

影响版本：

​ nginx 0.5.*

​ nginx 0.6.*

​ nginx 0.7 <- 0.7.65

​ nginx 0.8 <- 0.8.37

Nginx 在遇到 %00 空字节时与后端 FastCGI 处理不一致，导致可以在图片中嵌入 PHP 代码然后通过访问 xxx.jpg%00.php 来执行其中的代码

复现环境：

​ nginx 0.7.65+php 5.3.2

在 nginx-0.7.65/html/目录下创建 1.jpg，内容为：

<?php phpinfo();?>

访问 1.jpg，无法访问，所以在 URL 中输入 1.jpg..php

然后抓包，hex 选项下，.的 hex 编码为 2e，将第一个 2e 改为 00

成功绕过

该漏洞不受 cgi.fix_pathinfo 影响，当其为 0 时，依然解析

高版本不存在该漏洞

CRLF 注入漏洞

漏洞产生：

Nginx 会将 $uri 进行编码，导致传入 %0a%0d 即可引入换行符，造成 CRLF 注入漏洞。

错误的配置文件原本的目的是为了让 http 的请求跳转到 https 上的，意思就是配置实现了强制跳转的功能，当用户访问 nginx 服务器时，由于此配置的存在会被强制跳转到以 https 协议访问之前访问的链接

1. 配置中的 $url是我们可以控制的，这样我们就可以在$url 处填入 CRLF ，然后对服务器进行访问实现头部注入

2. 服务器会返回一个 302 跳转给用户

漏洞危害：

​ 劫持合法用户会话，利用管理员身份进行恶意操作，篡改页面内容、进一步渗透网站

​ 利用 CRLF injection 设置一个 SESSION ，造成一个 "会话固定漏洞"

原理：

​ CRLF 是“回车 + 换行”（\r\n）的简称。在 HTTP 协议中，HTTP Header 与 HTTP Body 是用两个 CRLF 分隔的，浏览器就是根据这两个 CRLF（使用 payload %0a%0d%0a%0d 进行测试）来取出 HTTP 内容并显示出来。所以，一旦我们能够控制 HTTP 消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话 Cookie（http://www.xx.com%0a%0d%0a%0dSet-cookie:JSPSESSID%3Dxxx）或者HTML代码（http://www.xx.com/?url=%0a%0d%0a%0d<img src=1 onerror=alert("xss")>），所以 CRLF Injection 又叫 HTTP Response Splitting，简称 HRS

Nginx 会将 $uri 进行解码，导致传入 %0a%0d 即科引入换行符，造成 CRLF 注入漏洞

$uri跳转HTTPS，$uri 就会产生 %0a%0d 换行符，换行符就一定存在 CRLF 注入漏洞

漏洞复现：

​ cd vulhub/nginx/insecure-configuration

​ docker-compose up -d

​ [http://127.0.0.1/%0ASet-cookie:JSPSESSID%3D36](http://127.0.0.1/ Set-cookie:JSPSESSID%3D36)

CRLF + XSS 配合：

%0D%0A%0D%0A%3Cimg%20src=1%20onerror=alert(/xss/)%3E

使用旧版浏览器即可弹窗

CRLF 深入：

攻击者操作：

1. 攻击者打开一个网站，然后服务器会回复他一个 session id。比如 SID=abcdefg。Attack 把这个 id 记下了

2. Attack 给被攻击者发送一个电子邮件，他假装抽奖或者推销，诱导攻击者点击链接：http://unsafe/?SID=abcdefg，SID 后面是 Attack 自己的 session id

3. 被攻击者被吸引后，点击了 http://unsafe/?SID=abcdefg，像往常一样，输入了自己的账号和口令从而登录到银行网站

4. 因为服务器的 session id 不改变，现在被攻击者点击后，他就拥有了被攻击者的身份，就可以为所欲为了

文件名逻辑漏洞（CVE-2013-4547）

影响版本：

​ nginx 0.8.41 - 1.4.3 / 1.5.0 - 1.5.7

​ 复现时需要文件名的后面存在空格，而 windows 是不允许存在此类文件的，因此复现采用 vulhub

漏洞复现：

cd vulhub/nginx/CVE-2013-4547

docker-compose build

docker-compose up -d

docker ps

上传 1.jpg

内容为：

<?php phpinfo();?>

抓包在后缀名后面加个空格，成功绕过

修改名称为 2.jpg…php ，在 hex 编码下将 jpg 后面的两个 2e 改为 20，00，

成功绕过

原理：

修复建议：

​ 升级版本

整数溢出 CVE-2017-7529

漏洞描述：

​ 在 nginx 的 range filter 中存在整数溢出漏洞，可以通过带有特殊构造的 range 的 HTTP 头的恶意请求引发这个整数溢出漏洞，并导致信息泄露。

影响版本：

​ Nginx 0.5.6 - 1.13.2

危害程度：

​ 低