文件上传验证绕过技术总结

文件上传验证绕过技术总结

 1.客户端验证绕过php

很简单啦,直接使用webscarab或者burp修改一下后缀名就行。css

2.服务端验证绕过-Content-type检测html

若服务端检测文件类型时是检测Content-type的值,也很简单,在webscarab或者burp中修改Content-type。nginx

如php中 if($_FILES['userfile']['type'] != “image/gif”) 便是检测Content-type值。web

3.服务端验证绕过-扩展名检测shell

a. 寻找漏网之鱼,如fckeditor 2.4.3 或以前版本的黑名单中就能够上传诸如asa,cer之类的文件。windows

b. 大小写绕过,如aSp,pHp。安全

c. 特别文件名构造。app

好比发送的http 包里把文件名改为help.asp. 或help.asp_(下划线为空
格),这种命名方式在windows 系统里是不被容许的,因此须要在burp 之类里进行修改,然
后绕过验证后,会被windows 系统自动去掉后面的点和空格。函数

d. IIS或者nginx文件解析漏洞。好比好比help.asp;.jpg 或http://www.xx.com/help.jpg/2.php。

e. 0×00截断绕过。例如:help.asp .jpg(asp后面为0×00),在判断时,大多函数取后缀名是从后往前取,故可以经过,可是在保存时,却被保存为help.asp。

f. 双扩展名解析绕过攻击(1)

若是上传一个文件名为help.php.123首先扩展名123 并无在扩展名blacklist 里,而后扩展名123 也没在Apache 可解析扩展名
list 里,这个时候它会向前搜寻下一个可解析扩展名,或搜寻到.php,最后会以php 执行。

g. 双扩展名解析绕过攻击(2)

若是在Apache 的conf 里有这样一行配置

AddHandler php5-script .php

这时只要文件名里包含.php,即便文件名是test2.php.jpg 也会以php 来执行。

h. 危险解析绕过攻击- 基于web 服务的解析方式

若是在Apache 的conf 里有这样一行配置
AddType application/x-httpd-php .jpg
即便扩展名是jpg,同样能以php 方式执行

a. 特别文件名构造(同黑名单攻击 列c)

b.IIS或者ngnix文件解析漏洞(同黑名单攻击 列d)

c. 0×00截断绕过 (同黑名单攻击 列e)

不管是黑名单仍是白名单,再直接点就是直接攻击.htaccess 文件,在PHP manual 中提到了下面一段话
move_uploaded_file section, there is a warning which states ‘If the destination file already exists, it will be overwritten.’
若是PHP 安全没配置好就能够经过move_uploaded_file 函数把本身写的.htaccess 文件覆盖掉服务上的这样就能任意定义解析名单了。

4 服务端验证绕过(文件完整性检测)

(1)文件头检测

80fc80186b63f62406b8274b8744ebf8184ca381

(2)文件大小及相关信息检测

经常使用的就是getimagesize()函数只须要把文件头部分伪造好就ok 了,就是在幻数的基础上还加了一些文件信息有点像下面的结构
GIF89a(…some binary data…)<?php phpinfo(); ?>(… skipping the rest of binary data …)

(3)文件加载检测

该方法是比较变态的检测方法,通常是调用API函数去进行文件加载测试,常见的是文件渲染测试,再变态是二次渲染。针对这种类型,通常是进行渲染测试绕过,或者攻击加载器自己。

a. 渲染测试绕过

先用GIMP 对一张图片进行代码注入用winhex 看数据能够分析出这类工具的原理是在不破坏文件自己的渲染状况下找一个空白区进行填充代码通常是图片的注释区对于渲染测试基本上都能绕过。

加载中...

b. 但若是碰到变态的二次渲染基本上就无法绕过了,估计就只能对文件加载器进行攻击了,好比上传文件前,文件的数据以下。

a6e40bebe6cd7b8994a524cb0f2442a7db330ea4

而后上传这个jpg 但把它从新下载回本地发现了奇怪的地方

4719d8dc7b899e510447245c42a7d933ca950da4

上传后图片被二次渲染过新的JPG 图片内容里含有这个 CREATOR: gd-jpeg v1.0 (using IJG JPEG v62) 貌似是调用的GD php 的gd 库。

通常进行过二次渲染再想绕过我的经验是几乎不可能了。若是要对文件加载器进行攻击,常见的就是溢出攻击,上传本身的恶意文件后,服务上的文件加载器进行加载测试时,被触发攻击执行shellcode好比access/mdb 溢出你们能够参考下 http://lcx.cc/?FoxNews=1542.html。

4 各类攻击方式的相互关系及组合

首先客户端端验证和服务端验证是相互独立的,因此分开绕过就好了,主要难点是在服务端验证的组合上。

文件完整性检测已经包含文件头检测和图像大小及相关信息检测,但不包含文件扩展名检测。它是以加载来做为检测的方式,好比用图像渲染函数去渲染一张图片。文件扩展名检测和文件头检测都是同级的,相互独立,因此若是是文件扩展名+文件头检测能够同时分开绕过。

5 图像代码注入后的攻击

代码注入到图片中,若是没法正常解析,也没法执行。

你们能够参考下http://hi.baidu.com/hackercasper/blog/item/38aa658ee1ca00f6f11f3649.html
常见的是结合LocalFileInclude 漏洞来解析咱们的图片
(RemoteFileInclude 和RemoteCodeExecution 在这里就有点大才小用了哈)

好比某个站有这样一个URL
www.website.com/view.php?page=contact.php
咱们替换contact.php 为../
www.website.com/view.php?page=../
获得一个报错
Warning: include(../) [function.include]: failed to open stream: No such file or directory in
/home/sirgod/public_html/website.com/view.php on line 1337就说明存在LFI 漏洞,这个时候找到咱们的图片文件路径用一句话client 去链接www.website.com/view.php?page=../upload/help.jpg就能够成功的获得shell 了还有像nginx(php-fpm)解析漏洞,也能够直接解析图片里的代码因此你们要了解哪些环境下才能对图片里的代码进行解析这样才能结合上传绕过最后获得webshell 

相关文章
相关标签/搜索