安全中级2:nginx的中间件漏洞

这篇具有很好参考价值的文章主要介绍了安全中级2:nginx的中间件漏洞。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

一、nginx解析php的流程

1.原理   

2.CGI、FastCGI、PHP-FPM、PHP-CG、WrapperI的定义

二、Fastcgi协议

1.Fastecgi Record

2.Fastcgi Type

3.PHP-FPM(FastCGI进程管理器)

4.总结FastCGI解析的流程

三、nginx配置错误导致的漏洞

1.CRLF注入漏洞($uri解码漏洞,换行符导致的注入漏洞)

(1)原理

(2)利用CRLF修改头部信息

(3)CRLF+Bottle HTTP造成的反射性xss漏洞

(4)防御

2.目录穿越漏洞

(1)原理

(2)漏洞复现

(3)防御

3.Http add_header被覆盖的问题

(1)原理

(2)CSP(Content-Security-Policy)

(3)漏洞的复现

(4)防御

四、nginx文件名逻辑漏洞(Nginx 0.8.41 ~ 1.4.3 /1.5.0 ~ 1.5.7 )

1.原理

2.文件名逻辑漏洞的复现

(1)首先创建一个文本,里面输入php代码

(2)修改文件后缀名为1.gif

(3)打开浏览器输入

(4)选择我们1.gif文件

(5)打开抓包工具,之后上传文件抓包

(6)找到文件名给他加成1.gifaa.php

(7)进入到hex也就是编码数字的部分,修改文件名,将aa改成20和00,主要是让他生成 \0(也就是一个空格和阶段符号)。

(8)将修改的数据包放行提交到端

(9)查看我们上传图片的目录

 (10)打开抓包工具抓取该网页,出现以下问题,是因为我们禁止了抓包工具抓取图片,我们点击开启就可以了。

 (11)抓包

 (13)修改我们的文件名为1.gifaa.php

 (14)进入到hex下,修改我们的aa编码为20和00,就是空格和截断符,这里主要是为了和我们上传的文件名一样

 (15)将我们修改过的数据包发送就会看到我们注意的php页面

 3.防御

五、nginx的解析漏洞

1.原理

2.nginx解析漏洞复现

(1)先看我们php-fpm配置文件,发现我们的后缀名安全策略为空的

(2)访问http://192.168.191.129/uplocalfiles/nginx.png

(3)在上面路径后面随意添加一个以.php结尾的文件

 (4)触发我们的php恶意代码

(5)还有一种方法和上面nginx逻辑名漏洞一样上传php恶意文件,修改名称,第二次直接访问就会触发


一、nginx解析php的流程

安全中级2:nginx的中间件漏洞

1.原理   

        首先浏览器对nginx进行传输数据,nginx接收到浏览器传过来的数据之后,通过fastcgi协议将数据格式化成fastcgi规定的形式,格式完之后通过php-fpm进程管理工具,格式成n多个的phpcgi,从而处理成fastcgi规范的数据,处理完的数据交给我们的php,然后PHP将数据传递给我们的nginx。

2.CGI、FastCGI、PHP-FPM、PHP-CG、WrapperI的定义

  • CGI:CGI是一种协议,它定义了Nginx或者其他Web Server传递过来的数据格式,全称是(Common Gateway Interface,CGI),CGI是一个独立的程序,独立与WebServer之外,任何语言都可以写CGI程序,例如C、Perl、Python等。

  • FastCGI:FastCGI是一种协议,它的前身是CGI,可以简单的理解为是优化版的CGI,拥有更够的稳定性和性能。

  • PHP-CGI:只是一个PHP的解释器,本身只能解析请求,返回结果,不会做进程管理。

  • PHP-FPM:全称FastCGI Process Manager,看名称就可以知道,PHP-FPM是FastCGI进程的管理器,但前面讲到FastCGI是协议并不是程序,所以它管理的是PHP-CGI,形成了一个类似PHP-CGI进程池的概念。

  • Wrapper:字母意思是包装的意思,包装的是谁呢?包装的是FastCGI,通过FastCGI接口,Wrapper接收到请求后,会生成一个新的线程调用PHP解释器来处理数据。

二、Fastcgi协议

1.Fastecgi Record

        Fastcgi其实是一个通信协议,fastcgi协议则是服务器中间件和某个语言后端进行数据交换的协议。Fastcgi协议由多个record组成,record也有header和body一说,服务器中间件将这二者按照fastcgi的规则封装好发送给语言后端,语言后端解码以后拿到具体数据,进行指定操作,并将结果再按照该协议封装好后返回给服务器中间件。其结构如下

typedef struct {
  /* Header */
  unsigned char version; // 版本
  unsigned char type; // 本次record的类型
  unsigned char requestIdB1; // 本次record对应的请求id
  unsigned char requestIdB0;
  unsigned char contentLengthB1; // body体的大小
  unsigned char contentLengthB0;
  unsigned char paddingLength; // 额外块大小
  unsigned char reserved; 

  /* Body */
  unsigned char contentData[contentLength];
  unsigned char paddingData[paddingLength];
} FCGI_Record;

        头由8个uchar类型的变量组成,每个变量1字节。其中,requestId占两个字节,一个唯一的标志id,以避免多个请求之间的影响;contentLength占两个字节,表示body的大小。

        语言端解析了fastcgi头以后,拿到contentLength,然后再在TCP流里读取大小等于contentLength的数据,这就是body体。

我们需要注意的是typre类型

2.Fastcgi Type

        type是用来编辑fastcgi的主要作用,最主要的是1、4、6

安全中级2:nginx的中间件漏洞

        值得注意的是,当我们的type是4的时候,就会按照对应的结构解析成我们的key-value,结构如下

typedef struct {
  unsigned char nameLengthB0;  /* nameLengthB0  >> 7 == 0 */
  unsigned char valueLengthB0; /* valueLengthB0 >> 7 == 0 */
  unsigned char nameData[nameLength];
  unsigned char valueData[valueLength];
} FCGI_NameValuePair11;

typedef struct {
  unsigned char nameLengthB0;  /* nameLengthB0  >> 7 == 0 */
  unsigned char valueLengthB3; /* valueLengthB3 >> 7 == 1 */
  unsigned char valueLengthB2;
  unsigned char valueLengthB1;
  unsigned char valueLengthB0;
  unsigned char nameData[nameLength];
  unsigned char valueData[valueLength
          ((B3 & 0x7f) << 24) + (B2 << 16) + (B1 << 8) + B0];
} FCGI_NameValuePair14;

typedef struct {
  unsigned char nameLengthB3;  /* nameLengthB3  >> 7 == 1 */
  unsigned char nameLengthB2;
  unsigned char nameLengthB1;
  unsigned char nameLengthB0;
  unsigned char valueLengthB0; /* valueLengthB0 >> 7 == 0 */
  unsigned char nameData[nameLength
          ((B3 & 0x7f) << 24) + (B2 << 16) + (B1 << 8) + B0];
  unsigned char valueData[valueLength];
} FCGI_NameValuePair41;

typedef struct {
  unsigned char nameLengthB3;  /* nameLengthB3  >> 7 == 1 */
  unsigned char nameLengthB2;
  unsigned char nameLengthB1;
  unsigned char nameLengthB0;
  unsigned char valueLengthB3; /* valueLengthB3 >> 7 == 1 */
  unsigned char valueLengthB2;
  unsigned char valueLengthB1;
  unsigned char valueLengthB0;
  unsigned char nameData[nameLength
          ((B3 & 0x7f) << 24) + (B2 << 16) + (B1 << 8) + B0];
  unsigned char valueData[valueLength
          ((B3 & 0x7f) << 24) + (B2 << 16) + (B1 << 8) + B0];
} FCGI_NameValuePair44;

        我们需要注意的是上述我标红的部分,当为44的部分时候,会将我们的key-value,传递到我们的php-fpm解析成我们真正的数据。

3.PHP-FPM(FastCGI进程管理器)

        FPM其实是一个fastcgi协议解析器,Nginx等服务器中间件将用户请求按照fastcgi的规则打包好通过TCP传给FPM,FPM按照fastcgi的协议将key-value解析成真正的数据。结构如下

{
    'GATEWAY_INTERFACE': 'FastCGI/1.0',
    'REQUEST_METHOD': 'GET',
    'SCRIPT_FILENAME': '/var/www/html/index.php',
    'SCRIPT_NAME': '/index.php',
    'QUERY_STRING': '?a=1&b=2',
    'REQUEST_URI': '/index.php?a=1&b=2',
    'DOCUMENT_ROOT': '/var/www/html',
    'SERVER_SOFTWARE': 'php/fcgiclient',
    'REMOTE_ADDR': '127.0.0.1',
    'REMOTE_PORT': '12345',
    'SERVER_ADDR': '127.0.0.1',
    'SERVER_PORT': '80',
    'SERVER_NAME': "localhost",
    'SERVER_PROTOCOL': 'HTTP/1.1'
}

最后执行SCRIPT_FILENAM的指向的PHP文件,将这个数据返回给我们的浏览器。

4.总结FastCGI解析的流程

        首先nginx接收到数据后,会被fastcgi处理,会按照type为4,构造出我们的key-value,然后传递给我们的php-fpm,php-fpm会将key-value对解析成我们真正的数据,这个数据中包含我们的版本,传参方式,请求文件根目录路径,请求的文件,请求参数等。然后根据数据请求我们的php,完成我们的nginx+php的请求。

三、nginx配置错误导致的漏洞

注意:1.先下载好文件(漏洞文件下载地址)

        2.进入到vulhub/nginx/insecure-configuration/这个目录下

        3.启用docker加载环境(docker-compose up -d)

1.CRLF注入漏洞($uri解码漏洞,换行符导致的注入漏洞)

(1)原理

        在我们访问http://example.com/abc时,我们的网页会自动的跳转到http://www.example.com/abc,但是在跳转的过程之中需要保持我们的uri(也就是网址后面的部分,比如abc)不变,在nginx配置中有三种配置uri的方法$uri、$document_uri、$request_uri,在这里面$uri和$document_uri是解码后的请求路径,而$request_uri并没进行解码,正是因为uri解码,我们可以利用%0d%0a(换行符),在我们的uri后面写入我们恶意代码,从而插入到我们的referer的头部,从而修改我们的头部信息。

(2)利用CRLF修改头部信息

a.nginx运维的错误配置

安全中级2:nginx的中间件漏洞

b.注入一个set-cookie

curl -I http://127.0.0.1:8080%0d%0aset-cookie:%20jiege666

安全中级2:nginx的中间件漏洞

安全中级2:nginx的中间件漏洞

(3)CRLF+Bottle HTTP造成的反射性xss漏洞

a.bottle搭建起来的环境,利用python运行下面代码

import bottle
from bottle import route, run, template, request, response

@route('/')
def index():
    server = request.query.get('server')
    response.add_header('Server',server)
    return response

if __name__ == '__main__':
    bottle.debug(True)
    run(host='localhost', port=8081)

安全中级2:nginx的中间件漏洞

b.在浏览器输入以下的请求

http://localhost:8081/server=jiege%0d%0aX-XSS-Protection:0%0d%0a%0d%0a<script>alert(location.href)</script>

安全中级2:nginx的中间件漏洞

c.结果

安全中级2:nginx的中间件漏洞

d.原理

        我们分析代码,发现server接收我们的内容,我们随意赋值,加入一个%0d%0a(换行符)先给他换行,然后在他的referer头部插入X-XSS-Protection:0,这个是浏览用来防止我们进行xss注入的,所以我们拆入头部将他关闭,然后%0d%0a%0d%0a之所以是两个换行符,是为了让后面的内容插入到我们的body也就是我们的html里面的,后面跟上我们<script>alert(location.href)</script>,就可以造成我们的xss反射性漏洞弹窗,从而获取我们的路径,也可以是其他恶意代码。以上就完成我们的CRLF+Bottle HTTP的xss漏洞

e.防御CRLF+Bottle HTTP

        第一种就是使用CSP禁止iframe跳转,第二种是将跳转的url端口设置<80

(4)防御

        我们可以在配置nginx的uri的跳转的时候,配置成$request_uri这样就可以防止浏览器自己解码了,从而防御住了我们的CRLF(换行符漏洞)

2.目录穿越漏洞

(1)原理

        nginx在配置别名(alias)的时候忘记加了/,让原本访问某个目录下的文件,攻击者多加../就会返回到根目录,从而造成了目录穿越漏洞。

(2)漏洞复现

a.出现错误的配置文件

安全中级2:nginx的中间件漏洞

b.在浏览器输入

http://192.168.191.129:8081/files../

安全中级2:nginx的中间件漏洞

c.结果

安全中级2:nginx的中间件漏洞

d.漏洞利用

        我们可以进入到/usr/local/nginx/html/下,下载我们的config.php也就是我们的数据库连接文件,获得数据库的用户名和密码,登陆数据库阻止其他人的连接,或者获取数据。

(3)防御

        给location /files 和alias  /home的后面同时加/,或者都不加

安全中级2:nginx的中间件漏洞安全中级2:nginx的中间件漏洞

3.Http add_header被覆盖的问题

(1)原理

        nginx在配置子模块(server location if)的add_header的时候,将会覆盖父模块的add_header头部,从而造成的隐患。

(2)CSP(Content-Security-Policy)

        主要是为了防止XSS的存在,阻止入侵者插入存在第三方跳转的链接

(3)漏洞的复现

a.后端出现配置错误的文件

        我们不难发现在我们的子模块中出现了add_header,而我们的父模块是只允许我们内部引用js,而我们的字模块却可以引用外部js,又因为我们的子模块会覆盖父模块,这就导致了漏洞的存在。

安全中级2:nginx的中间件漏洞

b.我们正常访问页面test1,发现页面存在csp只允许加载本地js

安全中级2:nginx的中间件漏洞

c.我们在访问test2,发现csp被覆盖了可以访问外部js,我们利用这一点进行攻击

安全中级2:nginx的中间件漏洞

d.在浏览器插入以下的请求

http://192.168.191.129:8082/test2#<img src=1 οnerrοr=alert(jiege666)>

安全中级2:nginx的中间件漏洞

e.我们查看页面弹出弹窗就可以进行xss漏洞的注入

安全中级2:nginx的中间件漏洞

         一般情况下会出现一个弹窗的,可能由于我们的浏览器版本可能太高了,可以降低浏览器版本就可以实现弹窗了

(4)防御

        在配置子模块的时候,不要重复去添加父模块所含有的add_header头部

四、nginx文件名逻辑漏洞(Nginx 0.8.41 ~ 1.4.3 /1.5.0 ~ 1.5.7 )

1.原理

        因为我们上传了一个文件名为1.gif \0.php文件,首先我们的nginx解析到他是php结尾的文件,之后将他发送给我们的fastcgi,我们的fastcgi将这个数据解析完成后,又由于1.gif \0.php,\0也就是c语言的结束符的意思,之后我们的通过我们的\0将这个文件名截断成我们的fastcgi认为他到1.gif就结束了,之后对上传的文件进行检查,发现他没有以php结尾,就将这个文件上传上去,然后我们的php-fpm.conf的安全后缀策略(security.limit_extensions = )是空的,之后他就会执行我们上传的1.gif \0.php文件。

安全中级2:nginx的中间件漏洞

 安全中级2:nginx的中间件漏洞

2.文件名逻辑漏洞的复现

(1)首先创建一个文本,里面输入php代码

<?php phpinfo(); ?>

安全中级2:nginx的中间件漏洞

(2)修改文件后缀名为1.gif

安全中级2:nginx的中间件漏洞

(3)打开浏览器输入

http://192.168.191.129:8080

安全中级2:nginx的中间件漏洞

(4)选择我们1.gif文件

安全中级2:nginx的中间件漏洞

(5)打开抓包工具,之后上传文件抓包

安全中级2:nginx的中间件漏洞

(6)找到文件名给他加成1.gifaa.php

安全中级2:nginx的中间件漏洞

(7)进入到hex也就是编码数字的部分,修改文件名,将aa改成20和00,主要是让他生成 \0(也就是一个空格和阶段符号)。

安全中级2:nginx的中间件漏洞

安全中级2:nginx的中间件漏洞

(8)将修改的数据包放行提交到端

安全中级2:nginx的中间件漏洞

(9)查看我们上传图片的目录

http://192.168.191.129:8080/uploadfiles/1.gif

安全中级2:nginx的中间件漏洞

 (10)打开抓包工具抓取该网页,出现以下问题,是因为我们禁止了抓包工具抓取图片,我们点击开启就可以了。

安全中级2:nginx的中间件漏洞

 (11)抓包

安全中级2:nginx的中间件漏洞

 (13)修改我们的文件名为1.gifaa.php

安全中级2:nginx的中间件漏洞

 (14)进入到hex下,修改我们的aa编码为20和00,就是空格和截断符,这里主要是为了和我们上传的文件名一样

安全中级2:nginx的中间件漏洞

安全中级2:nginx的中间件漏洞

 (15)将我们修改过的数据包发送就会看到我们注意的php页面

安全中级2:nginx的中间件漏洞

 3.防御

        我们在配置php-fpm.conf的安全后缀策略(security.limit_extensions = jpg gif)尽量不要设置为空,这样就可以防御我们的nginx文件名逻辑漏洞。

五、nginx的解析漏洞

1.原理

        我们在配置php.ini的时候,开启了我们的自动修复路径(cgi.fix_pathinfo=1),也就是我们访问http://127.0.0.1/test.jpg/test.php,由于没有test.php这个文件我们服务器会自动到上一个路径,发现有test.jpg于是就自己执行了这个文件,但是由于我们在配置php-fpm.conf的安全后缀策略(security.limit_extensions = jpg php )为空或者就只有jpg和php,我们的服务就会执行jpg和php,我们的test.jpg里面就是我们的恶意的php代码,之后通过解析为php文件就导致了我们执行该文件,从而产生了我们的漏洞。

2.nginx解析漏洞复现

(1)先看我们php-fpm配置文件,发现我们的后缀名安全策略为空的

安全中级2:nginx的中间件漏洞

(2)访问http://192.168.191.129/uplocalfiles/nginx.png

http://192.168.191.129/uplocalfiles/nginx.png

安全中级2:nginx的中间件漏洞

(3)在上面路径后面随意添加一个以.php结尾的文件

http://192.168.191.129/uplocalfiles/nginx.png/nginx.php

安全中级2:nginx的中间件漏洞

 (4)触发我们的php恶意代码

安全中级2:nginx的中间件漏洞文章来源地址https://www.toymoban.com/news/detail-492846.html

(5)还有一种方法和上面nginx逻辑名漏洞一样上传php恶意文件,修改名称,第二次直接访问就会触发

到了这里,关于安全中级2:nginx的中间件漏洞的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 中间件安全-CVE复现&IIS&Apache&Tomcat&Nginx漏洞复现

    中间件及框架列表: IIS,Apache,Nginx,Tomcat,Docker,Weblogic,JBoos,WebSphere, Jenkins ,GlassFish,Jira,Struts2,Laravel,Solr,Shiro,Thinkphp, Spring,Flask,jQuery等 1、中间件-IIS-短文件解析蓝屏等 2、中间件-Nginx-文件解析命令执行等 3、中间件-Apache-RCE目录遍历文件解析等 4、中间件

    2024年02月07日
    浏览(50)
  • 小迪安全33WEB 攻防-通用漏洞&文件上传&中间件解析漏洞&编辑器安全

    # 知识点: 1 、中间件安全问题 2 、中间件文件上传解析 3 、 Web 应用编辑器上传 编辑器也就是第三方插件,一般都是文件上传漏洞 # 详细点: 1 、检测层面:前端,后端等 2 、检测内容:文件头,完整性,二次渲染等 3 、检测后缀:黑名单,白名单, MIME 检测等 4 、绕过技

    2024年03月16日
    浏览(60)
  • 服务攻防-中间件安全&CVE复现&IIS&Apache&Tomcat&Nginx漏洞复现

    目录 一、导图 二、ISS漏洞 中间件介绍 1、短文件 2、文件解析 3、HTTP.SYS 4、cve-2017-7269 三、Nignx漏洞 中间件介绍 1、后缀解析漏洞 2、cve-2013-4547 3、cve-2021-23017 无 EXP 4、cve-2017-7529 意义不大 四、Apache漏洞 中间件介绍 1、漏洞版本简介 2、cve-2021-42013 3、cve-2021-41773 4、cve-2017-1571

    2024年02月10日
    浏览(63)
  • day33WEB 攻防-通用漏洞&;文件上传&;中间件解析漏洞&;编辑器安全

    先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前阿里P7 深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前! 因此收集整理了一份《2024年最新网络安全全套学习资料》

    2024年04月24日
    浏览(62)
  • day33WEB 攻防-通用漏洞&;文件上传&;中间件解析漏洞&;编辑器安全(1)

    2、解析漏洞-nginx.conf 配置不当 二,Web 应用编辑器-Ueditor 文件上传安全 三,实例 CMS平台-中间件解析编辑器引用 配套资源下载(百度网盘): 链接:https://pan.baidu.com/s/11Q9sAPQ9P_ReOP9PKL0ABg?pwd=jgg4  提取码:jgg4 本章节知识点: 1 、中间件安全问题 2 、中间件文件上传解析 3 、

    2024年04月15日
    浏览(89)
  • 中间件漏洞解析

     服务器解析漏洞算是历史比较悠久了,但如今依然广泛存在。在此记录汇总一些常见服务器(WEB server)的解析漏洞,比如IIS6.0、IIS7.5、apache、nginx等 2 | 1 1、打开之前的一个网站,比如:cookies 2 | 2 2.目录解析漏洞 找到cookies,新建一个名字为.asp(也可以是.cer和.asa)的文件夹,这

    2024年02月12日
    浏览(49)
  • 中间件安全—Apache常见漏洞

      简单介绍一下apache是什么,Apache是世界使用排名第一的Web服务器软件。它可以运行在几乎所有广泛使用的计算机上,由于其跨平台和安全性被广泛使用,是最流行的Web服务器端软件之一。它快速、可靠并且可通过简单的API扩充,将python等解释器编译到服务器中。 1.2.1.漏洞

    2024年01月22日
    浏览(52)
  • 中间件安全—Tomcat常见漏洞

      整个复现环境均使用Vulhub一键搭建漏洞测试靶场,Vulhub靶场:链接 1.2.1.漏洞原理   Tomcat配置文件/conf/web.xml 配置了可写(readonly=false),导致可以使用PUT方法上传任意文件,攻击者将精心构造的payload向服务器上传包含任意代码的 JSP 文件。之后,JSP 文件中的代码将能被

    2024年02月08日
    浏览(60)
  • 从理论上理解SQL注入、XSS、中间件解析漏洞、挖矿马

    目录 1、SQL注入 (1)原理 (2)分类 (3)防御 2、XSS (1)原理 (2)分类 3、中间件(解析漏洞) (1)IIS6.X (2)Apache (3)Nginx和IIS7.5 4、挖矿木马 web应用对用户输入数据过滤不严谨,并把数据当做SQL语句带入数据库中执行。 XSS又叫跨站脚本攻击,是HTML代码注入,通过对

    2024年02月08日
    浏览(49)
  • 中间件安全-CVE复现&Weblogic&Jenkins&GlassFish漏洞复现

    中间件及框架列表: IIS,Apache,Nginx,Tomcat,Docker,Weblogic,JBoos,WebSphere, Jenkins ,GlassFish,Jira,Struts2,Laravel,Solr,Shiro,Thinkphp, Spring,Flask,jQuery等 1、中间件-Weblogic安全 2、中间件-JBoos安全 3、中间件-Jenkins安全 4、中间件-GlassFish安全 常见中间件的安全测试: 1、配置

    2024年02月08日
    浏览(43)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包