微信小程序场景

在计算机网络的世界中，每种新技术、新产品或新平台的面世都会衍生出新的安全问题，为网络安全发展注入新鲜血液。在微信巨大用户基础和腾讯公司对小程序平台的大力推广之下，近几年来小程序可谓是发展迅速、遍地开花，为移动互联网又带来了一场繁荣。
从安全的角度来看，虽然小程序技术从本质上只是WEB应用在B/S网络架构上的另一种实践，其安全也更多的是常见基础网络安全的堆叠。但由于小程序依赖于微信相对封闭的生态而存在，面向的却可能是国内互联网上跨度最广、数量最大的用户群体。因此对于小程序技术，即使是基础安全问题也值得挖掘与思考，进一步针对小程序的独特性进行安全性的研究。

小程序场景下的安全问题

从一张流程图简单说明微信小程序的架构拓扑。

由图中可见小程序的网络架构主要包含前端与后端两个部分。其中前端部分是位于用户侧的客户端，包含微信App和小程序客户端（即小程序前端）；而后端部分为远离用户的服务端，包括位于腾讯公司服务器的微信服务器后端，以及提供小程序的业务方后端服务器与数据库等。
在小程序的运行过程中，需要与业务后端进行网络数据通信，以完成业务上的功能；同时小程序的运行环境又依赖于微信生态，因此小程序往往需要调用微信提供的API，例如调用微信客户端的二维码识别、人像识别等API，或调用微信后端提供的用户身份认证等接口。
简单说完微信小程序的架构和通信场景，下面针对上述场景探讨可能存在的安全问题。

前端安全

前端包括微信客户端和小程序两个部分，其中微信客户端主要以App或应用程序形式存在，具体而言就是基于x86或ARM的Android、iOS、Windows或MacOS应用程序；小程序主体为采用微信定义的方式进行打包、编码甚至加密的web应用。

源码泄漏

从二进制逆向来说，微信App采用的保护措施并不多，即使练习时长两年半的逆向工程师也能比较容易进行关键函数Hook，从而达到预期的逆向目的。而小程序部分主要为WEB，因为没有编译过程所以代码基本上以源码方式运行，相较与二进制逆向便天然降低了门槛。即使微信团队在小程序供应链上对构造和分发过程采取了一定的安全措施，但相应的小程序逆向技术更可谓是魔高一丈。例如著名的wxappUnpacker对微信小程序的打包算法进行了逆向，实现了小程序解包，这样小程序的逆向就剩下源码审计了。

源码分发是WEB前端技术的一大特征，因此web前端代码保护技术也是一个亘古的话题。WEB前端技术是小程序的基石，因此WEB前端代码保护技术也可以用于于小程序中，对小程序的WEB前端代码进行保护，即使代码被解包也难以被理解、调试和修改。
在腾讯官方提供的小程序开发工具中提供了压缩代码和代码保护选项，可以在打包的过程中对小程序中的JS代码进行混淆与压缩。也可以使用好评如潮的javascript-obfuscator等第三方开源工具进行JS代码混淆保护。

源码信息泄漏

攻击者获取了小程序的源码，除了可以对小程序的特定功能流程、API调用等进行分析与修改，也可能在代码审计过程中发现由于开发者失误而留在WEB前端代码中的敏感信息。例如账号密码敏感数据、数据库地址或个人信息等。前阵子有因为在某技术平台进行交流时在代码注释处泄漏数据库密码导致大量信息泄漏事件，可见在对发布的代码进行信息脱敏的重要性。对于WEB前端代码这种几乎以明文分发的代码，对敏感信息的扫描则更显得尤为重要。
在小程序开发工具中虽然对特定数据如手机号、银行卡等敏感数据有一定的扫描能力，但对于用户名密码等敏感数据的扫描与检测通常还是需要人工代码审计进行，同时加强开发人员的安全意识。

恶意代码

在小程序供应链上，开发可谓是最重要的一环。开发小程序的工具主要有三种：使用腾讯官方提供的小程序开发环境进行开发、使用第三方小程序开发环境进行开发、交给外包团队进行开发。除了直接使用官方工具进行开发之外，后二者都会存在一定的风险，例如被第三方植入恶意代码；如果把前端和后端都交给外包团队进行开发的话，则恶意代码的风险不仅存在于小程序客户端，也可能存在于服务端，例如外包团队在服务器上留下后门。
虽然官方开发工具安全又可靠，但往往会有一些限制，从而许多开发者选择了更为自由的第三方开发工具，宁愿用安全换取方便，就像多年前的Xcode后门事件中，开发者因为官方Xcode下载速度慢而安装了第三方途径下载的Xcode，导致编译出来的App存在后门。
在计算机发展史上，安全与效率的博弈是一直处于动态平衡的过程中，二者都是不可或缺的。

后端安全

小程序是典型的前后端分离场景，后端通常使用API方式为小程序前端提供服务。与其他后端服务类似，小程序后端也会面临常见的WEB攻击，而又由于使用API方式提供服务，也会面临API相应的安全问题。

网络安全

作为一台服务器在公网开放端口提供服务，自然会受到各种各样的骚扰，比如端口扫描、漏洞扫描和端口爆破等。即使是无关业务，攻击者也可以根据存活的主机与开放的端口发起DoS和DDoS攻击。
所以说服务器在外一定要学会保护好自己：在网络层上，对包长过大的Ping of Death等攻击手段进行识别；在传输层上，对SYN flood、UDP flood等攻击手段进行识别；在应用层上，还要识别慢速HTTP、DNS洪泛等攻击。当然，专业领域最好交给专业人士，应用服务器不应该疲于应对攻击，搭建一个DDoS防御服务是更好的选择。

WEB安全

作为后端服务，面临的WEB安全也是耳熟能详千篇一律，例如基于PHP和MySQL搭建的后端容易受到MySQL注入、PHP反序列化、文件上传与包含等各种攻击；基于Java及其框架搭建的后端，则会受到各种Java反序列化攻击、框架漏洞攻击等；基于Python和Flask搭建的后端，又有模板注入等攻击方式……
WEB安全攻击手段数不胜数，也是防不胜防，但可以用一个通用招数应对，就是上WAF（Web Application Firewall，WEB应用防火墙）！

上图中，由于抗DDoS和WAF都前置于后端服务器并提供安全服务，因此将二者整合抽象作为安全层。

API安全

API安全和WEB安全存在些许差异，而由于小程序场景中对API的大量使用，因此在研究小程序后端安全时，可以将API安全独立于web安全进行研究。除了常见的WEB攻击手段外，小程序场景下的API服务还会面临CC攻击和未授权访问攻击等。
许多WAF已经具备了对于CC攻击的防护，但对于API攻击的横向、纵向未授权访问防御，通常需要专业API网关进行防护。除此之外，更为行之有效、低成本高收益的措施则是提高开发人员的安全意识。毕竟稍微有安全意识的开发人员就不应该写出有未授权访问漏洞的API。

业务安全

说到底小程序也是围绕着业务去提供服务，代码层面上的攻击可以用代码去防御，但对于业务上的攻防，代码就更多只能起到辅助作用。
小程序业务上的一个风险点是攻击者伪造相似的小程序进行用户欺骗。伪造小程序并不困难，除了正向开发，还能采用逆向获取源代码的方式。而伪造的小程序可以骗取用户的点击则更为轻松，虽然人们常常被教育不要点击来历不明的链接，但人们往往忽略了来历不明的小程序。比起链接给人们带来的不安全感，小程序的点击页面图文并茂，用户在点击之前几乎无法判断小程序的正规性。

对于虚假小程序的排查，一方面需要微信官方提高对小程序发行的审核，阻止虚假的小程序发布；另一方面对于相关的业务提供方，也可以进行小程序相似名称进行搜索，或接受用户举报，从而发现伪造小程序。

后记

正如前文所说，安全与效率始终在进行着动态平衡的博弈。在移动互联网时代，显然是效率为王。快速的应用开发、功能迭代之下，必然是在安全性上作出了牺牲。小程序是移动互联网的又一次繁荣，也是对应用开发效率的进一步追求，而同样也是在安全性上的又一次牺牲。相比起桌面端应用在安全上的孜孜以求，小程序领域上遍地都是未授权的API。
在一个领域发展到巅峰之时，往往是其安全才开始萌芽，而如今小程序技术已将近成熟，开发人员应该多关注关注安全了。