1. 开篇碎语为什么“老掉牙”的上传漏洞值得重新拿出来聊看到“UEditor”这个名字一些做安全的朋友可能会不屑一顾这不是多少年前的组件了吗怎么还有人拿它做文章可我在最近的授权评估中确实又遇到了一个仍在生产环境运行的旧版UEditor而且问题几乎和首次公开披露时一模一样——远程抓图功能可以变成任意文件上传的通道。所谓“老洞新谈”不是说这个漏洞本身有了新变体而是它背后的信任边界问题在今天依然大量存在只是换了壳、换了框架、换了部署方式。UEditor是一款被广泛集成的开源富文本编辑器。它之所以特别是因为不少老系统的内容管理后台、论坛、电商平台都在用且很多系统在集成后就不再升级更不去关心编辑器内部那几个经典的HTTP接口。富文本编辑器的本质是“帮助用户把内容变成网页可展示的HTML”过程中必然涉及图片上传、附件上传、远程图片下载等复杂业务。业务复杂接口就多接口一多攻击面就大。任意文件上传只是其中一个结果它的根子在于编辑器需要处理的外部数据太多而开发者对“哪些数据可信、哪些数据绝不可信”的判断出了偏差。这篇文章我会按实战排查的角度来写先讲漏洞的成因再拆不同语言版本的表现差异然后还原一次授权测试中的排查思路最后给出修复和加固清单。无论你是安全测试人员、运维工程师还是维护着老系统的开发都值得花二十分钟读完排查一下自己负责的系统里有没有同类“老洞”。2. 任意文件上传的本质一个“下载图片”功能的信任链断裂2.1 帮用户“保存远程图片”本是常用功能富文本编辑器有个常见场景用户从其他网站上复制了一段带图片的HTML或者直接在编辑框里粘贴了某个图片链接。出于防盗链、图片访问速度、数据持久化的考虑系统往往需要把远程图片下载到自己的服务器上。于是编辑器提供了一个接口例如actiongetRemoteImage或者actioncatchimage前端把远程图片URL发给后端后端请求这个URL将图片内容保存到本地然后返回一个新的本地图片地址给前端。这个需求听起来简单但它有一个非常大的隐含假设编辑器后端必须像浏览器一样去“消费”一个外部URL。问题来了后端不是浏览器浏览器执行JS、渲染页面、加载图片攻击者很难让浏览器把任意文件下载到任意路径而后端接口一旦被攻击者利用就是一个高度可控的“下载机器人”。它能访问内网地址能把远程文件保存到本地还能决定保存后的文件名。2.2 实现里缺失的三重校验把远程图片保存到本地理想的实现至少要做三重检查第一URL来源是否符合预期是否允许任意外部域名第二下载返回的内容是否真的是图片比如检查Content-Type、文件头、图片尺寸第三保存后的文件名和扩展名是否可控是否可能生成脚本后缀。但很多老版本UEditor没有完整做这三件事。实际代码逻辑往往只做了零散的判断通过URL字符串中的扩展名来判断是否图片比如链接是http://xxx/a.jpg就认为是图片或只是简单地在白名单里比对扩展名。可URL字符串是人写的攻击者能造出各种后半截像图片可最终落盘却变成脚本的链接。同时文件内容完全没有被检查只要扩展名通过内容可以是一段攻击代码。再加上保存路径往往是由配置模板拼接文件名生成的一旦文件名带有多段后缀、特殊字符或可控目录片段就有机可乘。2.3 一句话理解漏洞本质把这段链路压缩成一句话远程URL不可信、下载内容不可信、保存文件名不可信但代码把所有输入当成了可信数据。任何人只要能调用这个接口就能让服务器替他去下载任意URL并可能把下载结果存成一个可执行文件最终造成远程代码执行。老版UEditor只是把这个漏洞暴露得比较明显而已今天很多自研系统里也藏着同样的模式——凡是“后端抓取外部资源”的功能都值得用这个思路重新审一遍。链路阶段预期做法缺陷做法远程URL校验限制协议、域名白名单、内网地址拦截任意URL直接请求内容类型校验检测文件头、图片解码只认URL后缀不验实际内容保存名生成服务端强制定名、随机名直接使用URL中的文件名并可被参数影响执行环境隔离上传目录禁止执行脚本上传目录与Web目录同权限3. 分版本剖析PHP、.NET、Java 的攻击面差异3.1 PHP版远程抓图接口与解析歧义叠加PHP版本暴露的接口常见路径是controller.php?actiongetRemoteImage参数source[]接收一个或多个远程图片URL。代码会把URL中的文件名作为保存文件名然后拼接配置好的图片保存路径。如果URL末尾带.jpg判断通过文件被下载并保存为xxx.jpg。问题出在哪一是文件名取自URL而URL可由攻击者完全控制比如构造一个末尾看起来像.jpg的链接实际通过特殊字符或路径编码绕过后缀校验二是下载文件内容不校验图片目录里可能混有PHP代码片段三是服务器解析歧义——某些Nginx配置会把.jpg文件交给PHP解析某些Apache多后缀解析会把x.php.jpg按PHP执行某些中间件在路径中存在特殊字符时会自动跳转或重写这都和部署环境强相关。实际操作中同一个接口在不同服务器上的利用难度差异很大但风险始终存在。3.2 .NET版历史问题最直观的一个版本.NET版本最常被提及的接口是controller.ashx?actioncatchimage。这个接口的历史实现中保存文件名的生成过程比PHP版更粗糙对远程URL携带的路径和扩展名有更大的信任。攻击者只要指向一个远程服务器上的恶意文件并控制好链接中的文件名部分就可能让UEditor将文件保存成可被Web访问和执行的脚本。这里要说明一点这不是说所有版本的.NET UEditor都一成不变地存在同一个洞毕竟后来源码也有过修复和加固。但现实中很多老系统跑的是十几年前的版本或者经过二开改了局部逻辑漏洞面并没有被真正关闭。我见过一个案例系统只做了“上传图片走UEditor、其他附件走自研接口”的改造却把UEditor的远程抓图接口完整暴露在公网这等于把一个可控下载器放在了未授权访问的位置。3.3 Java版相对收敛但仍存在SSRF风险Java版本在历史漏洞通报中不如PHP和.NET那么刺眼原因在于它在存储和扩展名校验上普遍做得更严格使用UUID随机文件名、强制图片格式校验、图片解码后再落盘。但这不代表Java版绝对安全。只要远程抓图接口存在就必然有SSRF问题——攻击者可以利用它探测内网端口、访问云元数据地址甚至把内网应用返回的HTML或JSON下载保存下来进行内容判断。SSRF和任意文件上传经常相伴而生。很多排查文章只关注“能不能传Shell”忽略了“能不能拿这个接口当跳板访问内网”。而实际的攻防评估中SSRF的杀伤力往往不亚于文件上传尤其是当后端数据库、缓存、管理后台都在内网且未做强认证时。如果内网应用本身还存在未授权访问这个看似只能下载图片的接口就能被用来读取内部接口返回的数据形成一次完整的间接攻击。版本经典入口历史上主要问题当前常见残留风险PHPactiongetRemoteImage文件名取URL、内容不校验、环境解析歧义直接下载恶意文件到可访问目录.NETactioncatchimage保存逻辑可控可生成可执行脚本未授权调用内网探测文件落地Java远程抓图接口已增强存储逻辑仍留SSRF内网探测、元数据读取4. 从防御视角还原一次排查过程4.1 搭建一个封闭的验证环境很多人可能一上来就想去线上系统直接测这很不专业。正确做法是先搭一个与实际环境接近的封闭实验环境。我验证时选择了一台与目标系统同版本的旧UEditor部署在包含Nginx和PHP的测试环境中前端模拟一个能调用远程图片下载的地点。需要准备的内容包括编辑器源码、一个测试入口页面、一个可控的外部HTTP服务端用来模拟攻击者服务器再准备几类测试文件——正常图片、文本文件、包含脚本代码的伪装图片。整个过程没有接触任何真实业务系统所有请求都在本地网络完成。搭建时需要注意版本一致性。很多老系统在新环境中部署会报错或自动禁用某些功能但在真实环境里却是完整可用的所以尽量以真实系统的复刻版为准。如果无法完全复刻至少复刻PHP、中间件、编辑器的版本组合这直接影响结论的有效性。4.2 构造测试用例观察真实响应在授权测试场景中我会从正常请求开始确保接口基线是通的。比如先在测试页面上传一张正常图片确认返回了包含路径的JSON和HTTP状态码。再尝试远程图片URL确认图片能被下载并保存。这一步成功说明远程下载功能是开放的。接下来才是关键测试把远程URL指向一个文本文件内容是一段无害的脚本代码。观察接口是否返回成功以及保存后的文件扩展名是什么。如果返回成功且文件实际是脚本内容基本可以确认“内容不校验”。再看保存路径信息如果把文件名和脚本后缀组合起来可被Web解析风险就升级为任意文件上传。我在测试过程中记录了三类结果接口返回成功文件被正常保存扩展名保持原样存在文件上传风险接口返回成功但扩展名被服务端强制改成随机字符串风险降级仍需关注SSRF接口拒绝非图片后缀风险较低但仍要确认是否可用其他绕过手法。4.3 结合日志与指纹定位线上问题如果是排查已上线的系统没有条件做实验环境那就要依靠日志和指纹特征来缩小确认范围。先从入口搜索带有ueditor或editor路径的访问记录、带有catchimage、getRemoteImage、uploadimage、uploadfile等action的请求。再看这些请求是否携带了异常的source[]或upfile参数有没有指向外部IP或域名的URL。一个实用的日志过滤规则类似下面这样(?i)(ueditor|editor).*(action(catchimage|getRemoteImage|uploadimage|uploadfile)) (?i)(action(catchimage|getRemoteImage)).*source\[\]https?:\/\/[^u]第一行用来拉出所有编辑器上传接口的请求第二行进一步筛选远程抓图类接口且source参数指向非本站域名的记录。如果日志中有大量此类请求说明接口正被外部探测甚至利用。进一步查看响应状态码如果返回类似{state:SUCCESS,url:...,source:...}的JSON结构就基本确认接口存在。日志特征说明路径含ueditor、editor关键字识别组件用途参数含actiongetRemoteImage或catchimage命中远程抓图接口存在source[]参数且值为外部URL触发下载逻辑的关键特征响应state字段为SUCCESS文件已成功保存风险确认保存路径中出现脚本后缀升级为任意文件上传风险这里要特别提醒线上排查时不要直接发送恶意payload只需通过一个公开可访问的测试文件或临时URL来验证响应特征足以支撑结论。确认后应立即通过安全流程通知相关方下线或防护不要继续扩大验证范围。5. 能落地的修复与加固清单5.1 第一优先级替换或升级组件如果系统还在使用旧版UEditor最彻底的做法是升级到官方维护的最新版本或者更直接一点——迁移到还在活跃维护的开源富文本编辑器。很多老版本已经停止支持安全补丁不再更新留着必然是风险。对于一时无法替换的系统至少要找到编辑器官方发布的补丁包确认远程下载接口是否增加了内容校验和扩展名白名单。补丁后还要做回归测试因为有的版本补丁只拦了其中一个接口另一个同名接口还是老逻辑。5.2 第二优先级源头加固上传目录无论版本新旧服务器层面的隔离都很关键。上传目录必须与代码执行目录分离上传图片放在独立目录通过配置文件禁止该目录解析PHP、JSP、ASPX等脚本。以Nginx为例可以对上传目录单独配置location ^~ /uploads/ { default_type application/octet-stream; location ~ \.(php|php5|phtml|asp|aspx|ashx|jsp)$ { deny all; } }这段配置的意思是所有以上传目录开头的URL不再默认按脚本执行只要遇到脚本后缀的请求直接拒绝。类似的思路也适用于Apache和Windows IIS。注意测试配置是否生效别只写了规则不重载。5.3 第三优先级网关层拦截异常请求如果WAF或反向代理在系统前面可以加上基于参数的规则。比如对所有编辑器接口要求source[]参数只能是本站域名的URL否则直接拒绝或者对source[]指向内网地址、云元数据地址的请求做拦截。网关规则只能作为临时双击手段不能替代组件升级。原因很简单编辑器代码绕过手法多规则更新永远追不上逻辑漏洞的变种。把网关当作第一道闸但最终的保险还是组件本身和存储层隔离。5.4 第四优先级改变功能设计重新审视业务远程图片下载这个功能真的需要保留吗如果只是给编辑内容做插图完全可以让用户先下载图片再本地上传或者由前端代理不让后端直接获取远程URL。如果确实需要后端抓图至少要做到限制URL协议为HTTP/HTTPS拦截内网网段、云元数据地址下载后必须验证Content-Type和图片魔数比如用图片解码库重新编码后保存文件名由服务端生成随机字符串扩展名使用白名单映射绝不使用URL中的文件名保存后使用独立域名或路径隔离禁止脚本执行。这些要求看起来基本但真正做到位的系统并不多。我见过不少系统只是把文件名改成了UUID但扩展名还是从URL尾部取的攻击者照样能通过URL控制扩展名。白名单映射才是关键只允许固定的几种图片扩展名并强制用图片处理函数生成最终文件。5.5 可持续的排查机制修复完成不代表一劳永逸建议把相关的指纹特征集成到安全监控平台里。定期扫描公网资产中暴露的编辑器路径出现新资产时自动检查是否存在远程抓图接口。代码上线前把上传和远程下载相关接口走一次安全评审重点就是本章节说的那三重校验。6. 一些个人的经验总结做安全评估做得久了你会发现一个规律真正危险的不一定是设计得复杂的功能而是那些看起来“只是下载一张图片”“只是上传一个附件”的简单功能。简单功能容易被忽视被绕过时也最难查因为开发根本不认为它会有问题。回到UEditor这个老洞它一次次被“重新发现”本质上不是漏洞代码本身有多精巧而是集成方的安全意识一直没跟上。很多系统上线时用的是最新版跑着跑着就成了老版本开发者知道要升级但担心升级影响现有编辑器功能就一直拖着。拖到漏洞被公开拖到被扫描器发现拖到应急响应时再临阵磨枪。我个人排查这类问题的习惯是先确认资产的暴露面再确认组件版本随后逐个检查下载类和上传类接口是否有完整校验没有条件搭实验环境时就靠日志特征来确认确认后先做网关拦截和目录隔离再排期彻底升级。整个过程不求快但求每一环都有记录、有验证。最后再分享一个实用小技巧验证编辑器是否存在任意文件上传风险时不必真的构造完整的攻击链只需要测试一个“非图片内容能否被保存为图片后缀文件”即可。如果返回SUCCESS但保存内容是非图片文件说明内容校验失效再结合保存路径能否访问风险等级很容易判断。高效、合规、低风险足够支撑你写出一份可信的排查报告。
