检测背景:学校直饮机 引入物联网设备,用户体验下降,用水费用反而升高几倍...虽然很不满..但是懒人又不愿意烧水喝,还是只能喝直饮机的水. 在使用的同时也对,此系统的架构产生一点点兴趣.....所以....
声明:非专业安全人士,,,仅仅一时xing起...
1.未采用https协议,利用charles简单抓包.
抓包过程
1.笔记本开启自带wifi,手机连上,开上charles.
2.打开手机端控制app...进行一系列操作,同时关注charles .
3.focus 饮水机控制app 发出的http链接
4.分析一系列http 头部报文
图一
分析结果
1.app内置多个host地址...估摸是防止其中某个服务挂掉 影响用户使用吧...
2.如图一所示 采用类似于jwt 协议认证 （不是jwt，下面会说）
(看到这里的时候 我就知道 基本上随便刷水的可能性不大了..因为估摸所有的接口都 要走验证拦截器.....除非进一步深究...)
3.通过不断登录获取新的token,发现token 构造有点小规律...前十位不变...估摸是什么跟用户相关的东西,,,虽然目前一点卵用都没有....
2.根据抓包host,访问管理端寻找入口
似乎通过抓包看不到什么....于是 想着去看看管理端的漏洞...
于是直接访问....host地址 跳转到 管理端接口....
分析前端代码 得出 也是一套前后端分离的模式
...然后下面就是对于前端代码的各种分析了..
图二
看到这里不免吐槽一下....原来这个平台还有这么多品牌的直饮机在用..所以外面的饮水机 套个牌子...租用一下别人的平台...水价 就翻翻翻翻上涨...?????
图三
根据图三 看到必要js路径资源...剩下的就是慢慢翻了..看看有没有什么可以利用的
图四
看到这里 就知道 原来 token的组成部分 果然如上面的猜测
图五
....终于看到了精华...文件上传接口...包括参数构造形式...于是....
3.postman测试文件上传接口.仅过滤用户权限,未过滤文件类型.
图六
虽然此处折腾了很久...但是还是顺利 成功构造成功...header中.auth中uid必须和form-data中uid 相同... 也并未测试上传文件能否正常解析...但是估摸静态资源文件
如题了....到了此步 为了避免fz.建立空文件.更改后缀上传 成功返回路径.....全程未获取任何目标计算机控制权.....
