文件上传漏洞概述

最新推荐文章于 2025-01-15 11:33:36 发布

Siebel.

最新推荐文章于 2025-01-15 11:33:36 发布

阅读量869

点赞数 26

文章标签：安全

本文链接：https://blog.youkuaiyun.com/2302_80164634/article/details/143406241

版权

近期学弟们也学到了文件上传漏洞，写这篇，一方面是去辅导他们，一方面是自己复习，当初学的多少有点草率，难得有机会再次接触upload，应当好好过一遍，加深记忆-----

概述

**文件上传漏洞一般都是指“上传web脚本能够被服务器解析”的问题。**即==（webshell）==

完成文件上传漏洞的三个条件

上传的文件能够被web容器解释执行。文件上传后所在的目录要是web容器所覆盖的路径。
用户可以从web上访问这个文件，既然称之为漏洞，文件上传之后，必须能通过web访问，或者使web容器解释这个脚本。
如果上传文件被安全检查，格式化，图片压缩等功能改变了内容，则也可能导致攻击不成功

绕过文件上传检查

在对于文件上传的检查中，很多应用都是通过判断文件名后缀的方法来验证文件的安全性的，但，如果在攻击过程中，**手动修改上传过程的POST包，在文件名后添加一个%00字节，则可以截断某些函数对文件名的判断**

【因为在许多语言函数中，比如在C，php等语言的常用的常用字符串处理函数中，0x00被认为是终止符。受此影响的环境有web应用和一些服务器。比如应用原本只允许上传JPG图片，那么可以构造文件名（修改post包）为xxx.php[\0].jpg, 其中[\0]为16进制的0x00字符，.jpg绕过了应用的上传文件类型判断；但对于服务器端来说，此文件因为0字节的截断的关系，最终会变成xxx.php】-------

{0x00 / %00 字符串截断问题，一个被广泛用于字符串处理函数的保留字符}

除了检查后缀之外，有的工具会通过上传文件的文件头来验证文件的类型。

在这里插入图片描述

上面是一张JPG文件

正常来说，通过判断前10个字节，就可以判断出一个文件的真实类型。

正常来说，浏览器的 MIME Sniff功能实际上也是通过读取文件的前256个字节，来判断文件的类型的。

**因此，为了绕过应用中类似MIME Sniff 的功能，常见的攻击技巧是伪造一个合法的文件头，而将真实的PHP等脚本代码附在合法的文件头之后。**

此时我们仍然需要php来解释此图片文件才行。

如果上传文件后缀是.JPG,则web server很有可能会将此文件当做静态文件解析，而不会调用PHP解释器，攻击的条件无法满足。

*在文件上传漏洞的利用过程中，攻击者发现一些和web service本身特性相关的功能，如果加以利用，就会变成威力巨大的武器，这往往是因为应用的开发者没有深入理解web service的细节所导致的*

Apache文件解析问题

Apache对于文件名的解析是从后往前解析的，直到遇见一个Apache认识的文件类型为止。

eg：Phpshell.php.rar.rar.rar.rar.rar

因为Apache不认识.rar这个文件类型，所以会一直遍历后缀到.php，然后认为这是一个php类型的文件。

至于Apache怎么知道哪些文件是它所认识的，这些定义在了Apache的mime.types文件中。

正常我们考虑过程中，会容易将这件事扣帽子到web server上，认为这是它该干的事情，如果不考虑这些因素，写出的安全检查功能就可能会存在缺陷，比如.rar 是一个合法的上传需求，在应用里只判断文件的后缀是不是.rar，最终用户上传的是 phpshell.php.rar.rar.rar.rar,从而导致脚本被执行。

IIS文件解析问题

之前说过0x00字符截断文件名，在IIS和windows环境下曾经出现过非常类似的漏洞，不过截断字符变成了“  ； “。

当文件名为 abc.php;xx.jpg时，IIS 6会将文件解析成 asb.php,文件名被截断了，从而导致脚本被执行。

eg：http://www.target.com/path/xyz.php;abc.jpg

会执行xyz.php ，而不会管 abc.jpg

[ IIS6 中另一个漏洞——因为处理文件夹扩展名出错，导致将/*.asp/目录下的所有文件都作为ASP文件进行解析。比如：http://www.target.com/path/xyz.asp/abc.jpg 这个abc.jpg，会被当做ASP文件进行解析。

！！！注意这俩个IIS的漏洞，是需要在服务器的本地硬盘上确实存在这样的文件或者文件夹，若只是通过web应用映射出来的URL，则是无法被触发的 ]——不好理解这俩个漏洞（有好的形容或者解释希望师傅们留言）

这里多理解理解，多读几遍

IIS 中 不得不提到就是 支持PUT功能所导致的若干脚本问题。

PUT是在WebDav中定义的一个方法，WebDav所包含的PUT方法，允许用户上传文件到指定的路径下。

在许多的Web server中，默认是禁用PUT的，或者有着严格的限制，

**但在IIS中，如果目录支持写权限，同时开启了webDav，则会支持PUT方法，再结合MOVE方法，就能够将原本只允许上传文本文件改写为脚本文件，从而执行webshell。MOVE能否执行成功，取决于IIS服务器是否勾选了”脚本资源访问“ 复选框**

**一般进行此攻击过程，Attacker应先通过OPTIONS方法探测服务器支持的HTTP方法类型，如果支持PUT，则使用PUT上传一个指定的文本文件，最后通过MOVE改写成脚本文件。**

  1. 使用 OPTIONS 方法探测服务器支持的 HTTP 方法（Python 示例，使用requests库）

import requests

# 目标URL
target_url = "http://example.com"

# 发送OPTIONS请求
response = requests.options(target_url)
if 'PUT' in response.headers.get('Allow', ''):
    print("服务器支持PUT方法")
else:
    print("服务器不支持PUT方法，攻击无法继续")
    
2. 使用 PUT 上传指定文本文件（假设文本文件内容为test_content）

# 要上传的文件内容
file_content = "test_content"
# PUT请求的URL（这里假设是目标服务器上的某个路径）
put_url = target_url + "/uploaded_file.txt"

put_response = requests.put(put_url, data=file_content)
if put_response.status_code == 200 or put_response.status_code == 201:
    print("文件上传成功")
else:
    print(f"文件上传失败，状态码: {put_response.status_code}")
    
3. 使用 MOVE 方法将上传的文件改写成脚本文件（这里假设改写为.php脚本
# MOVE请求的URL，将文件重命名为脚本文件
move_url = target_url + "/uploaded_file.txt"
destination_url = target_url + "/uploaded_file.php"

headers = {'Destination': destination_url}
move_response = requests.request('MOVE', move_url, headers=headers)
if move_response.status_code == 200 or move_response.status_code == 201:
    print("文件重命名成功，可能创建了恶意脚本")
else:
    print(f"文件重命名失败，状态码: {move_response.status_code}")
    
    
下面对这段代码进行分析
1.概述
这段 Python 代码的目的是通过 HTTP 的 MOVE 请求来重命名服务器上的文件。它试图将一个已经存在的uploaded_file.txt文件重命名为uploaded_file.php，这可能是一种恶意行为，因为如果服务器对.php文件的处理存在漏洞，可能会导致安全问题。
2. 变量解释
move_url：这是源文件的 URL，它由目标服务器的基础 URL（target_url）和要重命名的文件名/uploaded_file.txt组成。这个 URL 指向要被移动（重命名）的文件在服务器上的当前位置。
destination_url：这是目标文件的 URL，它同样基于target_url，但文件名是/uploaded_file.php。这个 URL 指定了文件重命名后的新位置和新名称。
headers：这是一个包含 HTTP 请求头的字典。在这里，Destination头指定了文件重命名的目标 URL。在 HTTP 的 MOVE 操作中，这个头告诉服务器文件应该被移动到哪里。
3. requests.request函数调用
move_response = requests.request('MOVE', move_url, headers=headers)：
这里使用requests库的request函数发送一个 HTTP MOVE 请求。
'MOVE'是请求方法，它指示服务器执行文件移动（重命名）操作。
move_url是请求的源 URL，即当前文件的位置。
headers包含了Destination头，用于指定目标 URL。
4. 状态码检查
if move_response.status_code == 200 or move_response.status_code == 201:：
这段代码检查服务器返回的状态码。状态码 200 表示请求成功，状态码 201 表示资源已被创建（在这种情况下，可能意味着文件重命名操作成功执行）。
如果状态码是 200 或 201，就打印出文件重命名成功的消息，同时指出可能创建了恶意脚本，因为将文件重命名为.php可能会被利用来执行恶意代码。
如果状态码不是 200 或 201，就打印出文件重命名失败的消息，并显示服务器返回的状态码，这可以帮助排查问题。

**从攻击原理看，PUT方法造成的安全漏洞，都是由于服务器配置不当造成的。**

PHP CGI路径解析问题

利用上传文件钓鱼

钓鱼网站在传播时，会通过利用XSS，服务器端302跳转功能，从正常的网络跳转到钓鱼网站。

https://example - ecom.com/products/item - 123?redirect_url=https://example - ecom.com/out - of - stock - notice

redirect_url就是原网站中指定接收用户返回的页面地址。假设一个在线教育网站允许使用 QQ 登录，当用户点击 QQ 登录按钮后，会被转到 QQ 的认证页面，认证成功后，QQ 服务器会根据教育网站传递的redirect_url（如https://example - education.com/login/callback）
将用户重定向回教育网站的登录回调页面进行后续操作，比如创建或关联本地账号。
在支付流程中也有重要作用。当用户在电商网站完成购物并选择支付方式（如使用支付宝支付）后，电商网站会将用户重定向到支付宝的支付页面，同时传递一个redirect_url（如https://example - ecom.com/payment/result）。当用户完成支付操作后，支付宝会根据这个redirect_url将用户重定向回电商网站的支付结果页面

redirect_url（重定向网址）

但这种钓鱼，任然会在URL中暴露真实的钓鱼网站地址。

而利用文件上传功能，钓鱼者可以先将包含了html的文件（比如一张图片）上传到目标网站，然后通过传播这个url进行钓鱼，在url不会出现钓鱼地址，更具有欺骗性。

这里简单提一下，不做详细讲解了

总结

只要web容器无法解析该目录下的文件，即使攻击者上传了脚本文件，服务	器本身也不会受到影响，因此此点至关重要。

在实际中，文件在上传后悔放到独立的存储上，做静态文件处理，一方面加速（使用缓存），降低性能损耗；另一方面也杜绝了脚本执行的可能（不排除某些小的小应用，仍然可能存在）

判断文件类型

结合MIME Type，后缀检查等方式。在文件类型检查中，！！！建议白名单的方式，黑名单网上很多大佬的文章中和实际操作中，被无数次证明，不可靠，

此外，对于图片的处理，可以使用压缩函数或者resize函数，在处理图片的同时破坏图片中可能包含的HTML代码（逆着去操作会有什么样的结果呢？哈哈哈！！！）
使用随机数改写文件名和文件路劲

/**************************
单独设置文件服务器域名

靶场关卡讲解csdn，非本人所写，仅作参考，教程很多，多多查找