【Web安全】文件上传下载安全测试的全面剖析与实践指南
文章目录
- 1 概述
- 文件上传安全测试的重要性
- 文件上传安全测试的基本流程
- 2 用例分析
- 2.1 文件上传跨目录漏洞测试
- 原理说明
- 测试方法
- 预期结果
- 实际应用与风险
- 2.2 压缩文件上传跨目录漏洞测试
- 原理说明
- 测试方法
- 预期结果
- 防范措施与建议
- 2.3 客户端判断文件类型测试
- 原理说明
- 测试方法
- 预期结果
- 正确的文件类型判断方式
- 2.4 绕过服务端对 http request 包 MIME 类型的检测(conteng - type)
- 原理说明
- 测试方法
- 预期结果
- MIME 类型检测的局限性与改进
- 2.5 服务端文件扩展名检测相关测试
- 2.5.1 服务端扩展名列表绕过测试
- 原理说明
- 测试方法
- 预期结果
- 2.5.2 文件名大小写绕过测试
- 原理说明
- 测试方法
- 预期结果
- 2.5.3 文件名截断绕过测试
- 原理说明
- 测试方法
- 预期结果
- 2.5.4 服务端文件扩展名检测的最佳实践
- 2.6 其他文件上传安全测试用例
- 上传压缩的大文件系统负载测试
- 限制上传文件大小测试
- 上传文件自动重命名测试
- 上传接口权限控制与日志相关测试
- 3 文件上传安全测试工具
- Burpsuite
- Ultraedit
- 4 文件上传安全测试的注意事项
- 测试环境的选择
- 测试的全面性
- 5 结论
1 概述
文件上传功能是用户将本地文件传输到服务器的过程。由于用户上传的文件内容和类型无法完全预知,这就给攻击者提供了可乘之机。攻击者可能会尝试上传恶意文件,如木马、病毒、Webshell 等,以获取服务器的控制权或者破坏服务器的正常运行。因此,文件上传安全测试的主要目标就是发现并修复这些潜在的安全漏洞,确保只有合法的文件能够被上传到服务器。
文件上传安全测试的重要性
- 保护服务器安全:防止恶意文件上传到服务器,避免服务器被攻击、数据被窃取或篡改。
- 保障业务正常运行:确保上传的文件不会影响应用程序的正常功能,避免因文件类型或内容不当导致的系统崩溃或错误。
- 符合安全合规要求:满足行业和法规对数据安全和隐私保护的要求,避免因安全漏洞导致的法律风险。
文件上传安全测试的基本流程
- 确定测试范围:明确需要测试的 Web 应用程序及其文件上传功能,包括上传页面、接口等。
- 收集信息:了解应用程序允许上传的文件类型、大小限制、存储路径等相关信息。
- 设计测试用例:根据可能存在的安全漏洞类型,设计相应的测试用例,如跨目录上传、文件类型绕过、文件大小限制绕过等。
- 执行测试:使用合适的测试工具,按照测试用例进行测试,并记录测试结果。
- 分析结果:对测试结果进行分析,确定是否存在安全漏洞,并评估漏洞的严重程度。
- 报告与修复:将测试结果整理成报告,提交给开发团队进行修复,并跟踪修复情况。
2 用例分析
2.1 文件上传跨目录漏洞测试
原理说明
如果存在任意文件上传漏洞,攻击者就可以将木马软件上传到服务器,进而获取服务器 ROOT 权限。通过相对路径访问方式可以上传文件至多个目录。这种漏洞的存在是因为应用程序在处理上传文件的路径时没有进行严格的校验,允许用户通过特殊的路径表示(如“…/”)来改变文件的上传位置。
测试方法
- 测试准备:确保 Web 业务运行正常,且待测网站存在文件上传功能。开启 Burpsuite 代理工具,设置抓包。
- 选择文件上传:登陆网站,打开文件上传页面,选择本地一个符合上传规则的文件,确认上传。
- 抓包修改路径:使用 Burpsuite 抓包获取完整的上传相关操作的请求消息(如 upload,import,filestatus 等)。在请求消息中,将带有上传文件名或者目录参数修改为“…/…/…/…/…/…/…/…/…/…/opt/export_1501638087706.xlsx”(注意回退目录要确保能到/opt,可与开发确认上传目录)。
- 检查服务器目录:登陆到服务器后台,查看/opt 目录。
- 多种路径形式测试:重复步骤 3,修改“…/”分别为“…\”、“%2e%2e%2f”、“%2e%2e/”、“…%2f”、“%2e%2e%5c”(“…\”的转义形式)、“…/”、“.\./”、“…/”等形式,再次查看/opt 目录。
预期结果
后台无上传的文件,且接口的响应消息中,不能包含文件上传的绝对路径信息。如果在两个及以上目录中存在 upload.sh 文件,说明存在此漏洞。
实际应用与风险
在实际的 Web 应用开发中,很多开发人员可能会忽略对上传文件路径的严格校验。一旦这种漏洞被攻击者利用,他们可以将恶意文件上传到系统的关键目录,如系统配置目录、可执行文件目录等,从而对服务器的安全造成严重威胁。例如,攻击者可以上传一个 Webshell 文件到 Web 应用的根目录,然后通过浏览器访问该文件,获取服务器的命令执行权限,进而窃取数据、篡改网站内容或者植入恶意软件。
2.2 压缩文件上传跨目录漏洞测试
原理说明
许多应用系统都允许上传压缩文件(如 rar、zip),并且有限制上传的压缩文件的大小,但没有对压缩文件里的文件类型进行校验,同时对文件解压的路径没有限制,导致攻击者可以改变上传路径并上传 Webshell。这种漏洞的根源在于应用程序在处理压缩文件时过于信任文件的内容和结构,没有对解压后的文件进行严格的检查和限制。
测试方法
- 测试准备:确保 Web 业务运行正常,且待测网站支持上传压缩包文件。
- 构造恶意压缩文件:构造一个压缩文件,压缩文件中包含系统不允许上传的文件类型,例如 jsp。
- 第一次上传测试:在文件上传页面上传该压缩包,并在后台检查对应的文件。
- 构造跨目录压缩文件:准备一个 Webshell,扩展名为 txt(文件名随意,但长度必须和要上传的路径的长度一致),将此 txt 文件进行压缩。用 ultraedit 修改压缩文件的路径(注意使用 16 进制模式,手工输入路径,如“…/…/…/…/…/test.jsp”,不能复制拷贝),最后保存上传。
- 第二次上传测试:在后台检查对应的文件。
预期结果
如果在对应目录检查到了解压缩后的 jsp 文件,说明存在漏洞。
防范措施与建议
为了防范这种漏洞,应用程序应该在上传压缩文件时,对压缩文件的内容进行预检查,确保其中不包含恶意文件类型。同时,在解压压缩文件时,应该指定固定的解压路径,并对解压后的文件进行严格的权限控制和类型检查。此外,还可以限制压缩文件的压缩比,防止攻击者利用高压缩比的文件进行拒绝服务攻击。
2.3 客户端判断文件类型测试
原理说明
在安全领域有这样一句话“永远不要相信用户的输入”。简单的通过客户端脚本验证,是完全不能保证应用安全的。用户可以通过禁用客户端脚本、自己构造无验证的表单、HTTP 数据包代理工具等方法绕过客户端检测。这种漏洞的存在是因为客户端验证容易被绕过,攻击者可以直接修改 HTTP 请求来上传恶意文件。
测试方法
- 测试准备:确保 Web 业务运行正常,且待测网站存在文件上传页面。
- 上传非法文件:在 uTraffic 上传功能页面,上传非法的传脚本文件,如 aaa.jsp。
- 拦截请求并修改:如果提示不允许上传 jsp 文件,启动 burpsuite 代理,拦截上传的请求消息(如 upload)。将脚本文件 aaa.jsp 修改为功能支持的合法文件,如 aaa.xls 文件,然后进行上传。再次拦截消息并将文件名再修改为 aaa.jsp 文件,继续上传,查看是否上传成功。
预期结果
如果上传成功说明文件类型仅在客户端判断,存在问题。
正确的文件类型判断方式
文件类型判断应该在客户端和服务器端同时进行。客户端验证可以提供友好的用户提示,减少无效的上传请求;而服务器端验证则是保障安全的最后一道防线,必须对上传文件的真实类型进行严格检查。服务器端可以通过文件的扩展名、文件头信息以及文件内容的解析等多种方式来确定文件的真实类型。
2.4 绕过服务端对 http request 包 MIME 类型的检测(conteng - type)
原理说明
多用途互联网邮件扩展(MIME,Multipurpose Internet Mail Extensions)是一个互联网标准,它扩展了电子邮件标准,使其能够支持非 ASCII 字符、二进制格式附件等多种格式的邮件消息。在 HTTP 协议中也使用了 MIME 的框架。MIME 的 Content - type 字段用来指定消息的类型。某些 WEB 应用在服务器端会对上传文件的 MIME 类型进行判断,但只通过修改 HTTP 数据包的 MIME 类型就能轻松绕过这种验证,无法保证服务器的安全性。
测试方法
- 测试准备:确保 Web 业务运行正常,且待测网站存在文件上传页面。打开上传页面,将 burpsuite 工具设置为拦截状态。
- 上传非法文件并抓包:直接上传一个非法的.jsp 文件,点击上传按钮之后,数据包代理工具截获到数据包。
- 修改 MIME 类型:将 Content - Type 部分的值由 text/plain 修改为 Content - Type: application/vnd.openxmlformats - officedocument.spreadsheetml.sheet(假如 excel 为合法格式,基于产品的实际情况来给出)或其他合法的格式。
- 查看服务器响应:放开拦截,查看服务器返回的信息。
预期结果
如果返回成功信息,说明服务器端是仅仅通过检测文件的 MIME 类型作为安全手段,存在安全问题。
MIME 类型检测的局限性与改进
MIME 类型检测虽然是一种常见的文件类型验证方式,但它存在一定的局限性。攻击者可以通过修改 HTTP 请求中的 MIME 类型字段来绕过检测。为了提高安全性,服务器端应该结合文件扩展名、文件头信息等多种方式进行综合判断。同时,还可以对上传文件进行进一步的内容分析,以确保文件的真实类型符合要求。
2.5 服务端文件扩展名检测相关测试
2.5.1 服务端扩展名列表绕过测试
原理说明
文件扩展名代表了文件的格式,也决定了服务器将如何解析该文件。目前,针对文件扩名的检测方式主要分为黑名单检测与白名单检测。对于黑名单检测,有时黑名单不够全面,只考虑到了部分可知性脚本。这时,攻击者可以通过上传黑名单中没有的文件格式进行攻击,比如上传 asa/ces 之类的文件。
测试方法
- 测试准备:确保 Web 业务运行正常,且待测网站存在文件上传页面。
- 上传合法文件并抓包:在浏览器中打开网站的上传页面,先上传合法后缀格式的文件,比如 a.xls。通过 burpsuite 拦截上传的请求消息。
- 修改后缀并上传:修改文件后缀为不合法的后缀,比如 a.jsp,重新上传。重复上述步骤,修改文件后缀为 jsp~,即新文件为 a.jsp~,重新上传。
预期结果
应用程序应提示所上传文件格式不合法。如果不出现警告框,表明该应用程序检测文件扩展名的黑名单不完整,遗漏了 asa 格式。
2.5.2 文件名大小写绕过测试
原理说明
对于黑名单检测,黑名单中限制了 asp/php 等扩展名,攻击者可以通过修改后缀为 ASP/Php 来绕过。
测试方法
- 测试准备:确保 Web 业务运行正常,且待测网站存在文件上传页面。
- 上传并修改后缀:在浏览器中打开网站的上传页面,先上传合法后缀格式的文件,比如 a.xls。通过 burpsuite 拦截消息,修改文件后缀为 ASP 或 JSP,即新文件为 a.ASP 或者 a.JSP,重新上传。
预期结果
应用程序弹出警告框提示所上传文件格式不合法。如果不出现警告框,表明该应用程序对上传文件的扩展名大小写敏感,容易被绕过。
2.5.3 文件名截断绕过测试
原理说明
在扩展名检测这一块目前只遇到过 asp 的程序有这种漏洞。例如给个简单的伪代码:name = getname(http request)(假如这时候获取到的文件名是 test.asp.jpg(asp 后面为 0x00)),type = gettype(name)(而在 gettype()函数里处理方式是从后往前扫描扩展名,所以判断为 jpg),if (type == jpg) SaveFileToPath(UploadPath.name, name)(但在这里却是以 0x00 作为文件名截断,最后以 test.asp 存入路径里)。
测试方法
- 测试准备:确保 Web 业务运行正常,且待测网站存在文件上传页面。
- 上传非法文件测试:先上传非法格式的文件,比如 a.jsp,应用程序应弹出警告框提示所上传文件格式不合法,否则有问题。
- 修改后缀并上传:重新上传该文件,在 Burpsuite 中修改文件后缀为 jsp%00%0d%0a0.xls(假设 xls 为程序支持上传的合法文件类型),即新文件为 a.jsp%00%0d%0a0.xls。
- 检查操作日志:检查操作日志。
- 多种后缀修改测试:重复第 3 步操作,在 Burpsuite 中修改文件后缀为 a.jsp.ttt 或者 a.jsp/a.xls 或者 a.jsp;.xls 进行测试。
预期结果
应用程序会弹出警告框提示所上传文件格式不合法,操作日志中记录上传失败的日志信息,上传失败。
2.5.4 服务端文件扩展名检测的最佳实践
服务端应该采用白名单检测的方式,明确规定允许上传的文件扩展名,而不是仅仅依赖黑名单。同时,对文件扩展名的检测应该不区分大小写,并且要防止文件名截断绕过的情况。可以对文件名进行规范化处理,去除特殊字符和非法的路径表示,确保文件扩展名的检测准确可靠。
2.6 其他文件上传安全测试用例
上传压缩的大文件系统负载测试
许多应用系统都允许上传压缩文件(如 rar、zip),并且有限制上传的压缩文件的大小。攻击者可以制作一个高压缩比 1000 的压缩文件,把几 G 的文件压缩成几 M,这样就不超过系统限制的大小,并且在后台对该文件进行解压时会对 CPU、内存、磁盘造成巨大压力,有可能会造成拒绝服务攻击。
测试方法是在浏览器中打开网站的上传页面,上传一个大压缩比的文件(如 dd if=/dev/zero count=$((1024*1024)) bs=4096 | zip -9 big.zip -),观察服务器上传、解压文件时的 CPU、内存占用变化。预期结果是系统的 cpu 和内存占用正常,且页面操作无卡顿和无响应的情况。
限制上传文件大小测试
检查文件上传是否限制文件大小。测试方法是查看文件允许的上传类型,例如允许上传.xls、txt、xml 类型。先选择上传合法大小的文件,通过 burpsuite 拦截请求消息,修改为超过合法大小的文件,然后上传。
预期结果是如果上传成功,说明存在问题。同时要关注后台对文件大小的校验,如果前台做了大小限制,而且通过 burpsuite 无法修改大小,则需要和开发确认后台是否做了大小校验,可通过修改代码,去掉前台的大小限制,然后验证后台对文件大小的校验。
上传文件自动重命名测试
测试文件上传是否对上传的文件自动重命名。测试方法是找到上传文件的功能点,上传合法的文件,例如 test.xls。用 burpsuite 记录文件上传的请求消息,并检查消息的响应。登陆后台服务器,用命令 find / -name test.xls 搜索 test.xls 文件。
预期结果是文件上传的请求和响应消息中,无后台存储的路径信息。文件上传到服务器后,如果保存的位置在 Web 目录下,并且文件名称没有改变,说明存在问题。文件上传到服务器后,如果需要保存在 Web 目录,需要对文件进行重命名,例如 201421399002633.jpg(可以使用时间 + 复杂的随机值)。
上传接口权限控制与日志相关测试
检测上传的用户权限,上传操作要有详细的日志记录。测试方法是先使用具有上传权限的用户上传合法文件,使用 burpsuite 工具截取上传操作过程涉及的接口信息。使用无权限用户,不具有上传文件权限的用户登录,获取 session 和 roarand 信息,然后替换步骤一中的截获消息的 session 和 roarand 信息,尝试重新下发上传请求。注销步骤 1 登录的用户,重新下发记录的上传请求,查看响应结果。
3 文件上传安全测试工具
Burpsuite
Burpsuite 是一款广泛使用的 Web 应用程序安全测试工具,在文件上传安全测试中发挥着重要作用。它可以拦截、修改和重放 HTTP 请求,帮助测试人员模拟各种攻击场景。例如,在上述的文件上传安全测试用例中,几乎所有的测试都使用了 Burpsuite 来拦截和修改上传请求,以达到测试安全漏洞的目的。
Ultraedit
Ultraedit 是一款功能强大的文本编辑器,在处理压缩文件上传跨目录漏洞测试时,可以用来以 16 进制模式修改压缩文件的路径。通过手工输入路径信息,测试人员可以构造出特殊的压缩文件,用于测试应用程序在解压压缩文件时是否存在路径控制漏洞。
4 文件上传安全测试的注意事项
测试环境的选择
在进行文件上传安全测试时,应该选择与生产环境尽可能相似的测试环境。这样可以确保测试结果的准确性和可靠性。同时,要注意在测试环境中进行充分的备份,以防止测试过程中对数据造成不可逆的损坏。
测试的全面性
文件上传安全测试应该覆盖所有可能的安全漏洞类型,并且要对不同的文件类型、上传方式和用户权限进行全面测试。不能仅仅依赖于已有的测试用例,要根据实际情况不断补充和完善测试用例。
5 结论
文件上传下载安全测试是保障 Web 应用程序安全的重要环节。通过对各种文件上传安全漏洞的深入分析和测试,可以有效地发现并修复潜在的安全问题,保护服务器和用户数据的安全。安全测试人员应该熟悉文件上传安全测试的流程、方法和工具,不断提高自己的测试技能和安全意识。
本文是「Web安全」系列内容,点击专栏导航查看全部内容。