App内使用H5页面的一个安全问题

2017-11-15

最近研究北京交警办理进京证这个东西的时候,发现了一个关于H5页面的安全问题,想到公司的App内也有这种情况,觉得这个漏洞真是很简单,记录一下,让同事们后面开发的时候一定要注意了.

介绍一下北京交警App,这里面的大部分业务都是用HTML5写的,包括办理进京证的业务.这样干的好处就是灵活,调整起来比较快,开发成本估计也低;问题就是不安全,虽然都是HTTPS,自己拿电脑上charles一抓包底裤都让人扒干净了,各种逻辑一下看到了.最近 进京证办理是越来越麻烦,谷歌一搜,果然是有不少同行各种脚本攻击人家.我一直懒得研究,一方面是觉得精力放在这个上有点浪费;更重要的是,这东西就好比当年的12306一样,大家都守法买票的时候 官方也不会整太多手段来限制你;然后就总有自私的人,为了自己爽 拿各种工具搞人家,想自动办证,结果频率控制不对 加上人多,估计跟DDOS差不多,搞得正常的用户打不开卡的很.然后就是现在这样,官方生气了 好嘛大家都别用了,白天直接关闭了 谁来访问都是302跳到错误页面,这下大家开心了.

被逼无奈掏出Charles开始抓包,发现他们H5的模式基本上还是那样,研究了一下JS,加密就靠JS与App之间交互 靠App算出Sign后通过JS获取Sign.想想我司的App基本也是这个套路,看起来 拿App来加密的方案是很靠谱的,不反编译App你也拿不到我的算法,也没法搞我了.

继续研究,无意中想起Charles是可以改包的.翻了翻其他人的思路,就是这样了!拿Charles拦截掉H5和JS,把自己的JS插入进去返回给App,这样就相当于有了任意执行的漏洞了.通过这种方式用自己的JS去实现自动提交,不要太容易啊.

更重要的是,我根本不Care你的sign算法.如果App考虑的不周全没有过滤和验证,那么任意的接口Url通过JS发给App,都能获得对应的Token,这简直太Easy了,完全不需要反编译 你的App接口基本上就是裸奔的了.想想这个洞都好严重,有经验的基本上个把小时就搞定了,成本非常低.

给开发讲了一下这玩意的原理,至少先要弄个白名单了.后面在考虑一下,上HTTP/2应该也是个不错的选择,安全性能更好速度还能快一些了.