小程序安全沙箱技术，将恶意代码装进“笼子”里,微信小程序沙箱环境

本文讲述了小程序安全沙箱技术，将恶意代码装进“笼子”里,微信小程序沙箱环境。

我们的工作和生活已经离不开各式各样的软件。

趋势所向。今年初白宫都不得不召集会议讨论Log4J，拜登都得知道Java，是不是莫名魔幻？但对于码农来说是不是略感自豪 - 相当于所在银行行长、公司CEO深入IT基层，亲自了解一个用Java写的、通常埋在十八层代码之下的日志工具，“并作出重要指示”的既视感...

那么，软件盛行的年代，企业中高管最怕的是什么？

“某天，某银行被盗取大量数据、遭受巨大经济损失，并遭到消费者集体诉讼和监管天量罚单。原因是技术系统用了某个开源代码包，该开源代码包原来是一个遭黑客污染过植入了后门的有毒组件。不小心误用这个代码包的，是IT部门某基层小弟所为。新闻爆出，CIO一脸蒙圈，卒。”

上述例子的罪魁祸首，叫软件供应链攻击。这个问题的潜在风险，大到什么程度呢？根据Gartner，至2025年全球有接近一半的企业会会遭遇到，感兴趣的同学可以自行脑补...

“Hello，World”后面可能有几万行代码

开源软件运动如火如荼的进行了二十四五年（如果从1998年2月3日在硅谷的一次会议中首次提出“open source”一说开始算 - 当时互联网先驱Netscape刚刚宣布开放他们的浏览器源码），极大程度的改变了软件业的面貌。当前全球企业超过90%直接或者间接甚至在无意识中使用了开源技术。

时间快进到2022年，很多企业的业务软件里可能只有低至10%的代码是自己的工程师写的，其他的都来源于不知名的开源世界，开发者自己都不知道，供应链被污染了，影响到自己，也殃及其他“租户”。“物业”呢，则不排除内部人员有道德风险，做倒卖“租户”资产（例如数据）的事情。

你想用JavaScript+Node.js开发一个只能对网络请求返回“Hello，World”回复的微服务，你决定采用一个最轻量简约的微服务框架ExpressJS - 一动手的瞬间，你的开发工具npm就给你从上游拉取100+软件包 - 54,000行代码拿去，不谢。如果你想再玩点高级功能，例如添加一个MVC框架（例如Locomotive），你的这个“微”服务实际代码量马上升至220,000行 - 不好意思，起步价，哪怕你只写一行代码。

软件供应链的四大风险

对于企业来说，当前软件供应链起码面临四类风险。

软件质量风险。企业软件表面上由IT或者外包商开发，可是实质上背后是成千上万的第三方开源代码，企业的QA工程质量管理方法和流程，对于第三方完全失控无效。

长期支持风险。企业软件所间接依赖的一些第三方开源零部件，并没有商业体在背后提供质量承诺和长期支持。开源项目因创始人退出或者社区活跃度低而不再维护、半途而废的，不在小数。产生维护支持需求时，企业自己不得不安排人手去处理该部分代码，先不说有没有这个意愿，企业自己的IT工程师是否有这个能力也难说。

知识产权风险。开源软件的知识产权机制，反映在著佐权（Copyleft）和许可证（Permissive）。后者约束了你的软件的分发传播需要满足的条件，前者则往往更进一步要求你用开源组件开发的软件本身的源代码必须沿用同样的开源条款，导致你的软件知识产权不得不公开。国内软件企业在使用开源、贡献开源的过程中规则意识普遍薄弱，存在错误混用不兼容的许可证，违反许可证规定二次发布等问题，带来更为复杂的知识产权问题和法律合规风险。

信息安全风险。在开发人员写第一行代码前，一个系统可能就注定继承了一堆“安全债务” - 部分取决于这个系统的设计者、开发者选择采用什么第三方组件，部分取决于这些第三方组件的开发者又选择依赖于什么别的组件。反正安全风险是传递的，只要有一个零部件有安全漏洞、甚至是在漫长复杂的互联网分发链路上被篡改过注入了恶意代码，你的系统就继承了所有这些风险。

在信息化程度比较高的金融业，软件作为金融信息基础设施的重要组成部分，安全问题将直接影响金融信息系统的安全稳定运行。

小程序安全沙箱类技术的盛行

首先说说小程序生态。在BAT等巨头的带动下，市场上已经有11大小程序平台，700W+的小程序应用，覆盖200+个细分垂直领域，可见，小程序生态在国内已经具备相当影响力的规模。正因为如此迅猛的发展，互联网系列全球标准的制定者W3C，也正在通过其Mini-Apps工作组制定小程序技术的国际标准。

然后说说App插件生态。作为Web 2.0的标志性技术产物，历经互联网蓬勃发展的市场需求的迭代，衍生出许多标准化的、能够降低App（甚至扩展至移动设备）开发的插件式SDK：极光推送、声网音视频、第三方登录、第三方支付.....

再说说小程序安全沙箱技术。如果将小程序和移动设备插件比喻成“点”，那么小程序安全沙箱技术（例如：FinClip）就是能够让一个个点组装成App的“线”。FinClip小程序容器技术的价值点之一在于「连接」：只要把FinClip SDK嵌入到自己的App中，马上获得小程序运行能力，而只有获得小程序运行能力，才能在App中充分引入成熟的小程序应用。

此外，在软件供应链安全防护上，小程序容器技术天然的安全隔离能力，通过构建一个封闭的软件环境，隔离了它所在的“宿主”的资源包括内存、文件系统、网络等等的访问权限。运行在这个封闭环境中的进程，其代码不受信任，进程不能因为其自身的稳定性导致沙箱的崩溃从而影响宿主系统，进程也无法突破沙箱的安全管控以读写宿主系统的资源。

俗话说，天时-地利-人和，现代社会快节奏市场强压下，如果还是老式的思想，企业重复造车轮，那么铁定是跟不上用户快速变化的需求。只有充分利用各领域构建起来的成熟生态，以互联互通、合作共赢的方式方能发挥企业1+1>2的效应。

小程序容器技术便是一个非常好的「技术催化剂」，将小程序应用生态、移动设备插件生态、移动设备有机的“粘合”在一起，且Plus一个安全沙箱的机制，对软件供应链安全的端侧进行安全隔离和防护。感兴趣的可以登陆FinClip官网了解一下。

双线程模型

微信小程序的框架包含两部分 View 视图层、App Service逻辑层。View层用来渲染页面结构，App Service层用来逻辑处理、数据请求、接口调用，它们在两个线程（Webview）里运行。

视图层和逻辑层通过系统层的JSBridage进行通信，逻辑层把数据变化通知到视图层，触发视图层页面更新，视图层把触发的事件通知到逻辑层进行业务处理。

小程序的渲染层和逻辑层分别由2个线程管理：

（1）视图层：界面渲染相关的任务全都在 WebView 线程里执行。一个小程序存在多个界面，所以渲染层存在多个 WebView 线程。

（2）逻辑层：采用 JsCore 线程运行JS脚本。

视图层和逻辑层通过系统层的 WeixinJsBridage 进行通信：逻辑层把数据变化通知到视图层，触发视图层页面更新，视图层把触发的事件通知到逻辑层进行业务处理。

渲染流程

把开发者的 JS 逻辑代码放到单独的线程去运行，但在 Webview 线程里，开发者就没法直接操作 DOM。

那要怎么去实现动态更改界面呢？

逻辑层和试图层的通信会由 Native （微信客户端）做中转，逻辑层发送网络请求也经由 Native 转发。

这也就是说，我们可以把 DOM 的更新通过简单的数据通信来实现。

Virtual DOM 大概是这么个过程：用 JS 对象模拟 DOM 树 -> 比较两棵虚拟 DOM 树的差异 -> 把差异应用到真正的 DOM 树上。

页面渲染的具体流程是：在渲染层，宿主环境会把 WXML 转化成对应的 JS 对象，在逻辑层发生数据变更的时候，我们需要通过宿主环境提供的 setData 方法把数据从逻辑层传递到渲染层，再经过对比前后差异，把差异应用在原来的Dom树上，渲染出正确的UI界面。

（1）在渲染层把 WXML 转化成对应的 JS 对象。

（2）在逻辑层发生数据变更的时候，通过宿主环境提供的 setData 方法把数据从逻辑层传递到 Native，再转发到渲染层。

（3）经过对比前后差异，把差异应用在原来的 DOM 树上，更新界面。

我们通过把 WXML 转化为数据，通过 Native 进行转发，来实现逻辑层和渲染层的交互和通信。

双线程模型设计的好处

双线程模型是小程序框架与业界大多数前端 Web 框架不同之处。基于这个模型，可以更好地管控以及提供更安全的环境。缺点是带来了无处不在的异步问题（任何数据传递都是线程间的通信，也就是都会有一定的延时），不过小程序在框架层面已经封装好了异步带来的时序问题。

为什么要这样设计呢，前面也提到了管控和安全，为了解决这些问题，我们需要阻止开发者使用一些，例如浏览器的window对象，跳转页面、操作DOM、动态执行脚本的开放性接口。

我们可以使用客户端系统的 JavaScript 引擎（iOS 下的 JavaScriptCore 框架，安卓下腾讯 x5 内核提供的 JsCore 环境），这个沙箱环境只提供纯 JavaScript 的解释执行环境，没有任何浏览器相关接口，这就是小程序双线程模型的由来。

性能优化

主要的优化策略可以归纳为三方面：

启动小程序方面：

分包加载

控制代码包大小

页面及页面层级方面

合理使用setData调用，减少setData次数和数据量

数据通信方面：精简代码，降低WXML结构和JS代码的复杂性。

js中提高数据更新速度

wxml 中提高数据更新速度

小程序启动时，微信会为小程序展示一个固定的启动界面，界面内包含小程序的图标、名称和加载提示图标。

性能优化方式一：分包加载

采用分包加载时，小程序的代码包有两种：

一个“主包”，包含小程序启动时会马上打开的页面代码和相关资源。

多个“分包”，包含其余的代码和资源。

这样，小程序启动时，只需要先将主包-完成，就可以立刻启动小程序，从而降低小程序代码包的-时间。

分包app.json 中的配置如下

{

  //主包

  "pages":["pages/index/index","pages/logs/logs"],

  //分包

  "subPackages": [

    {

      "root": "packageA",

      "pages": [“pages/apple/apple"]

    }, {

      "root": "packageB",

      "pages": ["pages/banana/banana"]

    }

  ]

}

单个分包/主包大小不能超过 2M

整个小程序所有分包大小不超过 16M

性能优化方式二：控制代码包大小

精简代码，去掉不必要的WXML结构和未使用的WXSS。

减少在代码包中直接嵌入的资源文件。不是必须的可以放在服务器上。

压缩图片，使用适当的图片格式。

性能优化方式三：合理使用setData调用，减少setData次数和数据量；

1、setData 工作原理

小程序的视图层目前使用 WebView 作为渲染载体，而逻辑层是由独立的 JavascriptCore 作为运行环境。

在架构上，WebView 和 JavascriptCore 都是独立的模块，并不具备数据直接共享的通道。

当前，视图层和逻辑层的数据传输，实际上通过两边提供的 evaluateJavascript 所实现。即用户传输的数据，需要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份 JS 脚本，再通过执行 JS 脚本的形式传递到两边独立环境。

而 evaluateJavascript 的执行会受很多方面的影响，数据到达视图层并不是实时的。

2、常见的 setData 操作错误

（1）频繁的去 setData

在我们分析过的一些案例里，部分小程序会非常频繁（毫秒级）的去setData，其导致了两个后果：Android下用户在滑动时会感觉到卡顿，操作反馈延迟严重，因为 JS 线程一直在编译执行渲染，未能及时将用户操作事件传递到逻辑层，逻辑层亦无法及时将操作处理结果及时传递到视图层；渲染有出现延时，由于 WebView 的 JS 线程一直处于忙碌状态，逻辑层到页面层的通信耗时上升，视图层收到的数据消息时距离发出时间已经过去了几百毫秒，渲染的结果并不实时；

（2）每次 setData 都传递大量新数据

由setData的底层实现可知，我们的数据传输实际是一次 evaluateJavascript 脚本过程，当数据量过大时会增加脚本的编译执行时间，占用 WebView JS 线程

（3）后台态页面进行setData

当页面进入后台态（用户不可见），不应该继续去进行setData，后台态页面的渲染用户是无法感受的，另外后台态页面去setData也会抢占前台页面的执行。

性能优化方式四：js中提高数据更新速度

多次setData合并成一次setData调用，不要过于频繁调用setData。

数据通信的性能与数据量正相关，因而如果有一些数据字段不在界面中展示，且数据结构比较复杂或包含长字符串，则不应使用setData来设置这些数据。

与界面渲染无关的数据最好不要设置在data中，可以考虑设置在page对象的其它字段下。

例如

onShow: function() {

    // 不要频繁调用setData

    this.setData({ a: 1 })

    this.setData({ b: 2 })

    // 绝大多数时候可优化为

    this.setData({ a: 1, b: 2 })

    // 将与界面无关的数据放在data外

    this.setData({myData: {a: '这个字符串在WXML中用到了',b: '这个字符串未在WXML中用到，且很长…’ }})

    // 可以优化为

    this.setData({'myData:{a': '这个字符串在WXML中用到了'})

    this._myData = {b: '这个字符串未在WXML中用到，且很长…'}

}

性能优化方式五：wxml 中提高数据更新速度

去掉不必要的事件绑定（WXML中的bind和catch），从而减少通信的数据量和次数。

不要在节点的data前缀属性中放置过大的数据，因为事件绑定时需要传输target和currentTarget的dataset

上文是小编为大家整理的小程序安全沙箱技术，将恶意代码装进“笼子”里,微信小程序沙箱环境。

国内(北京、上海、广州、深圳、成都、重庆、杭州、西安、武汉、苏州、郑州、南京、天津、长沙、东莞、宁波、佛山、合肥、青岛)Finclip软件分析、比较及推荐。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。