图形用户界面

Firefox浏览器表单的butterfly加载阻塞

0
登录或者登记去做吧。

背景

一个礼拜前,在退款维权的业务中,发现这样一个问题: 在某些Firefox浏览器中,表单的butterfly加载阻塞导致功能异常了。

一开始,我们以为是即将发布的修改点导致的问题。

但再三确认本次的修改点后,确定只是改了文案啊! 这…

因此,我们首先怀疑是否线上已经有问题? 经过测试发现,果然,确实是个线上问题。

经过并不算麻烦的自测后,发现问题还不小:

影响范围:所有Firefox版本。
(注意:Firefox略有修复,但未完全解决:30.00+官方版Firefox浏览器; 原因是该版本携带有“附加组件管理器”1.2.3版本这个扩展)

chrome在一个月前也发现过类似问题,不过近期没有类似案例,可能已经在35中修复。

隐藏在Firefox中的Google:safebrowsing是如何工作的?


印象中,页面在Firefox中请求一个JS文件的过程,是这样的

图中看到了三个步骤:

  1. 页面向Firefox发起一个js的请求;
  2. Firefox判断是否为reload请求或者已在缓冲,if true直接读缓存,返回js文件给页面使用;if false则执行步骤3;
  3. 向阿里CDN请求,获取到js文件,返回js文件给页面使用,并且写入缓冲;

看起来没什么问题,太符合我们的认知了。

直到有一天,发现页面因为js加载阻塞导致页面功能严重受影响。

而且怎么强刷、清理缓存,都无果。

才发现….

原来,页面在Firefox中请求一个JS文件的真正过程,是这样的

这里演示下Google服务正常和异常两种情况:

一. Google服务正常时:

二. Google服务不正常时:

图中可以看到多了个本地哈希碰撞和向Google服务发送检测的过程,更多步骤描述如下:

  1. cdn返回js给Firefox后,Firefox先在本地safebrowsing哈希库中执行哈希碰撞;
  2. 碰撞结果为不通过的话,会向Google服务器(safebrowsing.google.com:443)发起检测通知,并进入等待状态;
  3. 此时,页面的直观感受就是js没有请求到,功能异常;
  4. 并且,如果再次请求同一个js文件,首先会查看safebrowsing等待队列;
  5. 如果已在safebrowsing等待队列中,则什么都不做。没错!什么都不做!(这就解释了,为什么强刷,甚至清理缓存后的强刷,都毫无作用)

似乎已经定位到了,问题了


第一: Firefox把我们的js判定为可疑文件(也就是哈希碰撞结果为可疑);
第二: Google服务被墙了, 哎~~

另外:

  1. safebrowsing会对所有静态资源执行哈希碰撞;
  2. 哈希碰撞,只针对静态资源的名称;(也就是说与js文件的文件内容无关)

于是,向Firefox的同学请求帮助


无辜的受害者: “为什么Firefox把我们的js认定为可疑文件?”

Firefox的解释是: “我也不知道为什么啊!”;

Firefox: “因为:Firefox浏览器会从Google下来一份safebrowsing哈希库,这个哈希库会对所有静态资源请求执行哈希碰撞。 因此,具体算法,Firefox方面,其实也是不知道的呢。”

无辜的受害者: “哦! 原来是被检查请求阻塞了呢?那要不你们添加一个阻塞行为的监控吧?”

Firefox: “对啊,对啊,在最新版本:30.00中,我们加了阻塞情况下,只进行本地检查的处理了, 你下载最新的版本就可以了。”

… 几个小时后 …

无辜的受害者: “我下更新到最新版本了,可还是不行呢? ”

Firefox: “要怪就怪gfw吧,为了伪造成是Google自己服务器的问题,而不是国内封锁,现在gfw对Google的封锁采用hold连接,不释放,不重置,一直不返回数据,造成现在火狐以为连接一直在等待数据”

无辜的受害人: “这….”, 尼玛,不是坑爹吗? “好的谢谢, 保持联系”。

因此,又抛出了两个新的问题:

  1. 为什么升级了Firefox还是在本地哈希碰撞中被fail了?
  2. 为什么Firefox已经添加了防阻塞处理,结果却还是被阻塞了?

问题的答案:

  1. Firefox升级是升级了,但是本地哈希库,并没有被更新(因为Google服务调不到啊~); 自测发现哈希库被保存在Firefox的应用程序中,而非个人配置目录中;
  2. Firefox添加了阻塞处理没错,但是gfw似乎做了一件奇葩的事情: gfw对Google的封锁采用hold连接,不释放,不重置,一直不返回数据,造成现在火狐以为连接一直在等待数据; 看来是Firefox的解决方案不够彻底啊;

最后的问题变成:

  1. Firefox没有处理到gfw对Google服务请求采取hold连接的情况;
  2. 没有得到能够让用户一次操作(如更新插件,更新浏览器)就能解决的方案,难以形成终极解决方案。

以后怎么办


首先:考虑到网络安全敏感问题,能拿到Google safebrowsing哈希库算法的可能性几乎不可能;尝试通过hash算法扫描本地代码库的思路不太可行。

看来:还是得靠Firefox那边,能够自己修复这个问题。 后续我们会持续跟进这一类的问题,并就这个问题跟Firefox方面保持反馈和测试结果的同步。

临时解决方案


js的出异常的解决方案是: 修改静态资源文件的文件名(注意如果是js文件必须修改非参数部分如: g.tbcdn.cn/aaa/bbb/ccc/ddd-min.js部分,而非 t=xxxxx.js)

另外:

由于safebrowsing检测的是所有静态资源,目前已发现的出现问题的资源文件类型和解决方案是:

/ Type Solution
1 ajax 修改请求名
2 js, css 修改目录时间戳
3 页面请求 修改参数名或添加时间戳

最后


说多了都是泪, 庆幸本次问题基本只在Firefox中被发现,并且没有大面积爆发。(应该多向chrome团队快速精准解决问题的作风学习呢~)

以后还是需要主动关注浏览器生态圈的动态,避免类似情况发生,以及对某些风险做好提前预防工作, 保证每一个使用Firefox的朋友有一个良好用户体验

特别感谢Firefox的同学积极的帮助! 后续还会继续骚扰!

互联网公司官方标志Logo的颜色选择依据
明年的,网页设计趋势!