file-upload-and-ssrf

文件上传、SSRF 与反序列化（发现/利用 — 服务器输入处理）

概述

三类高影响问题，往往会导致 RCE 或云环境完全失陷；此前在参考资料中都没有专门归类：不可信的文件、不可信的URL和不可信的序列化对象。这三类问题的共同点是“服务器处理攻击者提供的数据”。

**核心原则：**只要服务器会获取、存储并提供或重建攻击者的数据，就要考虑这些数据还可以被指向何处，或被构造成什么。

适用情况 / 跳过情况

• 适用情况：应用接受文件上传、获取用户提供的 URL或对输入进行反序列化——分别测试这三类问题。
• **跳过情况：**某项功能不存在 → 对应部分不适用（例如，没有上传功能 → 跳过上传部分，但如果存在 SSRF/反序列化，仍应测试）。
• **如果不适用：**说明这三类问题中哪些不存在，并且只测试存在的部分。

⚠️ 授权

仅限你自己的环境或经授权的非生产环境。SSRF 可能触达真实内部基础设施和云凭证，因此目标应限于你的环境；使用无害的验证信标，不要越界测试。

文件上传

检查项	测试
类型/扩展名绕过	shell.php.jpg、双扩展名、空字节、大小写、.phtml/.svg/.htaccess
Content-Type 欺骗	真实图片字节 + 脚本；不匹配的 Content-Type 标头
多格式文件	文件同时是有效图片和脚本（例如 GIF/PHP）
路径遍历	文件名使用 ../../var/www/shell.php，控制文件存放位置
可执行位置	文件是否存放在可通过 Web 访问且可执行的目录中？
解析器攻击	恶意 SVG（XXE/XSS）、Office/ZIP（zip-slip、XXE）、图像库 CVE
限制	大小/速率限制；解压炸弹

关键成立条件是上传 → 可访问的可执行路径 → 执行。如果文件存储在 webroot 之外、使用随机名称且不可执行，大多数上传漏洞的危害就会大幅降低。

SSRF

• **入口：**URL 预览/展开、webhook、从 URL 导入、PDF/截图/图片获取、SSO 元数据、file:// 处理程序、服务端 HTTP 客户端。
• **要验证的目标（无害）：**先使用你控制的协作服务器/OOB 主机，然后是 127.0.0.1/内部地址，接着是云元数据 http://169.254.169.254/latest/meta-data/（AWS）、metadata.google.internal（GCP）。
• **要测试的绕过方式：**其他 IP 编码形式、[::1]、DNS 重绑定、重定向、@ 技巧、允许列表解析缺陷。
• SSRF→云元数据→IAM 凭证是值得演示的重点攻击链（参见 vulnerability-chaining）。

不安全的反序列化

• **入口：**不可信输入中的 pickle.loads、yaml.load、Java readObject、PHP unserialize、.NET BinaryFormatter、Node node-serialize。
• 检测：Cookie/参数/请求体中存在序列化数据块；篡改数据会改变服务器行为。
• 使用无害的 gadget（OOB ping）确认——不要运行破坏性 gadget 攻击链。

载荷及安全验证方法见 references/upload-ssrf-recipes.md。

输出

每项发现都应包含：入口、载荷、证据（文件执行的位置/OOB 命中/对象重建情况）以及可实现的影响（RCE、内部访问、云凭证）。严重程度通常为高至严重。

交接

这类问题经常是 vulnerability-chaining 中的立足点/跳板；使用 active-pentest 复现；通过 security-hardening 修复（将文件存储在 webroot 之外 + 验证内容 + 使用随机名称；URL 允许列表 + 屏蔽内部地址段 + IMDSv2；使用安全的反序列化格式）。

常见错误

• 只在客户端检查文件扩展名——应在服务器端验证内容。
• 未测试重定向、DNS 重绑定和 IP 编码绕过，就断言“不存在 SSRF”。
• 使用真实内部基础设施/生产环境测试 SSRF——测试范围应限于你的环境。
• 将反序列化视为理论问题——它是直接导致 RCE 的常见途径。