.NET 一条被忽视的路径：某文本编辑器老版本文件名设计缺陷实现文件上传

红队在一次渗透测试过程中，意外通过某编辑器 v1.3 的 ASPX 版本成功获得 WebShell 的全过程。值得一提的是，此次利用方式并非坊间广为流传的 v1.4 任意文件上传漏洞，而是一个较早版本中被忽视的逻辑问题。本文将从发现线索、漏洞分析、利用方法、环境限制等方面，逐步还原整个攻防思路，供红队朋友参考。

01. 实战分析思路

在进行渗透测试时，我们通过目录扫描发现存在编辑器的路径信息，进一步确认为 .NET 版本，并能访问 /net/ 相关目录。

作为一名有实战经验的渗透测试人员，看到这个路径的第一反应自然是尝试复现 v1.4 的上传漏洞，通过 imageManager 或 catchimage 的远程文件下载导致 RCE。然而尝试指定 URL 访问相关功能文件时，服务器返回 404，说明常见利用路径并不存在。

但一个疑问浮上心头：如果删除了 /net/controller.ashx 文件来防御已知漏洞，那么编辑器上传功能是否还能正常使用？

毕竟本身结构复杂，功能分发中心就是这个 controller.ashx 文件，贸然删除势必影响业务。因此我们怀疑可能存在残留上传点或其它被忽视的处理入口。为了验证猜想，我们下载了历史版本的源码进行比对。

发现 v1.3 的 .NET 版本使用的是离散上传文件结构，fileUp.ashx、imageUp.ashx、scrawlUp.ashx。

而 v1.4 后统一通过过controller.ashx 分发。这意味着，在老版本中，上传接口是多个独立的 .ashx 文件，并非单一入口。这一发现打开了新的攻击面。经手动审计 v1.3 源码中的 Uploader.cs 文件，我们发现上传逻辑存在两个关键点的疏漏，为绕过白名单与构造任意后缀写入文件创造了条件。

02. 绕过原理分析

源码中的 GetFileExt(string filename) 函数，用于提取上传文件的扩展名，其实现如下逻辑：

string[] temp = filename.Split('.');return"."+ temp[temp.Length -1];

简单来说，该函数就是以“.”为分割符，得到一个文件名信息的字符型数组，并获取数组最后一个值，在前面添加‘.’后作为后缀返回。

这里存在一个问题，如果所传的字符不存在点字符，文件名以点分割获取的数组只有一个值也是最后一个值，如，‘pdf’。该函数最后返回的值将是‘.pdf’。从而绕过白名单的检查。

另一个问题就是文件名的生成过程，文件名是随机生成的，但是随机生成的决定参数是前端fileNameFormat传入，格式是{filename}{rand:6}，最简单办法就是直接将该参数改为字符串，不会被正则匹配，直接拼接入文件名。

此时获取后缀的函数使用.net Path.GetExtension(filename)，这里只想说不知道开发是怎么想的，该函数获取pdf中后缀的值为空。所以最后保存的文件名只由format决定。

这里完成了对1.3 版本的分析，同时我也搭建了jsp、php本部的和v1.4的对应的三种语言的靶场，经查看，这几种均使用语言自带的获取后缀的函数。所以该利用方法也只能在v1.3的aspx环境下复现。

综上，老版本的市场占有率虽逐年减少，但在政企、学校、传统门户等系统中仍有一定存量，特别是在开发团队未做完整代码升级，仅简单删除漏洞文件的情况下，更容易留下类似的非预期漏洞点。

03.NET安全扩展学习

以上相关的知识点已收录于新书《.NET安全攻防指南》，全书共计25章，总计1010页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。

04. NET代码审计学习

微软的.NET技术广泛应用于全球企业级产品，包括其知名的Exchange、SharePoint等，国内如 某友的Cloud、某通的T系列、某蝶的云产品 等也广泛采用。各行业核心业务均依赖于此技术。这些基于.NET的系统频繁遭攻击，问题涵盖任意文件上传、反序列化漏洞、SQL注入、文件下载漏洞、命令执行漏洞等。