upload-labs通关（Pass-01~Pass-05）
目录
Pass-01
方法1：浏览器disable JS
方法2： burp抓包修改后缀
Pass-02
方法1：改Content-Type
方法 2：改文件后缀
Pass-03
Pass-04
Pass-05
开始之前，准备好burpsuite，浏览器配置好代理。
（还有一个必须知道的知识点）文件上传漏洞被利用需要两个前提条件：
1、文件能上传成功
2、攻击者能知道文件路径
凡是上传图片并显示的关卡，都有三种方式可以知道文件路径，这里先说一下，后面就不再每关赘述了：
1、最简单直接的，在没显示出来的图片上右键选择“复制图像链接”，可以得到文件的绝对路径，比如：
http://192.168.101.16/upload-labs/upload/sh.php
2、网页上右键选择“查看页面源代码”，源代码中显示文件的相对路径
3、如果是用burpsuite上传的文件，response报文中也会显示文件的相对路径。
下面就正式开始吧~~~
Pass-01
这关要求上传一个webshell，我选择了一个叫sh.php的文件并点击上传之后，跳出了一个弹框，提示当前文件类型不是允许上传的文件类型。
在burpsuite上proxy模块的http history中看了一下，并没有上传文件相关的报文，说明弹框时文件格式没有经过后端校验。
查看网页源代码，发现文件类型和弹框是由前端JS代码校验的。
这关至少有两种方法：浏览器disable JS，或者上传合法格式的文件，burp抓包并修改文件后缀为.php
方法1：浏览器disable JS
firefox可以安装一个叫Script Switch的插件，安装成功之后，就是下图右上角小红框里那个图标，使其处在JS disabled状态，上传sh.php。出现下图这样没加载成功的图片表示webshell已经上传成功。
到服务器上看看，上传成功的webshell在 upload-labs目录\upload 文件夹下
好了，先把服务器上的sh.php删掉，再来试试方法2。
方法2： burp抓包修改后缀
这个方法不如方法1方便呢，但是比较通用，而且不用安装插件或者扩展……
把攻击机上的sh.php改名为sh.png。
burp的proxy模块的intercept设置为on
选择sh.png并上传，这时burp的proxy模块可以抓到请求报文
将请求报文中 Content-Disposition头的filename从sh.png改为sh.php
然后一路forward，再去服务器上看看，就发现sh.php已经成功上传到服务器了。
Pass-02
试了试发现本关是后端过滤MIME，也有两种方法：第一种是上传php文件，改Content-Type，第二种是上传合法后缀文件，改文件后缀。
方法1：改Content-Type
上传sh.php文件，burpsuite的http history中找到如下报文
将其send to repeater，然后把Content-Type的值改为image/png
服务器上可以看到sh.php已经上传成功
方法 2：改文件后缀
攻击机上改sh.php为sh.png，burp的proxy模块的intercept打开，上传sh.png时抓到如下报文
修改filename的值为sh.php，一路forward
服务器上可以看到文件已经上传成功
代码分析：
从第10行可见，本关后端代码对上传的文件的Content-Type，也就是MIME进行了白名单校验。
事实证明，单纯对MIME校验对于文件上传攻击并没有什么用。
Pass-03
首先上传个sh.php，发现页面提示是”不允许上传……后缀文件“，并且burpsuite有抓到包，初步判断，这关可能是后端文件后缀黑名单过滤。
把burp的proxy模块抓到的本关文件上传的包send to intruder
把文件后缀设置为爆破点
payload写一些有可能被解析为php的文件后缀的字符，大小写绕过，双写绕过，一些利用操作系统特性（比如服务器是windows系统的话，结尾加点，加空格，加::$DATA，后缀某几个字母大写），web容器解析漏洞绕过黑名单的后缀……
start attack之后，结果用../upload过滤，可以发现很多后缀都上传成功了，但并不是每个上传成功的文件都有用（我用的后缀字典不是仅针对php的，所以还把jsp相关的也包含进来了，这边先忽略掉这些，仅考虑php相关后缀的）
上图的文件后缀是正常的，是有用的，用webshell管理工具连接的时候，文件名写202109252215097525.php就行，比如：
而下图这样后缀的文件，显然是没有用的
题外话：
1、我的服务器用的是phpstudy8，Apache版本是2.4.39，按照网上说的httpd.conf文件中增加
AddType application/x-httpd-php .php .phtml .phps .php3 .php5 .pht
之后，仍然不能把.phtml，.php3，.php5等文件解析为php代码，不知道是否是Apache版本太高了。
不过这个和文件上传黑名单绕过没啥关系，只是这里无法演示这些后缀文件作为php文件进行解析了。
2、本关无法使用.htaccess绕过，因为从上图可知，上传后的文件被重命名，而.htaccess必须是这个名字，是其他名字时是无效的。
3、这关虽然重命名了文件，但是仍然可以上传有效webshell的原因是，响应报文中给出了重命名后的文件名和路径。
代码分析：
代码的13~17行对文件扩展名进行了去末尾的点，转换为小写，去掉::$DATA，去掉空格的操作，然后与11行的后缀黑名单比较，后缀名在黑名单中则报错。
注意：
（1）trim和deldot函数可以删掉连续的多个空格和点，但str_ireplace函数只能替换掉一个::$DATA，因此本关可以文件末尾双写::$DATA绕过过滤
（2）trim函数仅仅是去掉空格，不能去掉空白字符。因此本关可以通过在sh.php文件名末尾加十六进制81~99（比如下图中加的是0x88）来绕过后缀黑名单限制。
（3）以上两种方法生成的文件在windows系统中不需要特殊配置就可以作为php文件解析，用webshell管理工具连接时，后缀名写.php即可。
Pass-04
这关上传了sh.php之后，只是提示这个文件不能上传。
把后缀改成png之后，可以上传成功。可以初步判断，本关不检查文件内容，检查点应该在Content-Type或者文件后缀，或者两者都有。
先看看Content-Type有无影响。把Content-Type从image/png改成application/octet-stream，发送之后，发现文件依然能上传成功，说明本关Content-Type无影响。
接下来判断一下文件后缀是黑名单过滤还是白名单过滤：
文件后缀改成.xxx，发送后发现文件上传成功，说明本关还是文件后缀黑名单过滤
那还是按照上一关的方法，对文件后缀进行爆破，爆破结果按../upload过滤，可以发现下面几个后缀是可以上传成功的。看了每一个后缀对应的Response报文之后发现，只有.php.awx和.htaccess是有启发性的。（双写php的上传后全都还是双写）
.php.awx上传成功可以联想到利用apache和nginx解析漏洞，但是我的phpstudy8提供的apache版本较高，没法演示apache解析漏洞；nginx解析漏洞尝试后也失败，由于找不到php-fpm.conf文件，只能作罢。
而说到.htaccess，从上图可知，本关上传后的文件并没有被改名，所以可以上传.htaccess文件。
关于.htaccess方法绕过文件上传黑名单过滤的具体方法，下面这个文章里面有详细描述：
【文件上传】.htaccess上传_redwand的博客-CSDN博客
简而言之，使用这种方法是需要满足一些环境条件的：
- apache服务器
- 能够上传.htaccess文件
- httpd.conf中AllowOverride All
- httpd.conf中有LoadModule rewrite_module modules/mod_rewrite.so
- 上传目录具有可执行权限
我在我的环境上尝试了，最终没有成功。但可以肯定的是.htaccess文件肯定是生效了，因为当.htaccess文件内容如下时，蚁剑不但连不上sh.png也连不上sh.php，去掉.htaccess文件文件后，蚁剑可以连上sh.php。
setHandler application/x-httpd-php
.htaccess文件的原理和 AddType应该是差不多的，所以这里我也怀疑是我的Apache版本比较高（2.4.39），才导致攻击不生效。
另一种方法：
burp的intruder模块中爆破文件后缀无法包括后缀以0x81~99结尾的情况，本关用这种方式绕过过滤上传webshell也是可以的，比如下图就是在sh.php文件名后加了0x88
上传到服务器后，文件被保存为sh.php
这是由于windows系统对于文件名的限制，当0x81~0x99放在文件名结尾时，不符合操作系统命名规范，字符会被自动去掉。文件名结尾的空格和点号也是同理。
本关代码也没啥好分析的，虽然用黑名单过滤了一大堆文件后缀，但是总有遗漏。
Pass-05
上传sh.php失败，提示“此文件类型不允许上传！”
burpsuite中将文件上传过程中抓到的包send to repeater，并修改filename为sh.xxx，发现上传成功，说明这关还是文件后缀黑名单过滤。
还是用上一关的方法，拿后缀字典爆破一下，用../upload过滤一下结果，发现下图几个后缀可以上传成功。
进一步考察返回的文件名发现，双写并没有被删掉一个，有可能上传webshell的后缀只有.php.awx和.ini，关于.php.awx上一关说了，不再赘述。稍微说一下.ini
关于用.user.ini文件绕过文件上传黑名单过滤的详细说明，可以看这个博文：
文件上传--.hatccess--.user.ini_野九的博客-CSDN博客
和使用.htaccess一样，使用.user.ini也要满足一些环境条件：
- 服务器脚本语言为PHP（和使用的web中间件无关）
- 服务器使用CGI／FastCGI模式
- php.ini中user_ini.filename = ".user.ini"，user_ini.cache_ttl =某个数
对比可见，使用.user.ini的条件比.htaccess宽松不少。但是我的环境上也没有尝试成功，因为我的环境没有使用CGI和FastCGI。
同样，本关也可以用上一关提到的文件名末尾加0x81~0x99的方法，是可以成功上传文件，并作为webshell使用的。
代码分析
其实也没啥可分析的，这关黑名单把.htaccess加上了，但是漏了.ini；并且之前说过的trim()只能去掉空格，不能去掉空白字符。所以上述提到的两种方法可行。
而由于和黑名单比较之前已经将后缀全部转化为小写，所以大小写绕过也是行不通的。
有意思的是，这关对::$DATA的处理和Pass-03是一样的，怎么这关就不能用双写::$DATA的方法过关呢？
我试了一下burp中将文件名改成sh.php::$DA::$DATATA，发送后提示“上传出错！”，从下面的代码可知，这表明其实已经绕过了黑名单过滤了。但为什么上传出错呢？
仔细看代码会发现是因为文件没有move成功，对比本关和Pass-03的代码可以发现，本关目标文件名是HTTP请求中的filename，而Pass-03目标文件名是随机数拼接处理后的文件后缀。在windows系统上尝试创建文件名为sh.php::$DA::$DATATA和sh.php::$DATA的文件可以发现，前者创建成功，后者创建失败。至此真相大白~