关于File Upload的一些思考

在web渗透中，文件上传是最简单直接的方式之一。但是碰到完全不做校验的代码直接上传getshell，很难有这样的运气；大部分时候都有检测，甚至多处设卡。

若按设卡点的顺序来说可大致分为：前端js检验、防护检测（waf）、服务端检测。

这里就讲如何绕过服务端代码的检测，服务端会出现文件上传的什么安全配置。

一图顶千言，请看下图：

服务端的代码常检测request包中的三个点：

1）MIME类型 

2）文件后缀

3）文件内容

如下图所示：

理论上请求包的任何参数都可以作为检测点，但是对于文件上传功能来说，用户提交的请求包中这三个地方，是辨别是否为恶意文件的重要的三个点，所以大部份后端程序的都是检测这么三个地方。

这三个检测点详细的检测方式，如下图所示:

讲了这么多，那么该怎进行绕过呢？

话不多说，开始吧！

我们先来看一段在w3c上的，检验MIME类型的一段php代码，如下图所示:

可以看见上面代码中只校验了http头中的MIME类型。

这MIME类型的校验啊，就好比：

城门守卫问你：“你是不是好人？”（php代码中的if判断）

你只需回答：“我是好人！”（request包中content-type字段改为image/jpeg）

然后，城门守卫就放行了。

至于你到底是不是好人，和你如何回答的是没有丝毫关系的。

这个逻辑适用于很多情况，这也是安全的基础：不信任任何客户端提交的数据。

文件后缀检测分两种情况：白名单和黑名单。

绕过白名单或黑名单有诸多姿势：“服务器解析漏洞” 、 “文件命名规则”、“00截断”、“长度截断”、“竞争上传”、“双上传”、“可解析后缀”、“.htacees和user.ini”、“误用函数”等等。

废话不多说，请看下图：

1、服务器解析漏洞

1.1、apache解析漏洞

首先，对于Apache服务器来说，哪些后缀可以被解析是由什么决定呢？

apache中有一个关于php的默认配置文件，其中用正则指定了哪些后缀使用哪些解析器。如图：

apache解析又一个特点，解析文件时是从右往左判断，遇到不认识的后缀时，就跳过，于是就有了类似于“.php.123”这种绕过方式。

但是从上图可以看到，这种方式在这种配置情况下是行不通的，但是在“CVE-2017-15715”中提到了可以使用%0a绕过，因为在上面正则中“.php$”代表以“.php”结尾或者“以.php”结尾加换行，可是一般情况下程序员获取文件后缀时会使用“$_FILES[‘file’][‘name’]”，它会自动过滤掉换行，这就让这个漏洞显得有些尴尬了。

大多情况下，我们遇到apache解析漏洞的是配置错误导致的，比如下面这条语句。

这种情况下，只要文件后缀包含“php”关键字，文件就会被作为php来解析。

1.2、nginx和iis7.5/7.0解析漏洞

此解析漏洞其实是php的配置错误导致。