前几个月我又到了一家安全领域比较有实力的公司实习，初来上海，很多事情要协调适应，还发现了一款超好用的笔记软件Obsidian（后面也出一期如何使用这个笔记软件），忙着从零构建那个本地笔记而暂时搁置了博客。最近对于实习期的工作已经开始游刃有余了，于是腾出一些时间，开始去思考SDL的建设，哈哈，也不知道算不算重回计算机梦的开始------软件开发方向。
这篇文章的创作思路是:
思考常见打点方式ing------>
想到文件上传与ssrf同时满足的条件------>
调取外部链接------>
思考如何去防御------>
结合ai网上学习搜索然后总结
一、明晰全部危害
核心风险点归类
- 服务端请求伪造 SSRF
- 恶意图片 / 伪装文件上传
- 内网探测、云元数据泄露
- 恶意外链钓鱼、恶意资源加载
二、完整梳理版
1. 业务场景
系统头像功能支持两种方式：
- 用户本地上传头像
- 用户输入外部 URL 链接，服务器拉取远程图片作为头像
2. 存在安全风险
- SSRF 漏洞：攻击者构造恶意 URL，让服务器访问内网地址、云元数据接口，探测内网服务、读取敏感信息。
- 内网端口扫描：遍历内网 IP + 端口，爆破 Redis、MySQL、SSH 等高危服务。
- 恶意文件伪装：伪装成图片的木马、脚本、HTML 钓鱼页面，被服务器下载存储。
- DNS 重绑定、IP 畸形绕过：绕过简单黑名单，解析到内网 IP。
- 重定向绕过：利用 301/302 跳转从公网跳转到内网。
- 超大文件 DoS、慢请求消耗服务器资源。
3. 整体防护架构分层
应用层校验 + 服务端中转拉取 + 沙箱隔离下载 + 安全对象存储 + 前端约束
三、解决方案
1. URL 基础严格校验（应用层）
- 协议白名单 ：仅允许
http/https，拦截file、gopher、dict、ftp等高危协议。 - 端口白名单 ：只放行 80 、443，拦截 22、3306、6379、8080 等敏感端口。
- 禁用自动重定向：关闭 3xx 自动跟随，防止跳转内网。
- 请求限制：超时 3~5 秒，限制单文件最大体积（如 5MB），防 DoS 和大文件攻击。
2. 域名与 IP 安全校验（防 SSRF 核心）
-
解析域名拿到真实 IP，不做简单字符串匹配。
-
拉黑禁止网段：
- 回环：127.0.0.0/8
- 内网：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16
- 云元数据：169.254.169.254、阿里云 100.100.x.x
-
封堵 IP 畸形格式、DNS 重绑定：解析一次固化 IP，不再二次解析。
3. 沙箱隔离下载
-
不直接在业务主服务器请求外部 URL；
-
独立部署安全沙箱节点 / 隔离容器做远程拉取；
-
沙箱特点：
- 无内网访问权限、仅可出公网 80/443
- 网络隔离、无业务敏感权限
- 下载环境只读、无持久化权限
-
作用：
即便被绕过、被恶意利用，也只能在沙箱内生效，无法渗透内网、无法攻陷业务主机。
4. 文件内容双重校验
- 校验 HTTP 响应头
Content-Type仅为合法图片类型； - 校验文件魔术字（文件头），防止后缀伪装、脚本伪装图片；
- 不符合直接丢弃、拦截保存。
5. 安全存储与资源管理
- 下载后不存业务本地 ，统一转存 OSS 对象存储；
- 服务端随机重命名文件名，禁止用户可控路径，防止路径遍历、文件覆盖；
- OSS 资源设置临时签名 URL、时效访问，防盗链、防恶意分发。
6. 前端辅助防护
- 前端正则先校验 URL 格式和协议，提前拦截非法输入；
- 前端不直接请求用户外链，全部走后端中转接口；
- 图片响应头配置
referrer-policy，防止内网信息泄露。
四、标准业务流程
用户输入头像（本地上传 / 外部 URL）
→ 应用层协议、端口、URL 格式校验
→ 解析 IP，拦截内网 / 回环 / 元数据地址
→ 交由独立沙箱环境安全拉取远程资源 //实在不行了才考虑
→ 校验响应类型 + 图片文件头合法性
→ 随机重命名，上传 OSS 对象存储
→ 前端返回 OSS 安全签名地址展示
→ 全程禁止前端直连用户外链、禁止服务器直连内网
五、总结
在渗透测试的常见打点场景中，"外部 URL 头像拉取" 是一个极易被忽视却风险极高的功能点 ------ 它同时叠加了SSRF 服务端请求伪造 与文件上传漏洞 的双重威胁，而一般可能只注意到了文件上传（也可能是我菜的原因哈哈）。
我感觉这个功能的核心风险在于 "服务器主动发起外网请求" ：攻击者可通过构造恶意 URL，触发 SSRF 探测内网资产、窃取云元数据；也可伪装恶意文件让服务器下载落地，形成变相文件上传；再配合 DNS 重绑定、30X 重定向等绕过手段，进一步放大攻击面，甚至引发服务器资源耗尽、违规内容传播等问题。
针对这类 "双重风险叠加" 的场景，防御不 能只靠单一规则，而需构建 "分层拦截 + 隔离防护" 的完整体系：从应用层的 URL 协议 / 端口白名单校验，到 IP 真实解析与风险网段拉黑，再到独立沙箱隔离远程拉取请求，最后通过文件双重校验、OSS 安全存储形成闭环。整个防护流程的核心思路是 "最小权限 + 风险隔离"------ 既严格限制外部请求的范围与权限，又通过沙箱、对象存储等手段切断攻击链路，避免恶意行为渗透到核心业务环境。
值得注意的是，本地上传 与外部 URL 拉取需分开防护：前者侧重后缀白名单、目录禁用脚本执行；后者聚焦 SSRF 拦截与远程资源安全校验。只有兼顾两类模式的风险特点，才能让头像上传功能既保留用户体验，又彻底堵死安全漏洞
任何 "服务器代用户发起请求" 或 "远程拉取资源" 的场景，都必须警惕 SSRF 与文件上传的叠加风险，通过 "源头校验 + 中间隔离 + 末端防护" 的三层架构，才能从根本上守住安全防线。