作者 | 陈峻
审校 | 重楼
众所周知，智能手机、平板电脑和智能手表等开放性移动智能设备，以其带有丰富的扩展性功能（如：麦克风、摄像头、地理位置等）和可访问到广泛的数据源（如：电子邮件、协作文档、社交媒体等），正在我们生活的方方面面被频繁使用。然而安装在移动设备上的、那些长久没能更新的移动应用（Mobile APP）往往潜藏着移动代码缺陷、API保护不到位、以及配置错误等安全薄弱环节，也可能导致APP的用户前端、甚至其对应的服务后端，受到针对财务数据的攻击和用户隐私的侵犯。
近年来的一项大规模的调查发现，全球有四分之三的移动应用至少包含了一个中等级别的安全漏洞。因此，我们需要警钟长鸣，通过开展持续的静、动态分析和渗透测试等方式，对已经在用和即将上线的移动应用开展全面的安全测评（MAST），以免遭不必要的攻击。下面，我们将从移动应用的攻击类型，安全构建和上线测评三个方面，和你进行深入讨论。
一、移动应用攻击
针对移动应用的典型攻击类型有如下三种：
- 基于浏览器的攻击，即攻击者使用过时的浏览器、或不安全的浏览活动，将恶意软件注入到移动设备上。
- 基于短信（SMS）的攻击，即攻击者通过传送与APP相关的、包含恶意链接的短信，诱骗用户点击，进而在后台将恶意代码下载到移动设备上。
- 基于应用逻辑的攻击，即攻击者直接利用APP的代码漏洞或逻辑错误，绕过身份验证机制，渗透到移动系统上，未经授权地访问甚至窃取数据。
二、移动应用安全构建
为了让移动应用免受上述各类攻击，我们需要事先设计APP的业务逻辑，了解漏洞可能出现的位置，以及设计优化数据的调用关系。如下移动应用安全构建要点，可以帮助你构建更安全的移动应用。
1.应用设计
移动应用里往往需要包含API、加密密钥、OAuth令牌、信任密码、以及缓存个人身份信息。而攻击者会想尽办法进行破解、克隆、甚至篡改。为此，在移动应用设计时，我们应创建源代码策略，包括：通过身份验证和授权来控制访问，加密和监控静态敏感数据，使用私密网络或SSH安全传输数据，以及采用日志、水印等数据泄漏防护（DLP）措施。
2.安全编程
3.身份验证
在身份验证的方法上，我们除了采用包括OAuth2.0、OpenID Connect和安全断言标记语言（SAML）等开放标准，也可以运用不同方式的多因素身份验证（MFA）解决方案。其中包括：
- 基于移网推送的一次性密码（OTP）验证：一旦使用此机制，攻击者就算获取到了也无法重复使用它。不过，我们难以认证从移动网络运营商处发来的短信的可靠性。
- 离线基于时间的一次性密码（TOTP）验证：该机制综合了时间和密码两个维度。虽然它不需要新增硬件，但如果攻击者克隆了该机制，便可以生成新的TOTP代码，进而侵占授权用户。
- 硬件令牌：该机制将基于硬件的身份验证与公钥加密相结合，使其难以泄露。当然，我们需要避免用户使用相同的令牌访问多个账户的违规行为。
- 软件令牌：作为一种数字身份验证密钥，该机制需要安装在单独的软件或集成到应用中。不过，由于它需要依赖互联网连接和软件才能工作，因此仍然存在被远程攻击的可能。此外，我们需要在登录尝试失败一定次数后，实施账户锁定策略，以提高注册与登录过程的安全性。这些都是细化保护规则与流程的安全实践。
4.加密通信
通过基于会话的密钥交换或4096位SSL密钥的形式，对移动通信通道实施强加密，以抵御黑客渗透到公共网络或WiFi网络的通信中。
SSL证书的优势在于，它可以在应用中对证书的公钥进行硬编码，并在不依赖第三方证书颁发机构的情况下，启用服务器身份验证，抵御中间人攻击（即攻击者通过提供虚假证书来拦截数据）。
5.API安全
移动应用的安全性离不开内部创建与集成API。其中涉及到API文档、编录、发现、密钥、验证授权、日志记录、调用监控、限流、以及运行时的保护。此外，我们还应采用REST等安全的API框架，并实施最小权限原则（PoLP）。
6.RASP
通过在应用程序的运行过程中采用“插桩”技术，实时应用的自我防护（RASP）可以将安全技术链接到应用环境中，通过自动监控应用在使用时的行为，借助其上下文情景分析能力，实现针对：帐户接管、设备越狱、逆向工程、以及注入钩子等攻击的无人工干预式防御。
事实证明，RASP的这种跨设备与平台的应用兼容性，可以让移动应用具备实时监测，阻断攻击和自我保护的能力。
7.数据存储
移动应用可遵循的应用数据安全存储与使用方式包括：
- 关闭提示在设备上存储密码的选项，以便除设备所有者外，他人无法访问到移动应用中的数据。
- 密码不可以纯文本的形式存储，须始终采取哈希和加盐（即：在哈希之前，将一个称为“盐”的随机字符串附加到密码中，确保生成的每个哈希值都是唯一）处理。
- 使用开发语言内置的加密库，来用于对密码进行哈希和加盐处理的函数。
8.代码混淆
代码混淆技术可以将移动应用变更为功能相同、但无法辨识和解读的格式，使其不易被攻击者破解分析和逆向利用，进而有效地防范了核心代码的泄露、以及数据被篡改。
9.日志监控
严格的审计跟踪和行为监控，可以密切关注移动应用的用户访问和数据修改，进而为日志分析和事件取证提供有利的证据。
三、移动应用安全测评
虽然已有前期的移动应用安全构建，我们仍无法保证移动应用被安装和运行在Android、iOS、Windows Mobile等移动操作系统上，不存在漏洞和风险。对此，我们可以参照OWASP移动应用安全测试指南等权威指导，开展深入的安全测评。
1.测评工具
目前，最常推荐的移动应用安全测评工具包括如下类型：
- 静态应用安全测试（SAST）工具：扫描应用的源代码，以识别漏洞。此类工具可以在CI/CD管道的早期运行，甚至可以在编程时作为IDE插件运行。SAST属于白盒测试，因此也会检验应用内部设计。
- 动态应用安全测试（DAST）工具：通过测试正在运行的应用，是否存在常见的受攻击类型，来检查其运行时的安全性。由于此类工具需要应用正常运行的状态，因此只能在开发过程的后期使用。DAST属于黑盒测试，因此只会基于外部认知，而不考虑应用的内部知识。
- 交互式应用安全测试（IAST）工具：通过从外部扫描应用和对内部应用流进行分析，以便在其运行时检查应用的安全性。IAST 是白盒和黑盒测试的混合体，能够像SAST工具那样开展，并将类似DAST的结果（如，回归识别）对应到源代码上。
- 软件组件分析（SCA）工具：根据第三方代码的依赖关系，开发人员可以使用此类工具，来发现与应用相关各种组件、开源支持库、及其直接和间接的依赖项，进而挖掘出可能存在的被利用的漏洞。
- 模糊测试工具：会自动将各种无效或意外的输入注入到应用中，以发现错误。作为一种黑盒测试技术，模糊测试旨在让应用到达可承受的极限，从而导致其行为异常、崩溃、或出现资源泄漏。
2.测评方法
目前业界比较流行的针对移动应用安全测评方法有：
- 自动测评：由自动化工具扫描应用代码，以查找潜在的漏洞，使开发团队能尽早识别到安全风险。此类测评的优势在于速度、准确性、可扩展性、以及成本效益。
- 手动测评：由人工测评人员手动与应用交互，以识别漏洞。此类测评最适合用于检测那些更高级别、更抽象的应用问题，例如，应用设计的缺陷和业务逻辑的错误等。
- 漏洞赏金计划：通过向能够识别和披露移动应用漏洞的安全研究人员和道德黑客提供金钱奖励，来及时发现潜在的安全漏洞，并激励改进措施的提供。
- 众包漏洞披露：与漏洞赏金类似，不同之处在于安全漏洞是被公开发布的，而不是私下提交的。此类披露有时包括提供给开发人员如何修复漏洞的建议。在移动应用的实际安全测评中，企业经常会综合利用上述方法。例如，许多组织会先使用自动化工具进行大部分的测评，然后让安全人员进行人工审查，以剔除误报，并了解背后的具体逻辑。与此同时，他们也会持续提供漏洞赏金计划，并加入众包漏洞披露，以增强漏洞的发现与处置能力。此外，作为全面的安全技术栈，移动应用安全测评的补充策略还包括：威胁建模、合规性测试、以及红队模拟攻击等。
3.测评挑战
虽然我们可以灵活选用上述提到的不同安全测评方法与工具，但是在实际操作中可能会遇到如下挑战：
- 当移动应用在各种不同的操作系统和设备上运行时，会出现平台“碎片化”的现象。也就是说，为了满足测评的覆盖面，我们不仅需要在不同的平台上开展，甚至需要在同一操作系统的不同版本上也要进行测评。这对于针对Android平台开发的移动应用来说十分常见，毕竟不同的第三方制造商往往拥有自己独特的操作系统版本。
- 当被选用的测评工具集无法支持诸如：Java、Kotlin、Objective C以及Swift等独立于平台的语言时，开发语言的覆盖率便成了挑战。显然，对于混合移动应用而言，原生开发与由Web应用开发带来的安全风险是不尽相同的。
- 由于许多DAST测试框架并非面向移动应用的安全性而设计，因此尽管各种框架仍在改进中，但是目前尚难以获得全面的针对移动应用的测评数据。
4.测评流程
一套完整的移动应用安全测评流程，通常由如下关键步骤组成：
- 定义目标：明确定义待测评移动应用的安全目标，需重点关注特定于移动设备的数据保护、安全数据传输和用户隐私等安全需求。
- 信息收集和规划：从测评方的角度收集有关信息、按需检查应用的运行环境、设计、功能和源代码，并据此来规划后续的安全测评工作。
- 选择工具：根据数据加密、身份验证与授权机制、以及特定于移动设备的API等因素，选择针对待测应用的适当测评工具。
- 确定方法：通过讨论，确定是从内部人员角度（白盒）、还是从外部人角度（黑盒）评估移动应用。应重点关注特定于移动设备的漏洞和用户数据保护。
- 自动工具扫描：对自动化工具进行基本配置，全面扫描并发现待测应用的漏洞。
- 手动测试与核实：测评人员根据定义的范围和选择的方法，对待测应用执行深入的手动测试，进一步发掘并核实漏洞。
- 渗透测试：模拟现实世界的攻击，重点关注与移动应用交互的后端服务和API的安全性，例如：不安全的数据存储、不适当的身份验证、API或云服务的错误配置、以及特定移动设备的风险等。其间，测评人员应遵守基本的道德准则。
- 分析结果：根据测评过程所发现的漏洞，针对用户数据安全和隐私的影响，分析并确定漏洞的优先级。
- 形成报告：测评人员根据上述结果，创建一份详细的、对开发人员友好的报告。该报告将包括发现的所有漏洞、严重性、以及如何整改的参考。
- 实施整改：开发人员通过实施必要代码修复与逻辑整改，解决特定于移动应用的安全漏洞，增强其安全态势，并保护用户数据。
- 重新测试：测评人员开展对整改后移动应用的重新测评，以避免应用“带伤”上线。
- 记录所有内容：全面记录整改内容、复测结果、补救措施，以满足合规性要求，并为下一轮测评提供参考。
- 定期测评：测评人员应定期对移动应用开展安全测评，特别是在移动应用发生重大更新或变更后，以维护用户数据和应用程序本身的安全。
5.优秀实践
虽然我们执行移动应用的具体方法与流程，会根据本系统和应用的独特性不尽相同，但是如下根据行业经验总结出的优秀实践，仍值得你参考，并有助你避开坑点：
- 将移动应用的安全测评整合到现有的移动CI/CD管道中，以体现诸如尽早改善安全态势和集成，以及降本增效的安全左移优势。
- 参照OWASP 移动应用安全测试指南，建立符合实际的安全测试框架，以及时发现和解决各种常见的典型安全问题。
- 针对不同类型的移动应用和不同的使用场景，综合采用上述提到的SAST、DAST和SCA等多种测试方法。
- 鉴于安全态势只是一时，而非一段时间，因此需要团队中形成定期测试的机制，即：对于一段时间未发生重大变更的移动应用，可引入每半年或每季度开展测评的“底线”，以识别该周期内新披露的漏洞。
- 选择具有互补功能的自动扫描工具，以确保其适合你的CI/CD管道，涵盖必要的移动应用编程语言，并降低误报率。
- 请不要忽视移动应用的后端安全性。即使已测试了前端应用的安全性，也需要测试其连接的后端的代码、配置、所处的环境、数据交换的链路等安全性。
- 鉴于移动终端的多样性，应尽可能多地在不同设备上测试移动应用的安装与运行，可考虑使用自动化来提高此过程的效率。
译者介绍
陈峻（Julian Chen），51CTO社区编辑，具有十多年的IT项目实施经验，善于对内外部资源与风险实施管控，专注传播网络与信息安全知识与经验。
