一次302劫持引发的血案

栏目: 后端 · 前端 · 发布时间: 5年前

内容简介:解决方法:换https。看标题来找解决方法的可以止步,下面内容只是想告诉你为什么会这样。302劫持在http中很常见,也称为DNS劫持。

解决方法:换https。

看标题来找解决方法的可以止步,下面内容只是想告诉你为什么会这样。

302劫持在http中很常见,也称为DNS劫持。

打开网站莫名其妙多了广告,下载apk莫名其妙下下来别的乱七八糟的安装包,原因就是访问 http://www.a.com时DNS服务器本应该返回a网站的ip,而在遭到DNS劫持后,会返回一个运营商中间服务器的ip,之后通过302重定向让用户访问到他们预设的目标ip。

但这里说的302劫持还没那么简单,如果不留意,可能还一直不会被发觉。

问题发现

事情是这样滴~~

某天,A更新了服务器最新渠道包,所以在应用打开时会弹框提示更新就像这样:

一次302劫持引发的血案

这个更新逻辑是这样的:

  1. 点击“立即升级”
  2. App内利用从RESTful API获取到的下载url,发起get请求进行文件下载
  3. 下载完成,调起apk安装界面进行安装

就这几步这么简单,然而就是这么简简单单的几步,慢慢发现还真不简单。

A发现App在服务器的渠道包已经更新到了7.0.5,但是刚刚更新完的App一打开又一次提示更新,这是什么鬼???

再去版本号一看,7.0.4,还真是没更新。。。

而且,诡异的是,原本是7.0.4_xm(小米应用商店)渠道的包,经过一轮(假)更新后,渠道标识变成了7.0.4_myapp(应用宝)渠道的包。

但这个不是必现,如果再按同样的流程更新一次,也就能更新到正确的最新的包了。

所以初步考虑是不是缓存相关导致的。

从RESTful API找起

初步怀疑是不是在请求RESTful API时,服务端对对应用户id的请求做了缓存,A的用户id在早些时候使用过myapp渠道的包请求过检查更新的接口,结果换成xm渠道包检查更新时拿到了缓存下来的myapp渠道的下载地址。

问题排查步骤及现象

  1. 跟后端对应api负责人沟通,获取对应id请求log
  2. 比对返回内容

从返回内容来看,返回是没问题的,下载地址也确实是正确的,

那么可以排除在RESTful API这个环节出问题的可能性。

再看所下载的文件

正常的文件命名为 gkfb_渠道名.apk ,比如小米渠道包升级文件是: gkfb_xm.apk

存放路径为手机根目录下的/download目录。

然后打开目录发现这种场景:

一次302劫持引发的血案

发现了莫名其妙命名文件名的安装包,命名为 com.zhouyue.Bee_7.0.5_190213.apk ,虽然知道是“包名 版本名 版本号.apk”这种格式,而且这些版本号信息都是正确的,但是奇怪的事情是,我们自己应用内更新是肯定不会这么命名的。

打断点调试

因为下载apk的逻辑是我们自己封装的,所以我们很清楚,文件名肯定是 gkfb_渠道名.apk 的形式,但为何通过我们封装的 工具 下载下来的文件出现 com.zhouyue.Bee_7.0.5_190213.apk 这种诡异的文件名?一时也没有答案,那就来打断点看看。

同样,先调试模式运行旧版本应用,之后应用会检查到更新,点击“立即升级”,然后在OKHttp的 RetryAndFollowUpInterceptor 中打下断点,得到以下信息:

一次302劫持引发的血案

可以看到这里进行了302重定向,一目了然。

抓包分析

其实上面断点已经可以证明这里进行了DNS劫持进行了302重定向,但实锤这种事情,终究还是要抓个包的。

这里利用Wireshark进行抓包,抓到如下信息:

一次302劫持引发的血案

可以看到在第14帧与负载均衡服务器三次握手建立TCP连接后,在第15帧发起http的get请求,并且在第19帧收到回复说302重定向,那么看一下第19帧的信息:

一次302劫持引发的血案

从具体信息可以看到Location到了 http://imtt.dd.qq.com/16891/3B08550828FFF5A92A3C95AE6E922A88.apk?fsname=com.zhouyue.Bee_7.0.5_190213.apk&csr=1242&_mark_heheda88=d73710c729d00d91908ce93644584bfb ,并且我们服务器并没有做这些事情,这就可以确定是传输过程中运营商做了手脚,在重定向后,在第20帧服务端就向客户端发起TCP断开连接的挥手过程了。

在之后就是运营商和某些黑产勾肩搭背的过程了。

关于缓存服务器,还可以从postman模拟中看出点端倪的,如下:

一次302劫持引发的血案

有兴趣可以了解下Disktank3。

因为是缓存服务器,存在一定的缓存命中性的问题,这就是为什么不是每一次都会发生劫持。

总结

其实302重定向劫持,或者叫DNS劫持是很常见的。但以前见到的大多都是你下载一个A.apk,下下来发现是一个B.apk,这就很明显你意识到被劫持了,当然也不会安装B.apk,但现在的做法就越来越鸡贼了,或者说醉翁之意不在酒,他目的不是为了推广B.apk,而是为了刷A.apk的渠道量。他会在中间节点解析出来你目标apk对应包名是什么,再来查找应用宝对应包名的apk来做缓存替换。

具体的劫持原理可以看看这篇文章(早上路上刚好刷到,正可以对这个问题的解释补充):

百度App网络深度优化系列《一》DNS优化


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

React Native:用JavaScript开发移动应用

React Native:用JavaScript开发移动应用

【美】Truong Hoang Dung(张皇容) / 奇舞团 / 电子工业出版社 / 2015-9 / 65.00

React Native是当前移动端开发中的优秀解决方案。《React Native:用JavaScript开发移动应用》围绕着如何将一个完整App提交到App Store,讲解了使用React Native开发iOS应用所涉及的方方面面。首先介绍了Flexbox布局,教大家从零开始搭建一个初始应用,以此阐明React Native的基础运行机理;然后介绍了Flux的设计思想,怎么理解和使用Pro......一起来看看 《React Native:用JavaScript开发移动应用》 这本书的介绍吧!

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

正则表达式在线测试
正则表达式在线测试

正则表达式在线测试