苹果爸爸放大招,禁掉JSPatch热更新(Apple爹已给回复)

by admin on 2020年4月17日

澳门新葡亰网址下载 1

这应该是软件开发最近两天最热的话题了吧。。。 O(∩_∩)O哈哈~
首先说一下这次受影响的第三方:
澳门新葡亰网址下载,目前已经知道的有:
高德地图 已经更新了sdk V1.3.4 规避了问题
*Bugtags 已经更新了SDK V2.2.1规避了问题 *
这里不得不说下,大厂就是效率啊,很快给出了解决方案。
还有rollout,react native,weex,JSPatch,个推 ,bugly with hotfix等。

苹果近期给大部分接入 JSPatch 的 APP
发送了警告,提示下个版本去掉拥有动态修改功能的代码或框架。

近日 iOS
开发者们陆续收到苹果邮件,警告去掉动态下发功能,覆盖面很广,内容没有明确指示是什么库,导致大家各种猜测。

也有说是使用dlopen(), dlsym(), respondsToSelector:, performSelector:,
method_exchangeImplementations()这些个方法太多了。。具体原因不清楚,还得等苹果大大给出答案啊,谁让他是你亲爹来呢。。。

我们理解苹果这个决定是为了杜绝 JSPatch
使用不当导致的安全隐患以及恶意滥用,在此建议大家在下个版本先去除
JSPatch。

其实上周已经有少量用户收到苹果这份警告邮件,当时还以为是特例,现在看来是在灰度测试扫描代码,可见这事苹果应该讨论已久,并专门排期开发测试了扫描程序,直到昨天才正式上线。

猜测的原因

苹果为什么这么做呢?苹果对热修复一直以来的态度都是不赞同也不拒绝,JSPatch
本身也并没有违反开发者条例,而且 JSPatch 大多数都用于修复 bug,提升
iOS 平台 App
的质量,对苹果也是件好事,为什么要禁?猜测原因有两点:可控和安全

热修复本身可以显著提升 App 质量,对于 iOS
平台是很有益的事情,鉴于热修复的需求量庞大,我们也在思考如何让热修复继续发挥作用提升
iOS 平台 APP 的质量,同时又可以解决这里面的安全和滥用的隐患。

从各方信息看起来,很不幸主要禁的还是 JSPatch / wax/ rollout 这样的热修复框架,特点是可以通过
JS 脚本调用和替换任意 OC 方法,而像 React Native/ 小程序这样用 JS
做功能的暂时不受影响,Weex 不确定,至于其他库像 AFNetworking /
SDWebimage 用到那几个接口的,应该只是误伤。

可控

苹果一贯作风是让所有事情可控,开发者能用什么不能用什么都尽量在自己的控制范围内。大多数人使用
JSPatch 修复
bug,或者弄一些临时运营的小功能配置,这些没有问题,但总会有少数用户使用
JSPatch
去调用私有API做些事,这是苹果不可控的
,也无法知道有多少人这样做了。
不过其实在代码这块苹果其实一直可控程度有限,他会在提交时扫描你有没有用某些私有方法,但只要你对这些私有方法调用做一些变化,加解密字符串拼接什么的,就能绕过扫描,再通过后台配置调用,是一样的。JSPatch
只是让调用私有 API 变得成本更低更方便点而已,可控这里只是个小理由。

对此后续 JSPatch
平台会有以下升级改进:

根据苹果要求,收到警告的同学只需要在下次提交版本时去掉相关框架就可以,没有时间期限,目前也不会强制下架。

安全

去年 FireEye 分析了使用 JSPatch
的安全问题,当时也有文章回应了,再复述一下,主要安全风险有三点:
开发者自己本身对 APP 下发恶意代码。
开发者没有做好加密传输和校验。
开发者接入的SDK里接入了JSPatch,SDK 作者可以对这些 APP 下发恶意脚本。
第一点其实不算安全风险,因为开发者自己有恶意的话完全不需要借助
JSPatch。
第二点大多数用户使用 JSPatch
时都做好了非对称加密,保证不会在传输过程被第三方篡改。但这里技术上没法保证用户一定使用正确的加密方式,苹果无法知道有多少接入
JSPatch 的用户没有正确加密和校验,这是未知的安全隐患。
第三点在当时并没有什么第三方 SDK 接入
JSPatch,但现在像高德地图/个推等都接入了,如果他们要作恶,或者他们本身服务端被入侵,确实是个安全隐患。
iOS 平台是最安全的,也是最注重安全的,即使热修复带来了 App
质量更高的好处,也无法无视这里的安全隐患,现在 JSPatch
国内覆盖面很大,若出一个安全问题,会影响 iPhone
的声誉,因为这个风险,所以考虑禁掉。

苹果爸爸还是爱我们的

是挑战也是机会

1.强制脚本下发必须使用自定义 RSA 私钥加密

这个功能 JSPatch 平台一直提供,不过不是强制使用,默认会使用平台统一的
RSA 私钥加密,这里会有一定的安全隐患。强制用户使用自己生成的 RSA
私钥后,平台本身完全无权限给用户下发脚本,就算平台被第三方恶意入侵也不会对
APP 有任何影响,不可能出现大规模安全事件。

为什么

苹果为什么这么做呢?苹果对热修复一直以来的态度都是不赞同也不拒绝,JSPatch
本身也并没有违反开发者条例,而且 JSPatch 大多数都用于修复 bug,提升 iOS
平台 App
的质量,对苹果也是件好事,为什么要禁?猜测原因有两点:可控和安全。

Apple大大终于给出了回复:

The code referenced in our initial rejection message includes any code
which passes arbitrary parameters to dynamic methods such as dlopen(),
dlsym(), respondsToSelector:, performSelector:,
method_exchangeImplementations(), and running remote scripts in order
to change app behavior or call SPI, based on the contents of the
downloaded script.

意思是:代码中引用我们最初拒绝信息,包括任何代码传递任意参数动态方法如dlopen(),dlsym(),respondstoselectorismemberofclass:performSelector:,method_exchangeImplementations(),并运行远程脚本为了改变应用程序的行为或调用SPI,基于下载脚本的内容。
都是不允许的。但是objective –
c方法respondstoselectorismemberofclass:和performSelector:仍然是支持和允许的。

建议最近风声很紧,还没有得到确定的解决方案的时候,还是暂时规避掉这些敏感东西吧,根据苹果要求,收到警告的同学只需要在下次提交版本时去掉相关框架就可以,没有时间期限,目前也不会强制下架。否则你的App可能会被拒甚至被下架。

2.禁止 SDK 接入

SDK 接入 JSPatch 后有能力对所有接入该 SDK 的 APP 下发脚本,SDK
覆盖面大以后,这里也是一个安全隐患,平台会禁止 SDK 接入 。

可控

苹果一贯作风是让所有事情可控,开发者能用什么不能用什么都尽量在自己的控制范围内。大多数人使用
JSPatch 修复
bug,或者弄一些临时运营的小功能配置,这些没有问题,但总会有少数用户使用
JSPatch
去调用私有API做些事,这是苹果不可控的,也无法知道有多少人这样做了。

不过其实在代码这块苹果其实一直可控程度有限,他会在提交时扫描你有没有用某些私有方法,但只要你对这些私有方法调用做一些变化,加解密字符串拼接什么的,就能绕过扫描,再通过后台配置调用,是一样的。JSPatch
只是让调用私有 API 变得成本更低更方便点而已,可控这里只是个小理由。

目前不清楚的点:(已经给出了解决方案)

1、是否不允许使用JSPatch或Rollout.js、React Native、Weex等框架?

3.检查每个下发的脚本,禁止调用私有 API,禁止下发大量代码

这里是避免热修复被滥用,利用动态下发去做一些违反 Apple
规则的事情,同时让热修复只用于修复 bug,而不是试图改变整个 APP 的功能。

平台升级后,接入平台的 APP
不会再有任何安全隐患,同时也可以强制禁止滥用。

鉴于 React Native / weex / 小程序
等动态化方案仍被允许,相信苹果并不拒绝动态方案,只是无法接受平台上有任何安全隐患和绕过审核调私有
API
侵犯用户隐私的行为,平台升级后可以帮助苹果解决这些问题,甚至如果苹果愿意,我们可以开放后台让苹果主导审核程序。

建议平台用户在 APP 下个版本去掉原有的 JSPatch
SDK,在平台升级后再接入新的 SDK,升级完成后我们会通知大家。

热修复可以显著提升 APP
的开发效率和质量,有庞大的需求量,希望可以共建良好的热修复环境。

原文- bang JSPatch
平台关于苹果警告的解决方案&version=12010210&nettype=WIFI&fontScale=100&pass_ticket=7EU6bwOE8tTZTrrxeY2LwcmBlmmFh%2BuQlsHwAIlxTShmr5aj%2Fu7nCE3fLjiheX10)

安全

去年 FireEye 分析了使用 JSPatch
的安全问题,当时我也写文章回应了,再复述一下,主要安全风险有三点:

  1. 开发者自己本身对 APP 下发恶意代码。

  2. 开发者没有做好加密传输和校验。

  3. 开发者接入的SDK里接入了JSPatch,SDK 作者可以对这些 APP
    下发恶意脚本。

第一点其实不算安全风险,因为开发者自己有恶意的话完全不需要借助 JSPatch。

第二点大多数用户使用 JSPatch
时都做好了非对称加密,保证不会在传输过程被第三方篡改。但这里技术上没法保证用户一定使用正确的加密方式,苹果无法知道有多少接入
JSPatch 的用户没有正确加密和校验,这是未知的安全隐患。

第三点在当时并没有什么第三方 SDK 接入
JSPatch,但现在像高德地图/个推等都接入了,如果他们要作恶,或者他们本身服务端被入侵,确实是个安全隐患。

iOS 平台是最安全的,也是最注重安全的,即使热修复带来了 App
质量更高的好处,也无法无视这里的安全隐患,现在 JSPatch
国内覆盖面很大,若出一个安全问题,会影响 iPhone
的声誉,因为这个风险,所以考虑禁掉。

(只要是运行了远程脚本,为了改变应用程序的行为或调用SPI,肯定是不行的啦)

2、AFN和SDWedImage等部分包括 such as dlopen(), dlsym(),
respondsToSelector:, performSelector:,
method_exchangeImplementations(),但是没有远程更新,这样能否使用?

反应

这个警告出来后,国内开发者有各种反应,各种表情贴图还挺搞笑的,不过大家放心,JS没事,iOS
开发该失业的还是失业:)

看到有一些人拍手称赞,赞的理由不是说苹果维护了平台安全,而是:1.国内开发方式low,2.产品经理滥用。这里我有一些想法说一下。

(objective – c方法respondstoselectorismemberofclass:和performSelector:仍然是支持和允许的。)

3、第三方SDK,比如统计分析、crash收集、以及性能分析等,我们怎么检查他们有没有使用非法的方法?

开发方式

他们说国外开发不理解国内为什么要用热修复,国外很少使用,国外开发流程很好很规范,会做好充分的
codereview 和测试,上线后没什么
bug,不需要热修复,也不会有产品经理乱提需求,迭代没像国内这么快,使用热修复是本末倒置,不去考虑提高
APP 质量,国内开发方式太 low,国外的才是正道。

这里有个问题,就是什么是好的开发方式?以什么标准界定?上面的说法可以看出他们是把工程的严谨性,流程的规范性作为好坏的依据。虽然我是个程序员,觉得工程严谨和流程规范确实是好东西,但我比较实用主义,更倾向于以结果作为标准,也就是能不能更低成本更高效地开发出质量更好的产品作为标准。

如果我使用热修复能以更低的人力成本(工程师能力和薪水不如国外,人数少),更高效(测试时间缩短,不需要覆盖到0.01%几率出现的
bug / crash ),做出质量更高的产品( bug /
特殊情况和需求反应速度快),为什么不是一个更好的开发方式呢?

另外客户端的开发方式本身就是落后的,不利于快速迭代,无法对线上产品有控制权,参考另一篇文章。这也就是为什么
Facebook 一开始要用 web hybird 的方式开发,现在又要做 React
Native。热修复是这种落后开发方式的弥补。另外我没在国外公司工作过,但感觉他们对bug的容忍程度还是比国内高的,对比一下
IAP 和微信支付的失败率,做过的人都知道。

还有一个声音说国内的人喜欢违反规则,钻空子太不老实。首先前面也说了热修复的方式并没有违反规则,完全符合开发者条例,其次国外也有热修复
rollout,最后如果从开发者条例来说,React Native
反而是违反规则的,因为主要用途动态添加和修改 APP 的功能。

我的方法就是,自己细致检查,并且关注对应的第三方网站给出的信息。

4、后期的解决方案是什么?

滥用

另一个说法是上了热修复后产品经理来劲了,产品时不时想到一个功能配置说上就上,开发者弱势只能跟着上。

这种情况在我这边团队还没遇到过,我的想法是:如果要上的功能配置对产品是有好处有必要的,开发维护成本又低,为什么不上?如果要上的功能配置是无关紧要的,或者开发维护成本太高,为什么不能讲理拒绝?

开发者把原因定位为自己“弱势”,就把自己从团队剥离开了,变成对人不对事,这种团队氛围是挺糟糕的,而这个锅也不是产品经理的。大家做的事都是为了产品更好,应该不会有那么多故意刁难不讲理的产品经理和老板。至于怎样界定对产品有没有好处和有没有必要,以及开发成本高低,这得自己协商了,以我们团队的做法是以做这个事的性价比计算。

请深入审查你的应用,删除任何代码,框架,或sdk只要是包含上面禁止的内容;然后提交更新你的应用程序。

马上提交版本了,里面只用了JSPatch用于热更新修复BUG,但是没有收到苹果下发的警告邮件,准备不下掉JSPatch 提交看看,到底会不会被拒。 提了之后再来补充结果。

怎么办

接下来如果还想用 JSPatch
怎么办?我没有跟苹果审核团队交流过,不知道他们的想法,短时间内是先不要用,后续再看情况。

热修复的需求很大,很希望苹果可以推出自己的方案,由系统做这个事是可以保证安全的,但现在看起来可能性较低,国外需求量不大,苹果也就不会重视这个需求,何况目前在大力推
Swift。

对于
JSPatch,苹果应该是扫描可执行文件里的关键字,从技术上说是很难禁掉的,可以做各种混淆去绕过检查,但若下发时被查到,会有政策风险,政策有待观察。

实际上动态化还是处于灰色地带,严格来说 RN
是不符合规则的,但还是被允许,只要不给苹果添麻烦,苹果就不会管,JSPatch
因为上面提到的两点风险被管了,怎样做到使用并不给苹果添麻烦呢?

  1. 减少使用人数,降低影响面。

  2. 禁止 SDK 接入。

  3. 接入保证传输安全和只用于修复 bug。

第一点警告邮件和代码检查使得使用门槛变高了,显然会减少使用人数。第二点第三点只要有一个平台来管控,是可以做到的,可能的话希望能跟苹果审核团队协商。

来自:bang’s blog

不过第一版,我还是要冒险测试下这个问题,一旦通过了呢。并且,没有了热更新真的好方啊,等我的消息吧 O(∩_∩)O哈哈哈~

结果:没有下掉JSPatch直接被拒了,删除之后在提交通过了。其中MJ和AFN等这些第三方库是没有问题的。坐等可以替代热更新的方案。

Apple 爹给出的具体回复:

The code referenced in our initial rejection message includes any
code which passes arbitrary parameters to dynamic methods such as
dlopen(), dlsym(), respondsToSelector:, performSelector:,
method_exchangeImplementations(), and running remote scripts in order
to change app behavior or call SPI, based on the contents of the
downloaded script. The Objective-C methods respondsToSelector: and
performSelector: are still supported and allowed. For example, they
can be used to check OS compatibilty before using a selector. However,
you should only pass selectors to these methods, which are specified
at compile time. If you think you are using static selectors, it’s
possible a third-party framework you’ve added to your app is not in
compliance.

Please perform an in-depth review of your app and remove any code,
frameworks, or SDKs that fall in line with the functionality described
above before submitting the next update for your app for review

JSPatch 官方给出的解决方案:

目前的建议以及后期的改进方案

讨论还可以看这些地方,已经closed了;
JSPatch
Issues
react-native
:https://github.com/facebook/react-native/issues/12778
Weex
:https://github.com/alibaba/weex/issues/2875
JSPatch作者的看法

所以,最后的结果以及我们应该做的就是:

请深入审查你的应用,删除任何代码,框架,或sdk只要是包含上面禁止的内容;确保符合要求之后,提交更新你的应用程序。

完!!! 继续关注中。。。

3月28日,JSPatch已经给出了解决方案:对应的解决方案

直接集成SDK的小伙伴可以更新了。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图