zoukankan      html  css  js  c++  java
  • 文件上传的思考 (转) http://blog.csdn.net/ncafei/article/details/53401961

    文件上传校验

    客户端JavaScript校验(一般只校验后缀名)

            一般都是在网页上写一段javascript脚本,校验上传文件的后缀名,有白名单形式也有黑名单形式。
      判断方式:在浏览加载文件,但还未点击上传按钮时便弹出对话框,内容如:只允许上传.jpg/.jpeg/.png后缀名的文件,而此时并没有发送数据包。

    服务端校验:

    1、文件头content-type字段校验(image/gif):代码对上传文件的文件类型进行了判断,如果不是图片类型,返回错误。

    2、文件内容头校验(GIF89a):

      可以通过自己写正则匹配,判断文件头内容是否符合要求,这里举几个常见的文件头对应关系:
    (1)  .JPEG;.JPE;.JPG,”JPGGraphic File”
    (2)  .gif,”GIF 89A”
    (3)  .zip,”Zip Compressed”
    (4)  .doc;.xls;.xlt;.ppt;.apr,”MS Compound Document v1 or Lotus Approach APRfile”

    3、后缀名黑名单校验,后缀名白名单校验,自定义正则校验,WAF设备校验(根据不同的WAF产品而定)

    文件上传绕过校验

    客户端绕过(抓包改包)  服务端绕过    文件类型  文件头  文件后缀名  配合文件包含漏洞绕过  配合服务器解析漏洞绕过    CMS、编辑器漏洞绕过   配合操作系统文件命名规则绕过  配合其他规则绕过  WAF绕过

    1.客户端绕过

      可以利用burp抓包改包,先上传一个gif类型的木马,然后通过burp将其改为asp/php/jsp后缀名即可。

    2.服务端绕过

    2.1 文件类型绕过

      我们可以通过抓包,将content-type字段改为image/gi

    2.2 文件头绕过

      在木马内容基础上再加了一些文件信息,有点像下面的结构
    GIF89a<?php phpinfo(); ?>

    2.3 文件后缀名绕过

    前提:黑名单校验
    黑名单检测:一般有个专门的 blacklist 文件,里面会包含常见的危险脚本文件。
    绕过方法:
    (1)找黑名单扩展名的漏网之鱼 - 比如 asa 和 cer 之类
    (2)可能存在大小写绕过漏洞 - 比如 aSp 和 pHp 之类
    能被解析的文件扩展名列表:
    jsp  jspx  jspf
    asp  asa  cer  aspx
    php  php  php3  php4
    exe  exee

    3.配合文件包含漏洞

    前提:校验规则只校验当文件后缀名为asp/php/jsp的文件内容是否为木马。
    绕过方式:(这里拿php为例,此漏洞主要存在于PHP中)
    (1)先上传一个内容为木马的txt后缀文件,因为后缀名的关系没有检验内容;
    (2)然后再上传一个.php的文件,内容为<?php Include(“上传的txt文件路径”);?>
    此时,这个php文件就会去引用txt文件的内容,从而绕过校验,

    下面列举包含的语法:

    #PHP    

    <?php Include("上传的txt文件路径");?>

    #ASP    

    <!--#include file="上传的txt文件路径" -->

    #JSP    

    <jsp:inclde page="上传的txt文件路径"/>

    or

    <%@include file="上传的txt文件路径"%>

    4.配合服务器解析漏洞

    详细可参考:http://thief.one/2016/09/21/服务器解析漏洞/

    5.配合操作系统文件命令规则

    (1)上传不符合windows文件命名规则的文件名
      test.asp.
      test.asp(空格)
      test.php:1.jpg
      test.php::$DATA
      shell.php::$DATA…….
    会被windows系统自动去掉不符合规则符号后面的内容。

    (2)Linux下后缀名大小写
    linux下,如果上传php不被解析,可以试试上传pHp后缀的文件名。

    6.CMS、编辑器漏洞

    (1)CMS漏洞:比如说JCMS等存在的漏洞,可以针对不同CMS存在的上传漏洞进行绕过。
    (2)编辑器漏洞:比如FCK,ewebeditor等,可以针对编辑器的漏洞进行绕过。
    这两方面的漏洞以后单独成文汇总,这里点到为止。

    7.配合其他规则

    (1)0x00截断:基于一个组合逻辑漏洞造成的,通常存在于构造上传文件路径的时候
      test.php(0x00).jpg
      test.php%00.jpg

    路径/upload/1.php(0x00),文件名1.jpg,结合/upload/1.php(0x00)/1.jpg
    伪代码演示:

    name= getname(httprequest) //假如这时候获取到的文件名是 help.asp.jpg(asp 后面为 0x00)

    type =gettype(name)        //而在 gettype()函数里处理方式是从后往前扫描扩展名,所以判断为 jpg

    if(type == jpg)

    SaveFileToPath(UploadPath.name, name)   //但在这里却是以 0x00 作为文件名截断

    //最后以 help.asp 存入路径里

    8.WAF绕过

    8.1 垃圾数据

    有些主机WAF软件为了不影响web服务器的性能,会对校验的用户数据设置大小上限,比如1M。此种情况可以构造一个大文件,前面1M的内容为垃圾内容,后面才是真正的木马内容,便可以绕过WAF对文件内容的校验;

    当然也可以将垃圾数据放在数据包最开头,这样便可以绕过对文件名的校验。可以将垃圾数据加上Content-Disposition参数后面,参数内容过长,可能会导致waf检测出错

    8.2 filename

    针对早期版本安全狗,可以多加一个filename或者将filename换位置,在IIS6.0下如果我们换一种书写方式,把filename放在其他地方:

    8.3 POST/GET

    有些WAF的规则是:如果数据包为POST类型,则校验数据包内容。
    此种情况可以上传一个POST型的数据包,抓包将POST改为GET。

    8.4 以上方式

    针对WAF,以上介绍的服务器解析漏洞、文件包含漏洞等都可以尝试绕过。

    8.5 利用waf本身缺陷
    删除实体里面的Conten-Type字段

    第一种是删除Content整行,第二种是删除C后面的字符。删除掉ontent-Type: image/jpeg只留下c,将.php加c后面即可,但是要注意额,双引号要跟着c.php。

    正常包:Content-Disposition: form-data; name="image"; filename="085733uykwusqcs8vw8wky.png"Content-Type: image/png

    构造包:Content-Disposition: form-data; name="image"; filename="085733uykwusqcs8vw8wky.png

    C.php"

    删除Content-Disposition字段里的空格

    增加一个空格导致安全狗被绕过案列:
    Content-Type: multipart/form-data; boundary=—————————471****1141173****525****99
    尝试在boundary后面加个空格或者其他可被正常处理的字符:
    boundary= —————————471****1141173****525****50

    修改Content-Disposition字段值的大小写
    Boundary边界不一致

    每次文件上传时的Boundary边界都是一致的:

    Content-Type: multipart/form-data; boundary=---------------------------471****1141173****525****99

    Content-Length: 253

    -----------------------------471****1141173****525****99

    Content-Disposition: form-data; name="file1"; filename="shell.asp"

    Content-Type: application/octet-stream

    <%eval request("a")%>

    -----------------------------471****1141173****525****99--

    但如果容器在处理的过程中并没有严格要求一致的话可能会导致一个问题,两段Boundary不一致使得waf认为这段数据是无意义的,可是容器并没有那么严谨:
    Win2k3 + IIS6.0 + ASP

    文件名处回车

    多个Content-Disposition

    在IIS的环境下,上传文件时如果存在多个Content-Disposition的话,IIS会取第一个Content-Disposition中的值作为接收参数,而如果waf只是取最后一个的话便会被绕过,Win2k8 + IIS7.0 + PHP

    利用NTFS ADS特性

    ADS是NTFS磁盘格式的一个特性,用于NTFS交换数据流。在上传文件时,如果waf对请求正文的filename匹配不当的话可能会导致绕过。

    其他情况补充

    文件重命名绕过

    如果web程序会将filename除了扩展名的那段重命名的话,那么还可以构造更多的点、符号等等。

    特殊的长文件名绕过

    文件名使用非字母数字,比如中文等最大程度的拉长,不行的话再结合一下其他的特性进行测试:
    shell.asp;王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王.jpg

    反删除

    将下图file1改成了file4,这样就不会把这个文件删除了。(JCMS漏洞)

    文件校验的几点建议

    • 文件扩展名服务端白名单校验。

    • 文件内容服务端校验。

    • 上传文件重命名。

    • 隐藏上传文件路径。

      以上几点,可以防御绝大多数上传漏洞,但是需要跟服务器容器结合起来。如果解析漏洞依然存在,那么没有绝对的安全。

    文件上传漏洞及解析漏洞总结

    文件上传漏洞是指用户上传了一个可执行的脚本文件,并通过此脚本文件获得了执行服务器端命令的能力。这种攻击方式是最为直接和有效的,“文件上传”本身没有问题,有问题的是文件上传后,服务器怎么处理、解释文件。如果服务器的处理逻辑做的不够安全,则会导致严重的后果。

    文件上传后导致的常见安全问题一般有:

    1)上传文件是Web脚本语言,服务器的Web容器解释并执行了用户上传的脚本,导致代码执行。

    2)上传文件是Flash的策略文件crossdomain.xml,黑客用以控制Flash在该域下的行为(其他通过类似方式控制策略文件的情况类似);

    3)上传文件是病毒、木马文件,黑客用以诱骗用户或者管理员下载执行。

    4)上传文件是钓鱼图片或为包含了脚本的图片,在某些版本的浏览器中会被作为脚本执行,被用于钓鱼和欺诈。

    除此之外,还有一些不常见的利用方法,比如将上传文件作为一个入口,溢出服务器的后台处理程序,如图片解析模块;或者上传一个合法的文本文件,其内容包含了PHP脚本,再通过"本地文件包含漏洞(Local File Include)"执行此脚本;等等。

    要完成这个攻击,要满足以下几个条件:

    首先,上传的文件能够被Web容器解释执行。所以文件上传后所在的目录要是Web容器所覆盖到的路径。

    其次,用户能够从Web上访问这个文件。如果文件上传了,但用户无法通过Web访问,或者无法得到Web容器解释这个脚本,那么也不能称之为漏洞。

    最后,用户上传的文件若被安全检查、格式化、图片压缩等功能改变了内容,则也可能导致攻击不成功。

    一、从FCKEditor文件上传漏洞谈起

    FCKEditor是一款非常流行的富文本编辑器,为了方便用户,它带有一个文件上传功能,但是这个功能却出过多次漏洞。

    FCKEditor针对ASP/PHP/JSP等环境都有对应的版本,以PHP为例,其文件上传功能在:

    http://www.xxx.com/path/FCKEditor/editor/filemanager/browser/default/browser.html?,配合解析漏洞。

    (一)IIS5.x-6.x解析漏洞

    使用iis5.x-6.x版本的服务器,大多为windows server 2003,网站比较古老,开发语句一般为asp;该解析漏洞也只能解析asp文件,而不能解析aspx文件。

    目录解析(6.0)

    形式:www.xxx.com/xx.asp/xx.jpg

    原理: 服务器默认会把.asp,.asp目录下的文件都解析成asp文件。

    文件解析

    形式:www.xxx.com/xx.asp;.jpg

    原理:服务器默认不解析;号后面的内容,因此xx.asp;.jpg便被解析成asp文件了。

    解析文件类型

    IIS6.0 默认的可执行文件除了asp还包含这三种 :

    /test.asa

    /test.cer

    /test.cdx

    (二)apache解析漏洞

    漏洞原理

    Apache 解析文件的规则是从右到左开始判断解析,如果后缀名为不可识别文件解析,就再往左判断。比如test.php.qwe.asd “.qwe”和”.asd” 这两种后缀是apache不可识别解析,apache就会把wooyun.php.qwe.asd解析成php。

    漏洞形式

    www.xxxx.xxx.com/test.php.php123

    其余配置问题导致漏洞

    (1)如果在 Apache 的 conf 里有这样一行配置 AddHandler php5-script .php 这时只要文件名里包含.php 即使文件名是 test2.php.jpg 也会以 php 来执行。

    (2)如果在 Apache 的 conf 里有这样一行配置 AddType application/x-httpd-php .jpg 即使扩展名是 jpg,一样能以php 方式执行。

    修复方案

    1.apache配置文件,禁止.php.这样的文件执行,配置文件里面加入

    2.用伪静态能解决这个问题,重写类似.php.*这类文件,打开apache的httpd.conf找到LoadModule rewrite_module modules/mod_rewrite.so

    把#号去掉,重启apache,在网站根目录下建立.htaccess文件

    (三)nginx解析漏洞

    漏洞原理

    Nginx默认是以CGI的方式支持PHP解析的,普遍的做法是在Nginx配置文件中通过正则匹配设置SCRIPT_FILENAME。当访问www.xx.com/phpinfo.jpg/1.php这个URL时,$fastcgi_script_name会被设置为“phpinfo.jpg/1.php”,然后构造成SCRIPT_FILENAME传递给PHP CGI,但是PHP为什么会接受这样的参数,并将phpinfo.jpg作为PHP文件解析呢?这就要说到fix_pathinfo这个选项了。 如果开启了这个选项,那么就会触发在PHP中的如下逻辑:

    PHP会认为SCRIPT_FILENAME是phpinfo.jpg,而1.php是PATH_INFO,所以就会将phpinfo.jpg作为PHP文件来解析了

    漏洞形式

    www.xxxx.com/UploadFiles/image/1.jpg/1.php

    www.xxxx.com/UploadFiles/image/1.jpg%00.php

    www.xxxx.com/UploadFiles/image/1.jpg/%20.php

    另外一种手法:上传一个名字为test.jpg,然后访问test.jpg/.php,在这个目录下就会生成一句话木马shell.php。

    (四)IIS7.5解析漏洞

    IIS7.5的漏洞与nginx的类似,都是由于php配置文件中,开启了cgi.fix_pathinfo,而这并不是nginx或者iis7.5本身的漏洞。

    5.配合操作系统文件命令规则

    (1)上传不符合windows文件命名规则的文件名

    test.asp.

    test.asp(空格)

    test.php:1.jpg

    test.php:: $DATA

    会被windows系统自动去掉不符合规则符号后面的内容。

    如图访问ip/Netsys/HtmlEdit/fckeditor/editor/filemanager/connectors/test.html

  • 相关阅读:
    vue 兼容ie 下载文件
    IDEA maven项目添加自己的jar包依赖
    mongodb 用户权限操作
    springboot + aspect
    Enum枚举类
    线上CPU飙升100%问题排查
    Linux零拷贝技术
    Java线程池实现原理及其在美团业务中的实践
    深入解析String#intern
    Java对象内存布局
  • 原文地址:https://www.cnblogs.com/lhq8998/p/7276884.html
Copyright © 2011-2022 走看看