16、代码安全与移动应用开发：挑战与应对策略

代码安全与移动应用开发：挑战与应对策略

1. 代码安全分析与 Cornucopia 游戏

在代码安全领域，各组件的攻击面以及攻击向量的弱化是关键问题。可以在 OWASP Cheat Sheet Series GitHub 上找到分析攻击面的速查表。开发团队必须定期重新定义攻击面，因为它会随每个开发周期而变化。跨组件检查用于监控整个产品的攻击面，同样会因开发周期而改变。只有通过跨组件视角，才能发现组件之间甚至依赖关系所产生的攻击向量。

如果没有安全管理人员（SecMs），可以通过结构化方法和团队联合培训进行安全评估。OWASP Cornucopia 就是这样一种工具，它是一款可在项目网站上免费获取的纸牌游戏。玩家需将纸牌上描绘的攻击场景应用于团队预先选定的领域，必要时也可仅针对个别方法，如代码库。团队随后要判断所打出纸牌的攻击场景是否可能发生，重点在于识别攻击向量，由于时间限制，缓解策略可在其他场合讨论。游戏的获胜者是成功打出最难纸牌的人，团队最后需记录由此产生的安全分析结果。

Cornucopia 游戏有诸多好处，它能提高团队对代码漏洞的认识，提升开发人员在 IT 安全方面的专业知识，注重开发人员的能力，符合敏捷准则，也是后续生成恶意用户故事的优秀工具。不过，该游戏也存在问题，对于缺乏经验的团队来说，初期学习曲线较陡，还存在团队错误排除潜在攻击向量的风险。若准备不足，如组件过大或对可能的攻击向量技术知识不足，会导致时间效率低下。因此，在最初的几次游戏中，建议检查小的、独立的组件，必要时咨询安全专家。

开发人员应掌握代码安全的主动权，理想情况下，团队应共同争取足够的时间和资金来实施基本的安全措施。随着数字化和网络化的发展，安全不能因预算和时间限制而被忽视，代码库的安全性是团队的责任。

1.1 Cornucopia 游戏流程

graph LR
    A[团队选定领域] --> B[玩家抽取纸牌]
    B --> C[应用攻击场景]
    C --> D[团队判断可能性]
    D --> E[记录安全分析结果]
    E --> F[评选获胜者]

1.2 Cornucopia 游戏优缺点对比

优点	缺点
提高团队对代码漏洞的认识	初期学习曲线陡
提升开发人员 IT 安全专业知识	存在错误排除潜在攻击向量的风险
符合敏捷准则	准备不足时时间效率低下
可用于生成恶意用户故事

2. 移动应用开发与 DevOps

移动开发和智能手机是计算机拥有量增长最快的领域，过去十年智能手机使用量飞速上升，全球拥有数十亿部智能手机。预计智能手机拥有量将继续增加，因为像印度和中国等大国的拥有率还不到 70%。到 2023 年，全球智能手机数量预计将达到 43 亿部，这是一个不可忽视的市场和用户群体。

智能手机的特性使得 DevOps 成为必要实践，它们属于默认需要持续更新的联网设备，因为面向技术水平较低的消费者，需要以最少的用户参与来维护设备。围绕智能手机构建的应用生态系统推动了这一需求，使最终用户下载新软件和接收软件更新变得容易且风险较低。

2.1 应用更新的原因

应用更新有多种原因，可分为功能性和市场性两方面：
- 功能性原因 ：
- 添加新功能 ：大多数应用为缩短上市时间，以最少可行功能快速发布，之后可通过频繁的小更新为用户添加有用功能。
- 修复漏洞和提高稳定性 ：成熟应用会有大量更新来修复小漏洞、解决稳定性问题和改善用户体验，这些更改通常较小，可频繁发布。
- 修补安全漏洞 ：移动应用的攻击面通常很大，包括本地安装的应用、提供数据的后端以及应用和云服务登录的用户认证流程。
- 市场性原因 ：
- 与主要平台版本对齐 ：主要平台发布新版本时，经过认证并更新以利用新功能的应用下载量会增加。
- 提高应用在应用商店的可见性 ：应用商店会奖励频繁更新的应用，保留用户评分并突出显示新版本，发布说明还能增加商店中的可搜索内容。若应用长时间不更新，搜索引擎优化排名会自然下降。
- 提醒现有用户使用应用 ：移动平台会提示用户更新现有应用，有时会显示徽章或其他提醒，以提高用户参与度。

应用商店中的顶级应用深知持续更新的重要性，更新频率很高。例如，appbot 数据显示，200 个顶级免费应用的上次更新中位时间为 7.8 天。若不采用持续发布流程，将难以跟上这一节奏。

2.2 Java 开发移动应用的选择

Java 开发人员在构建移动应用方面有多种选择：
- 移动 Web 开发 ：使用响应式 Web 应用，可适应受限设备。
- Android 专用应用 ：用 Java 为 Android 设备编写专用应用。
- 跨平台应用 ：如 Gluon Mobile 和 Electron 等，可在 Android 和 iOS 设备上运行。

3. 移动 DevOps 工作流程

移动 DevOps 有诸多商业优势：
- 更好的客户体验 ：应用商店的评分系统使客户体验至关重要，快速响应客户问题并在多种设备上进行测试，可确保最佳客户体验。
- 更快的创新 ：持续向生产环境发布可让新功能和能力更快地交付给客户，超越竞争对手。
- 更高的软件质量 ：由于 Android 设备数量众多且碎片化严重，手动全面测试应用几乎不可能。采用自动化移动测试策略，针对用户群体的关键设备特性进行测试，可减少最终用户报告的问题数量。
- 降低风险 ：现代应用的大部分可执行代码依赖开源组件，存在已知安全漏洞。移动 DevOps 管道可测试依赖项的新版本并频繁更新，能快速修复应用中的已知漏洞。

规划 Android 设备的移动 DevOps 管道时，需考虑以下阶段：

3.1 构建（Build）

Android 构建脚本通常用 Gradle 编写，可使用任何喜欢的持续集成服务器，如 Jenkins、CircleCI、Travis CI 或 JFrog Pipelines。

3.2 测试（Test）

• 单元测试 ：Android 单元测试通常用 JUnit 编写，可轻松实现自动化。更高级的 Android 单元测试常使用 UI 测试框架，如 Espresso、Appium、Calabash 或 Robotium。
• 集成测试 ：除了测试自身应用，还需使用 UI Automator 等工具测试应用之间的交互，这些工具专注于集成测试，可跨多个 Android 应用进行测试。
• 功能测试 ：整体应用验证很重要，可手动进行，也可使用自动化工具模拟用户输入，如上述的 UI 自动化工具，还可运行 Google 的 App Crawler 等机器人爬虫工具来检查应用的用户界面并自动执行用户操作。

3.3 打包（Package）

在打包步骤中，需聚合部署所需的所有脚本、配置文件和二进制文件。使用 Artifactory 等包管理工具可保留所有构建和测试信息，便于跟踪依赖项，进行可追溯性和调试。

3.4 发布（Release）

移动应用开发的一大优势是发布以应用商店提交结束，最终部署到设备由 Google Play 基础设施管理。但挑战在于需准备好构建，确保应用商店提交成功，若未完全自动化构建、测试和打包过程，任何错误都可能导致延迟。

3.5 移动 DevOps 管道流程图

graph LR
    A[构建（Gradle）] --> B[测试]
    B --> B1[单元测试（JUnit 等）]
    B --> B2[集成测试（UI Automator 等）]
    B --> B3[功能测试（App Crawler 等）]
    B --> C[打包（Artifactory）]
    C --> D[发布（应用商店提交）]

3.6 各测试类型的工具及作用

测试类型	工具	作用
单元测试	JUnit、Espresso、Appium、Calabash、Robotium	对代码单元进行自动化测试
集成测试	UI Automator	测试应用之间的交互
功能测试	UI 自动化工具、Google 的 App Crawler	验证应用整体功能，模拟用户输入

4. Android 设备碎片化问题

4.1 Android 与 iOS 设备生态对比

iOS 生态系统由苹果严格控制，硬件型号、屏幕尺寸变化、硬件传感器和功能种类有限。自 2007 年第一部 iPhone 推出以来，仅生产了 29 种不同设备，目前在售的只有 7 种。

相比之下，Android 生态系统对众多不同的设备制造商开放，他们会对屏幕尺寸、分辨率、处理器、硬件传感器等进行定制，甚至生产出可折叠屏幕等独特的外形。有超过 24000 种不同的设备来自 1300 个不同的制造商，其碎片化程度是 iOS 设备的 1000 倍，这使得 Android 平台的测试执行难度大大增加。

4.2 Android 设备碎片化的关键差异

当涉及到碎片化时，有几个关键差异使得统一测试不同的 Android 设备变得困难：
- Android 版本 ：Android 设备制造商并不总是为旧设备提供更新到最新 Android 版本的服务，导致用户只能继续使用旧的 Android 操作系统版本，直到购买新设备。旧版本 Android 的使用率下降非常缓慢，仍有活跃设备在运行 7 年多前发布的 Android 4.x 版本，包括 Jelly Bean 和 KitKat。
- 屏幕尺寸和分辨率 ：Android 设备具有各种各样的外形和硬件配置，并且有向更大、像素密度更高的显示屏发展的趋势。一个设计良好的应用程序需要能够在不同的屏幕尺寸和分辨率下正常工作。
- 3D 支持 ：特别是对于游戏来说，了解设备在 API 和性能方面的 3D 支持水平至关重要。
- 硬件功能 ：大多数 Android 设备都配备了基本的硬件传感器（如相机、加速度计、GPS），但对于较新的硬件 API（如 NFC、气压计、磁力计、接近传感器和压力传感器、温度计等）的支持存在很大差异。

4.3 Android 设备碎片化差异对比表

差异类型	Android 情况	iOS 情况
设备数量	超 24000 种来自 1300 个制造商	29 种，7 种在售
Android 版本更新	制造商更新不及时，旧版本仍大量使用	苹果能推动设备同步更新，新版本采用率高
屏幕尺寸和分辨率	差异大，不断有新尺寸和高像素密度出现	相对统一
3D 支持	设备间差异大	相对一致
硬件功能	对新硬件 API 支持差异大	支持较统一

4.4 Android 版本碎片化影响

Android 版本碎片化在两个不同层面影响设备测试。首先是主要的 Android 版本，它决定了需要为多少个不同的 Android API 版本进行构建和测试。其次是原始设备制造商（OEM）为支持特定硬件配置而对操作系统进行的定制。

在 iOS 方面，由于苹果同时控制硬件和操作系统，它能够同时为所有受支持的设备推送更新，这使得性能和安全修复的小更新采用率非常高。苹果还会在主要版本发布中投入大量功能和营销，以促使已安装设备尽快升级到最新版本。因此，iOS 14 在首次发布仅七个月后，采用率就达到了 86%。

而 Android 市场则要复杂得多，因为 OEM 会为其设备修改和测试定制版本的 Android 操作系统，并且他们依赖于系统级芯片（SoC）制造商为不同的硬件组件提供代码更新。这意味着主要供应商生产的设备可能只会获得几次主要的操作系统版本更新，而小供应商的设备即使在保修期内也可能永远不会进行操作系统升级。

为了帮助开发者决定应该支持多旧的 Android 操作系统版本，Google 在 Android Studio 中提供了按 API 级别划分的设备采用情况信息。截至 2021 年 8 月的用户分布情况显示，要达到与最新 iOS 版本相当的超过 86% 的采用率，至少需要支持 2014 年发布的 Android 5.1 Lollipop 版本，但即便如此，仍会错过超过 5% 仍在使用基于 Android 4 的设备的用户。

此外，每个 OEM 都会对其设备所搭载的 Android 操作系统进行修改，因此仅对每个主要 Android 版本的一种设备进行测试是不够的。这是因为 Android 使用 Linux 内核来访问硬件设备，Google 会在基于的 Linux 内核中添加特定于 Android 的功能和补丁，SoC 供应商会添加特定于硬件的支持，而 OEM 会进一步针对其特定设备进行修改。这意味着每个设备在性能、安全性和潜在的 bug 方面都存在一定的差异，可能会影响应用程序在新设备上的运行。

Google 在 Android 8.0 Oreo 中努力改善这种情况，引入了新的硬件抽象层，允许特定于设备的代码在核外运行。这使得 OEM 可以在不等待 SoC 供应商提供设备驱动程序更新的情况下，从 Google 更新到新的 Android 内核版本，从而减少了操作系统升级所需的重新开发和测试工作量。然而，除了 Google 负责操作系统更新的 Pixel 设备外，大多数 Android 设备的升级仍掌握在 OEM 手中，他们升级到新 Android 版本的速度仍然较慢。

5. 应对 Android 屏幕差异的策略

5.1 Android 屏幕情况

由于硬件制造商的多样性以及超过 24000 种不同的型号，屏幕尺寸和分辨率存在巨大差异也就不足为奇了。新的屏幕尺寸不断涌现，例如巨大的 HP Slate 21 使用 21.5 英寸触摸屏，而 Galaxy Fold 采用垂直的 1680x720 封面显示屏，打开后可显示分辨率为 2152x1536 的双宽内显示屏。

除了巨大的屏幕尺寸差异外，提高像素密度的竞争也十分激烈。更高的像素密度可以提供更清晰的文本和更锐利的图形，从而提供更好的观看体验。目前像素密度领先的是索尼 Xperia XZ，它在仅 5.2 英寸对角线的屏幕上配备了 3840x2160 USH - 1 显示屏，像素密度达到 806.93 PPI，接近人眼能够区分的最大分辨率。

应用材料公司（Applied Materials）是 LCD 和 OLED 显示屏的领先制造商之一，他们对人眼在手持显示屏上对像素密度的感知进行了研究。结果发现，在距离眼睛 4 英寸的情况下，视力正常（20/20）的人能够区分 876 PPI。这意味着智能手机显示屏正在迅速接近像素密度的理论极限，但其他形式的设备（如虚拟现实头戴设备）可能会进一步推动这一密度的提升。

5.2 Android 屏幕分辨率分类

为了处理像素密度的变化，Android 将屏幕分为以下像素密度范围：
| 分类 | 像素密度 | 缩放比例 | 适用设备示例 |
| ---- | ---- | ---- | ---- |
| ldpi | ~120dpi |.75x | HTC Tattoo、Motorola Flipout、Sony X10 Mini（240x320 像素） |
| mdpi | ~160dpi | 1x | HTC Hero、Motorola Droid |
| tvdpi | ~213dpi | 1.33x | Google Nexus 7（电视用，非主要密度组） |
| hdpi | ~240dpi | 1.5x | HTC Nexus One、Samsung Galaxy Ace |
| xhdpi | ~320dpi | 2x | Sony Xperia S、Samsung Galaxy S III、HTC One |
| xxhdpi | ~480dpi | 3x | Google Nexus 10（平板形式，原 300dpi 需大图标） |
| xxxhdpi | ~640dpi | 4x | Nexus 6、Samsung S6 Edge |

5.3 确保应用跨分辨率工作的最佳实践

为了给最终用户提供最佳的体验，确保应用程序在各种可用分辨率下外观和行为一致非常重要。由于屏幕分辨率种类繁多，简单地为每个分辨率硬编码应用程序是不够的。以下是一些最佳实践：
- 始终使用密度独立和可缩放像素 ：
- 密度独立像素（dp） ：这是一种根据设备分辨率进行调整的像素单位。对于 mdpi 屏幕，1 像素（px） = 1 dp。对于其他屏幕分辨率，px = dp * (dpi / 160)。
- 可缩放像素（sp） ：用于文本或其他用户可调整大小的元素的可缩放像素单位。它从 1 sp = 1 dp 开始，并根据用户定义的文本缩放值进行调整。
- 为所有可用分辨率提供备用位图 ：Android 允许通过将备用位图放在名为“drawable -?dpi”的子文件夹中来为不同分辨率提供备用位图，其中“?dpi”是支持的密度范围之一。对于应用图标，应使用名为“mipmap -?dpi”的子文件夹，这样在构建特定密度的 APK 时，资源不会被删除，因为应用图标通常会被放大到设备分辨率以上。
- 尽可能使用矢量图形 ：Android Studio 提供了一个名为“Vector Asset Studio”的工具，它允许将 SVG 或 PSD 转换为 Android 矢量文件，可作为应用程序中的资源使用。

5.4 应用适配屏幕分辨率策略流程图

graph LR
    A[使用密度独立和可缩放像素] --> B[提供备用位图]
    B --> C[使用矢量图形]
    C --> D[应用在不同分辨率屏幕正常显示]

综上所述，在代码安全和移动应用开发领域，无论是代码安全分析、移动应用更新策略，还是应对 Android 设备碎片化和屏幕差异等问题，都需要开发者采取相应的有效措施，以确保应用的安全性、稳定性和良好的用户体验。