今天在 jellow 看到即友反馈在内嵌网页中打开苹果支持页时出现了唤醒其他应用的情况,有人分析是运营商注入劫持导致的,非常好奇这是怎么做到的。
苹果支持页应该已经全站 https 了,我理解 https 的内容运营商很难篡改吧,只要客户端进行证书校验,理应不会被注入,除非运营商已经逆天到伪造证书了。之前没搞过 webview 开发,是利用了 webview 的什么特性吗?
1
GDC 2020-03-06 16:25:29 +08:00
每一个微信浏览器打开的页面 都会被注入微信的脚本哦,包括 https 的。
毕竟人家主程序有网站控制整个 webview 的能力。 |
4
b821025551b 2020-03-06 16:30:53 +08:00
客户端被安装了其它根证书可以实现。
|
5
heiheidewo 2020-03-06 16:33:55 +08:00
UC 浏览器了解下
|
7
yongliu OP |
8
b821025551b 2020-03-06 16:46:18 +08:00
@yongliu #7 我说的是客户端信任了其他根证书,经常有一堆人去下各种描述文件,一顿信任下去。
|
9
yongliu OP @b821025551b #8 看下来我也比较怀疑是这个导致的
|
12
temporary 2020-03-06 17:00:33 +08:00
运营商劫持 dns 就可以吧
|
14
GDC 2020-03-06 17:07:29 +08:00
@yongliu 啊哈,有了新发现
请求一下 support.apple.com 响应的 header 中包括了一项 X-Cache: HIT from cache.51cdn.com 这个 51cdn 是网宿的域名,也就是说苹果这个页面被缓存在了网速的 cdn 服务器里, 也就说,多了一个投毒的可能性咯,至于网速会不会做这种事,可参考 /t/272022 这个帖子 |
15
keyfunc 2020-03-06 17:12:04 +08:00
Apple 的域名并不在 HSTS Preloading 的列表中,所以理论上用户访问 http 时运营商是有机会进行劫持的,因为存在 http 301 明文的阶段。
|
16
keyfunc 2020-03-06 17:16:38 +08:00
@GDC 我觉得 CDN 厂商是没胆子做这种事的,一般 CDN 投毒大多发生在 CDN 和 源站之间用 HTTP 传输数据。
|
17
yongliu OP |
18
tengyoubiao 2020-03-06 17:23:44 +08:00 via Android
黄即回来了?
|
19
yongliu OP @tengyoubiao #18 还是 jellow 小打小闹,黄即看起来是真黄了,都过去半年多了
|
20
virusdefender 2020-03-06 17:38:44 +08:00
cdn 回源的时候可能是 http 被劫持
|