前言
此次实战是参加某地攻防演练打点所遇，如有打码不严请勿复现，大佬勿喷。
实战经过
摸到一个某信息管理平台
开局一个登录框，那么尝试sql注入和弱口令爆破，从返回包中可以看出存在用户名枚举
尝试注入测试发现后端存在检测，试了几十个常见的测试手机号还无法枚举到用户名后，遂放弃此路
通过报错页面的信息，和url格式，我当时判断的是这是一个 java mvc模型的站点，也给后面埋了个坑
于是开始翻看静态资源，熟悉的文件名格式，确认过眼神，这是vue的资源
根据以往的经验，VUE项目的关键代码存在于生成的以app开头的js文件中，所以通常遇到vue项目的目标，只需翻看其app开头的js文件，即可通过其内容大致了解到它的功能点。
于是打开那个app开头的js文件，我个人是非常喜欢将js代码粘贴到Pycharm里面，然后按 Ctrl + Alt + L 来格式化代码，再慢慢的审阅寻找线索。
经过仔细的查看js代码，发现一处疑似后台主页的跳转url
直接粘贴至浏览器打开，进到了一个后台页面
在熟悉它里面的功能点时，发现这只是一个框架页面，跟后端交互获取数据时仍需要验证用户身份
于是我灵机一动，猜测 url的company_id提交的可能就是用户凭证，所以直接在Pycharm使用字符串查找功能查找，没想到真的找到了一串md5值，看起来像是凭证，大喜之后将其补上到url后再访问
获得了一个用户身份的后台（看右边的成员和部门那里已经与前面不同）
但继续摸功能点后，发现只是个测试用户的身份
找到一处上传点，但是上传过去发现没有数据包响应
于是查看浏览器控制台信息，发现是被同源策略给限制了，那么这里通过功能点直接上传是行不通的，除非你通过他的域名访问，我这里反查了ip查不到对应的域名
这个时候可以手动构造文件上传表单， 然后浏览器打开上传
发包过去之后，是我天真了
报了一个404回来，开始怀疑人生当中，不过后面想了想，我刚才访问的是82端口，提交上传的接口是8082端口，难不成这里面有问题？本着死磕到底的精神，我颤抖的手敲了敲键盘，在burp的重放功能那将8082端口改为了82端口，再尝试发包
回包果真不一样了，貌似是被后端接受了，但是却没有返回上传成功的文件路径，我怀疑是没有上传成功
于是掏出了我的大*，不对，是我的祖传字典，用于测试上传文件对象的键名
我晕，原来上传的文件对象键名就是 file
将文件字典键名改为file, 文件名改为 .jsp后缀再上传，成功上传了
于是赶紧上传个冰蝎的webshell,发现被拦了，难不成存在waf ？
那么先上传个打印字符串的短小代码，发现上传成功了也顺利访问了可是却不解析？？？
我尼玛直接怀疑人生，这不是tomcat应用服务器吗，怎么可能不解析jsp
后面在测试其他文件名时，
发现解析php，这就离谱，tomcat + php还有这种搭配？麻烦搞懂的朋友告诉我
蚁剑链接之，发现是 apache权限，内核3.10
其实这个时候通常都是上代理打内网的了，不过后面遇到了更诡异的事，我上传了frp 客户端做代理时，发现连接到服务端后几十秒就断了，再查看文件时，权限已经变成了 000
看来是应该有某种防护软件？这是块硬骨头啊
然后开始打算提权，一般提权通用性比较高的就是内核提权，但是不太建议这种提权方式，因为溢出类的内核提权都有一定的偶然性，容易把服务器打宕机
查看了下进程，很惊喜的发现python 以root权限运行了一个程序，有着django开发经验的我一眼就看出了这就是django,
然后访问其8000端口，是一个 swagger 接口页面。
这时随便访问个不存在的路由
通过报错信息得知这真的是django，并且开起了debug功能，开启后修改源代码会自动重启应用
心中大喜直接奔去寻找这个django项目的目录，很巧的是项目目录里的所有文件都具有777的权限，所以能改写视图函数，我添加了红框中的代码，大致意思就是当访问 test/ 路由时，返回字符串 “Hello Django”
再去浏览器访问 test 路由，成功执行了我自定义的视图函数
于是这时候 python 版的webshell就出来了
去查看执行效果，ok提权成功
当我开始漫游时，问题又出现了，应该是流量特征太明显被 waf 拦了
然后我又把视图函数改了下，添加base64编码传输
完美
随便几行代码写了个方便点的利用工具
本次外网打点到此结束
结论
渗透测试的本质就是信息收集加弱口令，只要足够细心就一定会有突破口，
防御对策
建议开发人员注意检查静态文件中是否包含凭证，服务运行权限尽量采取最小化原则。