前言：
本篇文章是关于一次渗透测试中意外getshell的记录，属于ueditor v1.3.x 的aspx语言的非网上流传的getshell方式。由于当时在网上搜索并未发现该种getshell方法，故分享给各位。
经过：
起因是针对某客户网站进行渗透测试时，发现了一个ueditor编辑器路径，并且网站是aspx，经验丰富的渗透测试人员应该都已经想到网上广为流传的v1.4.3的那个远程文件加载绕过导致的getshell方式。起初，我也是第一反应去进行该尝试，但是网站回馈对应漏洞url404。在测试结束其他功能点后，再回过来看这个漏洞，我产生一个疑问，据我说知，ueditor是个由唯一入口文件ueditor etcontroller.ashx 进行请求分发。如果开发知识单纯得删除了漏洞文件，必然影响网站的正常使用。起于该思虑，我下载了v1.3.6版本的net源码，进行查看。
确认后了解，ueditor在1.4.x版本对整体设计架构进行改版，在v1.3.x,还是离散的功能文件存在的，上传功能在ueditor3
etfileUp.ashx。代码如下：
本意是对.net进行代码审计，发现是否存在安全漏洞（虽然通过搜索引擎并未找到这种信息），但是有意思的是在我审计出来之前，先前开启的burp的后缀fuzz已经有所发现。
框架使用的是白名单，并重命名，但是代码层面存在两点不足。
第一点是获取后缀的函数是自定义的，并且存在逻辑问题。这部分代码存在于ueditor3
etUploader.cs:190
简单来说，该函数就是以“.”为分割符，得到一个文件名信息的字符型数组，并获取数组最后一个值，在前面添加‘.’后作为后缀返回。这里存在一个问题，如果所传的字符不存在点字符，文件名以点分割获取的数组只有一个值也是最后一个值，如，‘pdf’。该函数最后返回的值将是‘.pdf’。从而绕过白名单的检查。
另一个问题就是文件名的生成过程，文件名是随机生成的，但是随机生成的决定参数是前端fileNameFormat传入，格式是{filename}{rand:6}，最简单办法就是直接将该参数改为字符串，不会被正则匹配，直接拼接入文件名。同时此时获取后缀的函数使用asp.net自带的获取后缀的方法Path.GetExtension(filename)，（这里只想说不知道开发是怎么想的），该函数获取pdf中后缀的值为空。所以最后保存的文件名只由format决定。
这里完成了对1.3.6版本的分析，同时我也搭建了jsp、php本部的和v1.4.3的ueditor对应的三种语言的靶场，经查看，这几种均使用语言自带的获取后缀的函数。所以该利用方法也只能在v1.3.x的aspx环境下复现。
总结
v1.3.x的市场覆盖率确实较1.4.3低了很多，希望能帮碰到该环境的老哥们多拿一个shell吧！如有，错误和不足之处，望多多斧正。