NIST Special Publication 800-163 Revision 1

审核移动App的安全性

迈克尔·奥加塔

软件与系统部信息技术实验室

文森特Sritapan

美国国土安全部科技办公室

乔希富兰克林*

应用网络安全部门信息技术实验室

Stephen Quirolgico

美国国土安全部首席信息官办公室

杰弗里沃纳斯

计算机安全部信息技术实验室

*前雇员; 本出版物的所有工作都是在NIST完成的

本出版物免费提供：https：//doi.org/10.6028/NIST.SP.800-163r1

2019年4月

1简介

移动App（或应用程序）对组织产生了变革性影响。通过不断增加的功能，无处不在的连接以及对关键任务信息的快速访问，移动App继续为促进组织目标提供前所未有的支持。尽管它们具有实用性，但由于其软件中可能存在的漏洞，这些App可能给组织及其用户带来严重的安全风险[1].这些漏洞可能被利用来窃取信息，控制用户的设备，耗尽硬件资源或导致意外应用或设备行为。

App漏洞是由多种因素引起的，包括设计缺陷和编程错误，这些因素可能是有意或无意插入的。在App市场中，包含漏洞的应用程序普遍存在，部分原因是开发人员提交App，这些App可能会交换安全功能以降低成本并缩短上市时间。

由移动操作系统供应商（Android，iOS）提供的商业App商店在允许托管之前检查App是否存在诸如恶意软件，令人反感的内容，收集用户信息而不通知，性能影响（例如，电池）等问题在他们的应用市场。对消费者和联邦政府来说，所进行的审查级别和类型是不透明的。此外，这些App市场为数十亿的全球客户群提供服务，他们对App的评论以消费者和品牌为中心。计划将消费者App用于其业务的企业组织-联邦机构，受监管行业和其他非政府组织-将需要根据自身的安全性，隐私和政策要求以及风险承受能力，为App获取做出基于风险的决策。

与漏洞相关的风险级别取决于多种因素，包括App可访问的数据。例如，访问诸如精确和连续地理定位信息，个人健康指标或个人身份信息（PII）等数据的App可能被认为比不访问敏感数据的App具有更高的风险。另外，依赖于无线网络技术（例如，Wi-Fi，蜂窝，蓝牙）进行数据传输的应用也可能具有高风险，因为这些技术也可以用作远程攻击的向量。然而，即使被视为低风险的应用，如果被利用也会产生重大影响。例如，由于漏洞利用而失败的公共安全App可能会导致生命危险。

为了降低与移动App相关的潜在安全风险，组织应采用软件保障流程，以确保软件没有漏洞的信心，无论是故意设计到软件中还是在其生命周期的任何时间意外插入，以及软件以预期的方式运行[2]。在本文档中，我们为移动App定义了一个软件保障过程。我们将此流程称为app审核流程。

1.1目的

本文档定义了App审查流程，并提供了以下方面的指导：（1）规划和实施App审查流程;（2）开发移动App的安全要求;（3）确定用于测试移动App的适当工具;（4）确定移动App可以在组织的移动设备上部署。提供软件保障专业人员常用技术的概述，包括测试离散软件漏洞和与移动App相关的错误配置的方法。

1.2范围

移动App的软件保障活动可能发生在移动App生命周期的一个或多个阶段：（1）在开发人员开发App期间（即App开发阶段），（2）在收到开发App但是 在由最终用户组织部署之前（即，App获取阶段）或（3）在由最终用户组织部署App期间（即，App部署阶段）。移动App生命周期的这三个阶段如图1所示。

图1- 移动App生命周期中的软件保障。

在本文档中，我们主要关注App审查过程的软件保障活动，我们将其定义为移动App生命周期的App获取阶段的一部分。因此，在App的开发阶段（例如，通过源代码分析器）或在App的部署阶段期间（例如，通过终端解决方案）执行的软件保证活动被认为超出了本文档的范围。

最后，应该注意的是，移动App及其运行的设备使用各种网络基础设施进行通信：Wi-Fi，蜂窝网络，蓝牙等。这些网络代表了App安全性可能的失败点。对这些网络基础结构的深入评估超出了本文档的范围。

1.3目标读者

本文档适用于寻求改进部署在移动设备上的App来保障公共和私营部门组织。更具体地说，本文档适用于以下人员：

•负责建立组织的移动设备安全状况，

•负责组织内移动设备的管理和安全，

•负责确定组织内使用App，以及

•有兴趣了解App审查流程提供的保证类型。

1.4文件结构

本文档的其余部分分为以下几个部分：

•第2节 - App安全要求

•第3节 - App审核流程

•第4节 - App测试方法和漏洞分类器

•第5节 - App审核注意事项

•第6节 - App审核系统

•附录A-移动App的威胁

•附录B-Android App漏洞类型

•附录C- iOS App漏洞类型

•附录D-缩略语和缩略语

•附录电子术语表

•附录F-参考

1.5文件约定

专门为移动平台编写的应用程序在本特刊中称为“apps”。

2 App安全要求

在审核移动App以确保安全性之前，组织需要定义App必须满足的安全要求才能获得组织批准使用。在本文档中，我们定义了组织应开发的两种类型的应用安全要求：一般和组织特定。

2.1一般要求

一般应用安全要求定义应该或不应该存在的软件的应用和行为特征，以确保应用的安全性。这些要求被认为是“一般性的”，因为它们可以应用于所有移动App，并且可以满足组织的安全需求和风险承受能力。一般App安全要求可能源自许多可用标准，最佳实践和资源，包括NIAP，OWASP，MITRE和NIST[2]指定的那些。

2.1.1国家信息保障合作伙伴关系（NIAP）

NIAP保护配置文件（PP）为满足特定联邦客户需求的一类信息技术（IT）产品指定了一组独立于实现的安全要求。具体而言，NIAP PP旨在用于认证在国家安全系统中使用的产品，以满足一组明确的安全要求。NIAP PP认证产品也被联邦组织用于非国家安全系统。NIAP PP详细定义了产品评估必须满足的安全目标，要求和保证活动，以便被国际标准化组织（ISO）/国际电工委员会（IEC）15408认证认可[6]。虽然许多移动App超出了ISO / IEC 15408认证要求的定义范围，但这些App的安全性分析仍然有用。对于这些App，NIAP建议在App软件保护配置文件[7]中审核移动App的要求中定义的一组活动和评估。本文档中定义的要求分为两大类：

1）功能要求-关于是否存在软件特定行为或属性的声明。

2）保证要求-关于评估者必须采取的行动声明或必须为审查成功执行的规定。

表1总结了NIAP的功能要求。[3]

表1 -  NIAP功能要求

功能要求

访问平台资源

反编译能力

密码密钥功能

加密操作

敏感App数据的加密

安全超文本传输协议（HTTPS）

安装和更新的完整性

网络通讯

传输中的数据保护

随机比特生成

默认配置安全

软件识别和版本

管理职能规范

存储凭证

支持的配置机制

传输层安全操作

使用支持的服务和App编程接口

使用第三方库

用户同意传输个人身份信息

X.509功能

保护配置文件中的保证要求可归纳如下：

• App应标有唯一的参考。

• 评估者应测试评估目标（TOE）安全功能（TSF）的子集，以确认TSF按规定运行。

• 该App应适合于测试（免于混淆[4]）

• 评估人员应搜索公共领域资源，以识别TOE中的潜在漏洞。

开放式WebApp安全项目（OWASP）维护有关移动App测试和安全性的多种有用资源。他们的移动应用安全验证标准（MASVS）[8]是移动应用安全的详细模型，可用于为组织提供基线安全要求。与NIAP PP一样，MASVS定义了一组关于App结构和行为的声明。但是，MASVS还定义了三个验证级别：

• 标准安全（1级）

• 深度防御（2级）

• 抵御逆向工程和威胁的能力（3级）。

每个级别的控制列表分为下面列出的类别，每个控件描述的对象取决于所需的验证级别：

• 架构，设计和威胁建模要求

• 数据存储和隐私要求

• 加密要求

• 身份验证和会话管理要求

• 网络通信要求

• 平台集成要求

• 代码质量和构建设置要求

• 弹性要求

OWASP移动安全测试指南（MSTG）[9]是一本测试移动App安全性的手册。它描述了验证MASVS中列出的要求的技术过程。

2.1.3 MITRE App评估标准

2016年，MITRE公司（MITRE）对移动App安全审查解决方案的有效性进行分析，以帮助企业自动化部分审查流程。为了进行分析，MITER基于NIAP的应用软件保护配置文件制定了解决方案标准，以及解决更广泛的App审查解决方案功能，针对App审查解决方案本身的威胁以及其他常见移动App漏洞和恶意行为的其他标准。

根据其标准，MITRE开发或获得了多个易受攻击和恶意出现的App，用于评估移动App审查解决方案。 MITER使用这些应用来测试移动App审查解决方案的功能。

MITER发布了一份技术报告[10]，描述了他们的方法，评估标准，测试应用以及分析当时可用解决方案的总体结果。报告和测试App可在MITRE的GitHub站点上获得[5]。

2.1.4 NIST SP 800-53

NIST特刊800-53 [5]为联邦信息系统提供了广泛的安全和隐私控制目录。此外，该文件还定义了一个流程，用于选择控制措施，以保护IT系统，个人和其他组织资产免受各种威胁，如敌对的网络攻击，自然灾害，结构故障和人为错误。可以根据组织特定的流程自定义控件，以管理信息安全和隐私风险。这些控件可以支持组织所需的策略，标准和/或业务需求中的各种安全和隐私要求。基于高，中，低影响提供一组三个安全控制基线。此外，该出版物还描述了如何开发专门的控制集，也称为控制覆盖，可以针对独特或特定类型的任务/业务功能和技术进行定制。NIST SP 800-53安全控制从功能角度（提供的安全功能和机制的优势）和保证视角（对实施的安全功能的信心度量）来解决隐私和安全问题。解决安全功能和安全保障确保信息技术产品和使用完善系统和安全工程原理从这些产品构建的信息系统足够值得信赖。

2.2组织特定要求

组织特定的安全要求定义了组织必须遵循的策略，法规和指南，以确保组织的安全状况。示例包括禁止社交媒体App在组织的移动设备上安装，并限制特定供应商开发的App的安装。

为了帮助制定组织特定的安全要求，有助于识别可能影响移动App安全状况的与漏洞相关的因素。可以通过考虑表2中所示的标准来推导出这些因素。

表2-组织特定的安全标准。

标准	描述
政策	安全，隐私和可接受的使用政策;社交媒体指南和适用于组织的法规。
出处	开发人员，开发人员组织，开发人员声誉，消费者评论等身份。
数据敏感性	App收集，存储或传输的数据的敏感性。
App 级别	App相对于组织业务的重要性级别。
目标用户	App来自组织的预期用户组。
目标硬件	部署App的预期硬件平台。
目标操作平台	操作系统，操作系统版本/软件开发工具包（SDK）以及将部署App的配置。
目标环境	App的预期操作环境（例如，一般公共使用与敏感军事环境）。
电子签名	应用于app二进制文件，库或包的数字签名
App文档	用户指南	App的用户指南通过指定预期功能和预期行为来协助测试。这只是开发人员的一个声明，描述了他们声称App做了什么以及它是如何做到的。
	测试计划	审查开发人员的测试计划可能有助于通过识别未经测试或测试不充分的任何区域来集中审查App。开发人员可以选择在某些情况下提交测试基准以演示其内部测试工作。
	检测结果	代码审查结果和其他测试结果将指出遵循哪些安全标准。例如，如果创建了App威胁模型，则应提交此标准。它将列出已确定并应在App设计和编码期间解决的弱点。
	服务级别协议	如果App是由第三方为组织开发的，则服务级别协议（SLA）可能已作为供应商合同的一部分包含在内。此合同应要求App与组织的安全策略兼容。

在某些情况下，可以从App文档中收集一些信息，但即使存在文档，也可能缺乏技术清晰度和/或使用特定于通常购买App的用户圈子的术语。由于不同App的文档会以不同方式构建，查找此信息以进行评估可能也非常耗时。因此，标准化问卷可能适用于确定软件的目的和评估App开发人员解决安全漏洞的努力。此类调查问卷旨在通过帮助开发人员解决最终用户/采用者关于其软件开发过程的问题来识别软件质量问题和安全漏洞。例如，开发人员可以使用美国国土安全部（DHS）定制软件问卷[11]来回答诸如“您的软件是否验证来自不受信任资源的输入？”和“在为您的软件设计保护时做出了哪些威胁假设？”之类的问题？另一个有用的问题，不包括在国土安全部调查问卷中，是：“您的App是否访问网络App编程接口（API）？”请注意，此类调查问卷只能在某些情况下使用，例如源代码可用时和开发人员可以回答问题。

App设计和编码中的已知缺陷可能会在公共可访问的漏洞数据库中报告，例如美国国家漏洞数据库（NVD）。[6]在对公开App进行完整的审查过程之前，分析人员应检查一个或多个漏洞数据库以确定是否存在相应版本的App中存在已知缺陷。如果已经发现一个或多个严重缺陷，仅此发现足以为组织拒绝使用该App版本提供充分理由，从而允许跳过其余的审查过程。但是，在大多数情况下，这些缺陷不为人所知，并且需要进行全面的审查。这种必要性是因为除了App设计和编码中的已知缺陷之外，还存在许多形式的漏洞。确定这些弱点需要首先定义App安全要求，以便将这些要求的偏差标记为弱点。

在某些情况下，组织没有明确的特定组织要求。因此，分析师将仅根据测试工具的报告和风险评估来评估应用的安全状况。

请注意，满足或违反组织特定要求并非基于软件漏洞的存在与否，因此通常无法通过测试工具确定。相反，满足或违反组织特定要求必须由分析师手动确定。

2.3风险管理和风险容忍度

NIST风险管理框架（RMF）代表了由NIST，国防部（DoD）和国家安全系统委员会（CNSS）牵头的联合努力。 RMF描述了一个组织建立，维护和传达策略以管理与信息系统相关的组织风险的过程[13]。RMF是一个包含以下步骤的七步流程：

•步骤0：准备 - 识别组织内的关键人物及其分配的角色，以及所需资源的识别，组织和优先级

•步骤1：分类 - 根据法律，政策，指令，法规，标准和组织使命/业务/运营要求对系统进行分类，确定与系统相关的安全要求

•步骤2：选择 - 确定与组织的风险承受能力相匹配的基准安全控制集

•步骤3：实施 - 实施和记录所选控制

•步骤4：评估 - 检查有关组织要求的安全控制的实施

•步骤5：授权 - 使系统能够在组织内使用

•步骤6：监控 - 对所选安全控制进行持续和/或重复的重新评估

图2描述了RMF步骤之间的关系，并显示了每个步骤的相应支持文档：

图2 - 风险管理框架

步骤0中的关键活动涉及识别组织的风险承受能力[14]。风险承受能力是组织可接受的风险水平或不确定程度[15]。定义的风险承受能力级别确定组织应受到保护的程度，以防止机密性，完整性或可用性受损。

风险承受能力应考虑以下因素：

• 遵守安全法规，建议和最佳实践;

• 隐私风险;

• 安全威胁;

• 数据和资产价值;

• 行业和竞争压力; 和

• 管理偏好。

3 App 审核流程

App审查过程是组织执行的一系列活动，用于确定移动App是否符合组织的App安全要求[7]。如果发现App符合组织的App安全要求，则通常会接受该App在组织的设备上进行部署。App审核流程概述如图3所示。

图3 - App审核流程概述。

虽然App审查流程可能因组织而异，但流程的每个实例都应该是可重复，高效和一致。该过程还应尽可能地限制错误（例如，假阳性结果）。通常，app审核过程是手动执行的，或由app审核系统执行，该系统管理和自动化全部或部分app审核活动[16]。作为App审查系统的一部分，可以使用一个或多个测试工具来分析App是否存在与恶意软件一致的软件漏洞或恶意行为。

如图1所示，组织在移动App生命周期的App获取阶段执行App审查过程; 也就是说，当组织收到App并在设备上部署之前进行。这种方法的基本原理是，虽然开发人员可以在App上执行自己的软件保障流程，但无法保证App符合组织的安全要求。此外，由于开发人员对App的测试发生在审查过程之外，因此组织必须信任这些先前执行的保证活动的工作。组织不应假设App已经过完全审查或符合其安全要求，因为它可以通过官方App商店获得。

需要注意的是，当组织与App开发人员建立密切关系时，如果组织紧密的如图3所示将App审核→拒绝→供应商反馈→app审批的核心环能嵌入应用开发者的测试基础设施加速。也就是说，组织可以利用现代敏捷软件开发模型[17]来更好地满足其安全要求。

在移动设备上部署执行App之前审查流程可提供的好处包括可以利用可扩展计算资源的严格而全面的分析。此外，由于测试在部署之前进行，因此审查过程不受用于补救已发现威胁的时序约束的限制。但是，虽然本文档侧重于在组织的App获取阶段审核移动App，但NIST建议组织还在部署阶段使用移动设备上的端点解决方案执行安全性分析。

App审核流程包括四个子流程：App入口，App测试，App批准/拒绝以及结果提交流程。这些过程如图4所示。

图4 - app审核流程的四个子流程

3.1 App Intake

App Intake过程在收到App进行分析时开始。此过程通常由组织管理员手动执行，或由App审查系统自动执行。App引入过程有两个主要输入：正在考虑的App（必需）和其他测试控件，例如以前的App审查结果的报告（可选）。

在收到App后，可以通过记录有关App的信息来注册App，包括开发人员信息，提交时间和数据以及App审查过程所需的任何其他相关信息。注册后，也可以对App进行预处理。预处理通常涉及解码或反编译应用以提取所需的元数据（例如，应用名称，版本号）并确认应用可以被正确解码或反编译，因为测试工具可能需要在执行其分析之前执行该操作。

除了App本身，App开发人员还可以选择提供软件保障工件，包括以前的安全分析报告。应该注意的是，接受这些控件的组织必须接受App开发人员所说的控件制作的App质量语句的有效性和完整性。

3.2App测试

App测试过程在App注册和预处理后开始，并转发到一个或多个测试工具。测试工具是一种软件工具或服务，用于测试App是否存在软件漏洞[8]。这种测试将涉及使用不同的分析方法（例如，静态分析），并且可以手动或自动执行。请注意，测试工具执行的测试可能会识别不同App中常见的软件漏洞，并且通常会满足一般App安全要求（例如NIAP指定的那些要求）。

测试App后，测试工具将生成一个报告，以识别任何检测到的软件漏洞或可能有害的行为。此外，该报告通常还会包含一个分数，用于度量检测到的漏洞或行为将被利用的可能性以及检测到的漏洞可能对应用或其相关设备或网络产生的影响。请注意，测试工具可能会生成符合现有标准（如NIAP）的报告。进一步注意，一些测试工具将能够检测违反一般应用安全要求但不违反特定组织的政策，法规等。

图5显示了典型测试工具的工作流程。当测试工具收到某个App时，它通常会保存为工具供应商服务器上的文件。如果测试工具是静态的（即，分析App的代码），则App通常从其二进制可执行形式解码，反编译或解密为可以分析的中间形式。[9]如果测试工具是动态的（即， 分析App的运行时行为），App通常在设备或模拟器上安装和执行，可以分析App的行为。在该工具分析App后，它会生成漏洞报告和风险评估，并将此报告提交给app审核系统。

图5-测试工具工作流程

3.3App批准/拒绝

在测试工具生成漏洞和风险报告并将其提供给一个或多个安全分析师之后，App批准/拒绝流程即开始。安全分析师（或分析师）检查来自一个或多个测试工具的漏洞报告和风险评估，以确保App满足所有常规安全要求。分析师还将评估特定组织的应用安全要求，以确定应用是否违反任何安全策略或法规。在评估了所有常规和组织特定的应用安全要求之后，分析师会将此信息整理到报告中，该报告指定批准或拒绝应用在组织的移动设备上部署的建议。

然后，分析师的推荐报告可供授权官使用，授权官是组织负责确定在组织的移动设备上部署哪些App的高级官员。授权官使用分析师提供的建议决定批准或拒绝App，并考虑其他组织特定（非安全相关）标准，包括成本，需求等。分析师可能会对某些调查结果添加潜在的缓解控制措施，例如使用每个App的虚拟专用网络（VPN）来保护传输中的数据。在进行App确定时，授权官员会考虑这些缓解措施以及App生成或访问的数据的敏感性，用户类型以及App的使用方式，拥有和管理设备的人员以及App是否可以访问-结束系统或数据（参见风险管理框架的第1步[13]）。这些分析报告描述了App的安全状态以及可能与其他非安全相关的要求。组织的正式批准或拒绝在最终批准/拒绝报告中指定。图6显示了应用批准/拒绝流程。

图6 - App批准/拒绝流程

3.4结果提交

结果提交过程在授权官确定最终App批准/拒绝报告之后开始，并且控件准备好提交给请求源。这些控件可能包括最终批准/拒绝报告，测试工具报告以及可能的数字签名版本的App，表明App已完成审核过程。使用数字签名提供源身份验证和完整性保护，证明分析的App版本与最初提交的版本相同，并且未经过故意修改。

3.5 App 再审核

移动App的威胁形势是一个不断变化的目标。随着时间的推移，会发现新的漏洞。同样，用于识别它们的工具也试图跟上步伐。因此，可以在App生命周期的任何时刻在App中发现漏洞，甚至可以在部署后发现漏洞。此外，当前的移动App开发范例允许App接收多个更新和补丁，这些更新和补丁可添加功能，提供错误修复和修补程序漏洞。从安全分析师的角度来看，这些更新可以强制将更新的App的评估视为全新的软件。根据组织的风险承受能力，这可以使移动App的重新审核对某些App至关重要。组织需要为触发App重新审核的条件建立协议。对这些触发器的完整分析超出了本文档的范围。但是，组织在制定重新审核政策时应考虑以下因素：

• 根据组织的风险承受能力，未定期更新的App可以定期（例如每季度，每两年，每年）进行重新审核，以便从改进的分析工具和技术中受益。

• 组织可以利用与App开发人员的业务关系，这些App开发人员可以使用构建App来了解App更新可能影响App风险状

• 如果组织策略允许/强制执行，源自商业应用商店的应用可以自动接收更新。这可以通过允许设备直接从其各自的应用商店提取应用更新，或者通过使移动应用管理（MAM）[10]软件将更新的应用推送到注册的设备来实现。这些行动可以大大改变组织的风险状况。

理想情况下，在允许安装之前，组织可以在更新后跟踪和分析所有App;但是，这是资源密集型的，并且会给用户带来延迟。一些App安全供应商通过自动跟踪已安装的App和更新的安全性分析，为组织的托管App提供“持续移动App审查”。虽然这种做法不会阻止推送到设备的应用更新，但它确实减少了潜在易受攻击的更新应用的曝露窗口。

4 App测试和漏洞分类器

在App测试过程中，测试工具用于测试App是否存在漏洞和恶意行为。通常，此类工具基于NIAP等标准，因此可用于确定一般应用安全要求的满足度。本节介绍测试工具和服务用于分析移动App漏洞的一些策略和方法。它还描述了用于描述漏洞的各种分类器和量化。

4.1测试方法

测试工具采用多种不同的分析技术，包括正确性测试，源代码或二进制代码分析，静态或动态分析的使用，以及手动或自动App测试。

4.1.1正确性测试

测试App的一种方法是软件正确性测试[18]。软件正确性测试是执行程序以检测错误的过程。虽然软件正确性测试的目标是改进质量保证以及验证和证实所描述的功能或估计可靠性，但它也可以帮助揭示潜在的安全漏洞，这些漏洞通常会对软件的质量，功能和可靠性产生负面影响。例如，崩溃或表现出意外行为的软件通常表示存在安全漏洞。软件正确性测试的主要优点是传统上它基于要测试的软件的规范。这些规范可以转换为需求，指定软件在进行测试时的行为方式。这与通常要求测试人员自己推导需求的安全评估方法不同;这些要求通常主要基于许多不同软件控件中常见的安全要求，并且可能无法测试被测软件特有的漏洞。尽管如此，由于安全性和质量，功能和可靠性之间的紧密耦合，建议尽可能执行软件正确性测试。

4.1.2源代码和二进制代码测试

执行App测试的一个主要因素是源代码是否可用。通常，从应用商店下载的应用无法访问源代码。当源代码可用时，例如在开源App的情况下，可以使用各种工具来分析它。源代码审查的目标是查找源代码中的漏洞并验证测试工具的结果。即使使用自动化辅助工具，分析也是劳动密集型的。使用自动化静态分析工具的好处包括引入不同评审之间的一致性并对大型代码库进行可能的评审。审核人通常应使用自动化静态分析工具，无论他们是进行自动审核还是人工审核，他们应根据常见弱点列举（CWE）标识符或其他一些广泛接受的术语表达其发现。执行安全代码审查需要在App安全性方面进行软件开发和特定于域的知识。组织应确保执行源代码审查的个人具备所需的技能和专业知识。

打算在内部开发App的组织也应参考有关安全编程技术和软件质量保证流程的指南，以适当地解决整个软件开发生命周期[19][20]。

当App的源代码不可用时，可以分析其二进制代码。在App的上下文中，术语“二进制代码”可以指代字节代码或机器代码。例如，Android App被编译为在虚拟机上执行的字节代码，类似于Java虚拟机（JVM），但它们也可以带有以机器代码形式提供的自定义库，即执行的代码直接运行在移动设备的CPU上。 Android二进制App包含可使用模拟和虚拟环境在无需硬件支持的情况下进行分析的字节码。

4.1.3静态和动态测试

分析工具通常表征为静态或动态。[1]静态分析检查App源代码和二进制代码，并尝试推断可能在运行时出现的所有可能行为。它提供了一定程度的保证，即无论输入或执行环境如何，分析结果都能准确描述程序的行为。动态分析通过使用一组输入用例执行程序并分析程序的运行时行为来运行。在某些情况下，输入测试用例的大量枚举会导致处理时间过长。但是，组合测试等方法可以减少动态输入测试用例组合的数量，减少导出分析结果所需的时间[22]。但是，动态分析不太可能提供100％的代码覆盖率[23]。组织应考虑静态和动态工具之间的技术权衡差异，并根据组织的软件保障目标平衡其使用。

静态分析要求在源代码不可用时对二进制代码进行逆向工程，这对于字节代码[2]来说相对容易，但对于机器代码来说可能很困难。许多商业静态分析工具已经支持字节码，就像许多开源和学术工具一样。[3]对于机器代码，特别难以跟踪许多函数的控制流并跟踪变量中的数据流，因为大多数变量都是存储在能够以不同方式访问的匿名内存位置。逆向工程机器代码的最常用方法是使用反汇编程序或反编译程序尝试恢复原始源代码。如果逆向工程的目的是允许人类检查代码，这些技术特别有用，因为输出的形式可以被具有适当技能的人理解。然而，即使是最好的反汇编者也会犯错误[25]。如果代码是针对静态分析进行逆向工程的，则最好将机器代码直接反汇编为静态分析器理解的形式，而不是将人类可读代码创建为中间副产品。针对机器代码的静态分析工具可能会使此过程自动化。

与静态分析相比，最重要的动态分析要求是查看代码执行时的工作情况。获取此信息有两种主要方法。首先，执行的App可以连接到远程调试器。其次，代码可以在具有内置调试功能的仿真器上运行。在预期的移动设备上运行代码允许测试工具选择设备的确切特征，并可以提供有关App行为方式的更准确的视图。另一方面，仿真器提供更多控制，尤其是当仿真器是开源的并且可以由评估器修改以捕获所需的任何信息时。虽然仿真器可以模拟不同的设备，但它们并不能模拟所有设备，因此仿真可能不完全准确。请注意，恶意软件会越来越多地检测仿真器作为测试平台的使用，并相应地更改其行为以避免检测。因此，建议测试工具使用模拟和物理移动设备的组合，以避免使用反检测技术的恶意软件的假阴性。

即使不了解各个功能的目的，也可以通过观察App的行为来收集有用的信息。例如，测试工具可以观察App如何与其外部资源交互，记录它从操作系统请求的服务及其执行的权限。虽然App使用的许多设备功能可能由测试工具推断（例如，相机App将需要访问设备的相机），但是可以允许App访问超出范围的其他设备功能。其描述的功能（例如，访问设备网络的相机App）。此外，如果针对特定输入观察app的行为，则评估者可以询问所执行的能力是否在这些特定输入的上下文中有意义。例如，日历App可以合法地拥有通过网络发送日历数据以在多个设备之间同步的权限，但是如果用户仅询问了当天约会的列表并且App发送的数据不是握手过程的一部分需要检索数据，测试工具可能会调查正在发送的数据以及用于何种目的。

4.2漏洞分类和量化

使用通用语言描述移动App中的漏洞是有利的。以下部分描述了一些用于识别，描述和衡量漏洞严重性的常用分类和量化。

4.2.1常见弱点枚举（CWE）

CWE是由MITRE公司维护的软件弱点分类系统[28]。CWE是软件弱点类别的通用语言。不同的编程语言可以创建相同软件错误的特定于语言的版本。CWE确保术语存在以引用不同语言中的相同错误，并为每个语言提供缓解策略。 CWE在全球工业，政府和学术界使用。

4.2.2常见漏洞和暴露（CVE）

CVE字典是软件漏洞的命名方案[12]，也由MITRE托管。识别漏洞后，可以将其报告给CVE编号机构，该机构为漏洞提供唯一的行业范围标识符。CVE被报告给NVD用于评分和描述。NVD是美国政府基于标准的漏洞管理数据库，用于收集，分析和存储描述特定计算机系统漏洞的数据。此外，NVD还托管安全检查清单，安全相关软件缺陷，错误配置，产品名称和影响指标的数据库。NVD广泛使用CWE和CVE来完成其使命。

4.2.3常见漏洞评分系统（CVSS）

通用漏洞评分系统版本（CVSS）是由事件响应和安全团队论坛（FIRST）[29]拥有和维护的漏洞评分系统。 CVSS模型尝试确保可重复且准确的测量，同时使用户能够查看用于生成数字分数的基础漏洞特征。需要准确一致的漏洞利用和影响分数的行业，组织和政府可以使用这种通用的测量系统。用于计算漏洞分数的算法对所有人开放，主要由人类分析师提供的三个度量类别的输入派生：基础，时间和环境。 CVSS的常见用途是计算漏洞修复活动的严重性和优先级。 NVD通过CVSS提供漏洞评分。

5 App 审核注意事项

本节介绍组织在建立App审核流程时应考虑的其他条件。

5.1托管和非托管App

企业App或部署在企业设备上的第三方App（或用于企业任务的个人设备）可在整个部署生命周期中进行管理，从初始部署和配置到从设备中删除App。管理这样的托管App可以使用企业移动App管理（MAM）系统来执行，该系统旨在使企业能够控制访问企业服务和/或数据的移动App。非托管（个人使用）App是不由MAM（或类似）系统管理的App。

仅管理App（而不是整个设备）的一个好处是，MAM系统不需要用户/所有者在企业管理下注册整个设备，所有者也不必接受在设备上安装企业配置文件。 MAM解决方案可以使企业将内部企业App目录与移动设备供应商的App Store（例如Apple的App Store，Google Play或Microsoft Store）集成，以允许移动用户轻松安装企业App。企业系统管理员可以部署App或向移动用户推出无线App更新;他们也可以在不影响整个设备的情况下限制App功能，这可能是自带设备（BYOD）用户的首选。某些移动设备管理（MDM）系统还包括MAM功能，可对单个受管设备上的不同App进行细粒度控制。MDM和MAM功能可用于限制托管和非托管App之间的企业数据流。

在设计用于管理移动App的移动解决方案，要求和策略时，企业应考虑托管和非托管App之间的权衡（此类安全要求的示例可在国防部首席信息官关于“移动App安全要求”的备忘录中找到[30]]）。权衡可能包括管理开销和额外成本与通过仅允许访问企业网络和服务的移动设备上的托管App获得的安全保证。

5.2应用白名单和应用黑名单

App白名单和黑名单是指允许或禁止基于预先指定的列表使用App，以防止安装恶意，易受攻击或有缺陷的App。NIST SP 800-53 Rev. 4 [31]在配置管理（CM）控制号CM-7下定义了这些控制增强功能，功能最少，如下所示：

• 增强功能CM-7（4）最低功能，未经授权的软件-黑名单是一种允许所有，拒绝异常的策略，禁止在系统上执行未经授权的软件程序。黑名单要求组织开发和维护未经授权的软件（App）列表

• 增强功能CM-7（5）最低功能，未经授权的软件-白名单是一种拒绝所有，允许例外的策略，允许仅在系统上执行授权的软件程序。这要求组织开发和维护授权软件（App）列表

白名单和黑名单都可以通过MAM / MDM软件得到增强和促进。对于联邦组织而言，重要的是要在本文件发布时注意，SP 800 53 Rev.4建议将中等基线分配系统列入黑名单，并为具有高基线分配的系统列入白名单。未来的800-53[4]修订版也可能建议在中等和高基线分配中列入黑名单和白名单。

5.3 App 审核限制

与任何软件保障流程一样，即使是最彻底的审查流程也无法保证发现所有潜在的漏洞或恶意行为。应该让组织了解尽管App安全评估通常会改善组织的安全状况，但是他们这样做的程度可能不容易或立即确定。还应使组织了解审查过程在安全性方面的作用和不提供的内容。

组织还应该在安全评估过程中了解人的价值，并确保他们的App审查不仅仅依赖于自动化测试。安全分析主要是人为驱动的过程[19][32]; 自动化工具本身无法解决构成软件安全性的许多上下文和细微差别的相互依赖性。最明显的原因是，充分理解软件行为是计算机科学中经典不可能出现的问题之一[33]，实际上当前的技术甚至还没有达到理论上可行的极限。无法通过自动化手段对复杂的多方面软件架构进行全面分析。

另外，当前的软件分析工具本身并不了解软件必须做什么才能在特定上下文中以安全的方式运行。例如，如果传输通过虚拟专用网络（VPN）进行隧道传输，则无法加密传输到云的数据可能不是安全问题。即使已正确预测并完全理解App的安全性要求，当前也没有技术可以明确地将人可读的需求转换为机器可以理解的形式。

出于这些原因，安全性分析需要人类分析师处于循环中，并且通过扩展，结果的质量取决于人类努力水平和可用于评估的专业知识。分析师应该熟悉软件安全评估的标准流程和最佳实践[19][34-36]。为了获得成功，强大的App审查流程应使用工具箱方法，其中多个评估工具和流程以及人员交互协同工作。由于每个工具的固有局限性，即使与人工交互，依赖于单一工具也是一个重大风险。

5.4本地和远程工具和服务

有许多专门用于分析移动App的工具和服务[37][38]。根据工具/服务提供商使用的模型，App分析可能发生在不同的物理位置。例如，可以在App所针对的组织的网络内安装和运行分析工具。其他供应商可能会在场外托管其测试服务。非现场工具可以驻留在工具/服务提供商的前提下，或者可以驻留在云基础设施中。在使用审查工具/服务之前，组织应该理解这些场景中的每一个，尤其是在App的代码库可能包含敏感或机密信息的情况下。

5.5自动批准/拒绝

在某些情况下，分析师为获得批准或拒绝App的建议而开展的活动可以自动化，特别是在不需要组织特定的政策，法规等的情况下。在这里，用于支持规则规范的App审查系统可以配置为根据多个工具的风险评估自动批准或拒绝App。例如，如果所有测试工具都认为App具有“低”风险，则可以将App审查系统配置为自动推荐App。同样，App审查系统可以配置为自动执行特定于组织的要求。例如，使用在预处理App期间提取的元数据，App审查系统可以自动拒绝来自特定供应商的App。

5.6互惠

互惠性涉及在App审查团队之间共享结果以减少返工;它发生在联邦机构的App审查流程中利用其他机构之前曾对同一个App进行App审查的结果时[39]。它使接收机构能够在部署App时自行确定风险，从而重用App测试结果。为了分享安全审查结果，测试机构以标准化的互惠报告格式针对一组共同的安全要求（例如，NIAP）捕获应用安全测试的结果，目的是使信息可供其他机构使用。

鉴于任何单个App可能具有的不同潜在用途以及不同代理商之间的不同移动架构，不建议共享风险决策（批准/拒绝）。另一种方法是将一个联邦机构进行的测试结果发给其他联邦机构，允许机构自己做出基于风险的决定，而不必重复其他机构已经进行的测试。这种组织对App共享的发现可以大大减少App审查其他组织的重复和成本。软件保障社区内的信息共享至关重要，可以帮助测试工具从全球安全专业人员的共同努力中受益。国家漏洞数据库（NVD）[40]是使用安全内容自动化协议（SCAP）[41]表示的基于标准的漏洞管理数据的美国政府存储库。此数据可实现漏洞管理，安全性测量和合规性的自动化。NVD包括安全检查表，安全相关软件缺陷，错误配置，产品名称和影响指标的数据库。SCAP是一套规范，用于标准化安全软件产品传达软件缺陷和安全配置信息的格式和术语。 SCAP是一种多用途协议，支持自动漏洞检查，技术控制合规性活动和安全性测量。开发SCAP的目标包括标准化系统安全管理，促进安全产品的互操作性，以及促进安全内容的标准表达的使用。CWE [28]和通用攻击模式枚举和分类（CAPEC）[42]集合可以提供有用的弱点列表和攻击方法来驱动二进制或实时系统渗透测试。分类和表达软件漏洞是软件保障社区中正在进行和正在开发的工作，以及如何在App中存在的各种弱点之间进行优先排序，以便组织可以知道那些对App构成最大危险的组织。鉴于各种可用工具和技术的有效性和覆盖范围的差异，审查活动解决了其预期用途/任务。

5.7工具报告分析

与报告和风险分析相关的一个问题源于由于不同测试工具使用的各种与安全相关的定义，语义，术语和指标而难以整理，规范化和解释不同的报告和风险评估。例如，一个测试工具可以将使用App的度量风险分类为低，中，高或严重风险，而另一个可以将度量风险分类为通过，警告或失败。虽然存在一些表达风险评估标准[5]和漏洞报告[6]，但目前采用这些标准的测试工具很少。在可能的范围内，建议组织使用利用漏洞报告和风险评估标准的测试工具。如果无法采用这种方法，建议组织为分析师提供有关测试工具生成的报告和风险评估解释的充分培训。

5.8合规性与认证

对于移动App审查，经常使用两个术语来证明成功实现移动App安全性要求的证据。对于已经开发出包含针对特定要求安全性的移动App（例如，国家信息保障合作伙伴关系-从App软件保护配置文件审查移动App的要求[7]），开发人员可以选择它们是合规的或经过认证的。差异取决于组织对合规性或认证的需求。

移动App安全性的合规性意味着自我证明或来自已经验证移动App满足此类安全要求的非官方第三方的证明。例如，企业可以选择使用他们自己内部开发的移动App审查流程来验证移动App的安全性和隐私性。通过他们自己的内部流程，批准移动App在其组织或其组织的移动资产中使用。

另一方面，认证意味着授权验证者的成功验证。例如，对于NIAP认证，必须遵循正式的NIAP验证流程。[7]在这种情况下，供应商可以选择经批准的通用标准测试实验室，根据适用的NIAP批准的保护配置文件进行产品评估。成功完成验证过程后，将授予正式认证并列在批准的产品列表中。

当成功授予认证时，NIAP会在产品兼容列表中列出产品[43]。这是官方列表，需要NIAP的官方认证才能在联邦信息系统中使用。应该注意的是，NIAP认证评估的认证要求可能不会直接映射到非联邦要求。对于受监管行业，例如金融和健康行业，组织应酌情遵守各自的合规要求。这种区别也可以扩展到州和地方组织。

5.9预算和人员配备

应用软件保障活动成本应包含在项目预算中，不应该是事后的想法。此类成本可能很高，需要包括分析师，审批人和管理员的测试工具和工资的许可成本。雇用承包商开发App的组织应指定App评估成本作为App开发过程的一部分。但请注意，对于内部开发的App，仅在开发工作结束时尝试实施App审查将导致成本增加和项目时间延长。强烈建议在开发过程中识别潜在的漏洞或弱点，以便原始开发人员仍能解决这些漏洞或漏洞。在开发过程中识别和修复错误也比在产品发布后修复错误要便宜得多[44]。

为了提供最佳的App审查流程实施，组织雇用具有适当专业知识的人员至关重要。例如，组织应雇用在软件安全和信息保障方面经验丰富的分析师以及在移动安全方面经验丰富的管理员。

6 应用审核系统

虽然可以手动执行app审查过程，但是使用app 审核系统（例如，DHS AppVet系统[16]）以半自动或全自动方式执行app审查过程通常是有利的。App审查系统是一个管理和自动化App审查过程的系统，可以实现为基于Web的服务，通常是包含测试工具/服务，App商店，EMM和用户的更大的App审查生态系统的一部分。

在将App部署到用户的移动设备之前，安全分析师（通常是企业系统管理员）使用App审查系统来识别App安全问题。系统分析App后，安全分析师会在较大的企业环境的安全状态的上下文中考虑审核结果，并提出安全建议。鉴于用户的角色，App解决的任务需求以及安全分析师的安全建议，授权官员随后决定是否批准使用App。图7描绘了app审核系统的参考架构。

图7-App审查系统架构示例。

图表的中心是app审核系统。系统是一个大App审查生态系统的中心枢纽。App审查系统协调所有其他系统组件，安全分析师和授权官员之间的请求和响应。审查系统的一个关键组成部分和功能是它作为App审查过程的长期学习和决策库。在图中，这由连接到app审核系统的数据库符号表示。该数据库应存储测试报告以及安全分析师和后续授权官员的输入。

寻求使用app的企业移动设备可以以多种方式这样做。企业可以托管仅包含经过审查的Ap在特定App商店。或者，该设备可以具有由企业移动性管理（EMM）系统强制执行的策略规则，该系统规定可以从任何源安装哪些应用。这些系统由图左上角的框表示。有关所请求App的信息（通常是App二进制代码，但有时是内部开发的App的App源代码）将从此系统发送到App审核协调中心以开始App审核过程

检查App和评估其安全特性有许多不同的策略。没有一种算法，工具或产品可以提供App安全特性的完整图片。参考体系结构显示了组织如何从多个（图中右侧显示）测试工具中获取输入，以便更好地通知安全分析师。在将App审查请求从App Store或EMM系统发送到审查中心后，集中系统会联系图中三个测试工具中的每一个。每个工具都会收到有关App的信息副本（例如，二进制代码或源代码），执行其独立评估并返回漏洞报告和某种形式的风险评分。

然后，审查中心收集各种测试工具报告的结果，可能会总结这些结果并在仪表板视图中将其提供给安全分析师。在审查各种测试结果后，安全分析师提交了一份建议，该建议由审查中心记录。然后，授权官员可以考虑安全分析师的建议以及任务需求来批准或拒绝移动用户使用该App。如果App被批准安装，则审查中心可以将数字签名的控件（包括经过数字签名的App）提供回App Store或EMM系统以启用App部署。

虽然该图描绘了本地托管的App审查系统（即App审查中心，测试工具，数据库和App Store被显示为驻留在主机上），但是许多App审查系统可以托管在云环境中。在云托管方案中，图中显示的框将由私有云或公共云服务提供商托管，并且大部分功能将被虚拟化。安全分析师和授权官无需知道如何实施审查系统。在任一类型的部署中，这些角色中的用户将通过提供适当服务和视图的仪表板与系统交互。这两种类型的部署都可以实现app审核系统的模块化扩展，以适应新的审查测试工具。

App审查系统使用App编程接口（API），网络协议和模式来与分布式部署第三方测试工具以及包括App商店在内的客户端集成。App审查系统还可以包括用户界面（UI）仪表板，其允许诸如管理员，分析员和授权官员的用户查看报告和风险评估，提供推荐并批准或拒绝App。图7显示了一个示例，说明如何使用API和UI的App审查系统来支持与App审查生态系统中的所有组件和用户的集成。

附录A-对移动App的威胁

与所有软件一样，移动App通常包含漏洞（由设计或实现中的错误或恶意引入），这些漏洞可能会使用户，移动设备及其数据或企业服务或其数据受到攻击。有许多常见类别的移动软件错误可能会产生此类漏洞，包括加密原语和其他安全服务的使用或实施中的错误，移动设备上软件组件之间的风险交互，以及移动设备与移动设备之间的风险交互。其环境中的系统。使用安全服务或加密的常见错误包括用户或系统的弱认证，加密原语的错误实现，选择过时或损坏的加密算法或参数，或者无法加密移动设备与Web或企业托管服务之间的应用流量。移动设备上软件组件之间的风险交互包括使用来自不可靠来源的数据作为安全敏感操作的输入，使用易受攻击的第三方提供的软件库，以及泄漏App外部敏感数据的App代码（例如，通过App活动的日志）。此外，移动系统可能通过与受损网络或企业服务的通信而暴露于恶意代码或数据注入。

在将移动App部署到用户的移动设备之前审核移动App可以使企业系统管理员检测可能产生漏洞或违反企业安全或隐私策略的软件或配置缺陷。移动App审查系统通常包括自动化测试和分析工具，并可与外部托管的审查服务进行交互。本节将讨论影响移动设备的不同类别的恶意软件。移动App审查系统旨在查找此类恶意软件的证据。

在考虑以下类别的移动App威胁的同时，识别不断变化的攻击格局非常重要。该清单并非详尽无遗，也不应作为评估审查解决方案，立法或安全态势的强度的决定性和/或规定性标题。相反，它旨在成为当前观察到的威胁的说明性列表。

A.1勒索软件

勒索软件是一种恶意软件，可以加密数据并保存解密密钥作为付款条件[45]。在移动环境中，已经观察到新的勒索软件[46]不仅加密了用户的数据，而且通过改变锁定屏幕PIN将它们锁定在他们的设备之外。这种勒索软件已经通过受到破坏的网站作为虚假软件更新传播。

A.2间谍软件

间谍软件[47]是一种恶意软件，旨在用户不知情的情况下收集有关个人或组织的信息，并将该信息发送给攻击者的系统。虽然间谍软件通常用于跟踪互联网用户在网络上的移动，它也可用于捕获短信服务（SMS）消息，照片，电话日志或敏感数据，如用户登录或银行信息。大多数间谍软件是在没有设备用户（或组织）知识的情况下安装的，通常使用诱骗用户进行安装的欺骗性策略。国家情报人员也使用间谍软件从移动用户那里收集信息[48]。

A.3广告软件

广告软件是嵌入广告中或作为广告的一部分加载的恶意软件，是全球移动设备最常见的威胁之一。移动广告有助于当前的移动生态系统，因为它们为提供免费移动应用的软件开发商提供资金来源。广告可能会从第三方网站提供，并且可能包含通常用于在未经用户许可或知情的情况下捕获个人信息的广告。最近的报告[49]显示，一些低端移动设备是从制造商那里预装的广告软件发货的。受影响手机的用户会遇到弹出式广告和其他恼人的问题，并且由于广告软件安装在固件级别，因此难以移除。

A.4 Rooting

“Rooting”是使用户能够在设备的操作系统（OS）^18[1]上获得特权（root）访问的过程。通常执行Rooting以克服运营商和设备制造商对某些移动设备实施的限制。Rooting可以更改或替换系统的App和设置，执行需要管理权限的专用App，或执行禁止运营商的操作。Rooting有两种类型[50]

• “软root”通常通过使用称为“root exploit”安全漏洞的第三方App执行。

• “硬root”需要刷新二进制可执行文件并提供超级用户权限。

在一些移动平台（例如，Android）上，存在超出Rooting的技术，其解锁设备引导加载程序以便于完全移除和替换设备的OS，例如，安装其更新或修改的版本。

A.5特洛伊木马

特洛伊木马（或特洛伊木马）是一种恶意软件，它伪装成合法且日常熟悉的软件，从而欺骗用户运行它。对于传统计算平台，攻击者通常使用具有众所周知扩展名的文件名来隐藏恶意软件，例如.doc或.jpg。用户打开特洛伊木马文件，恶意软件开始执行。在移动环境中，移动银行特洛伊木马是一种令人担忧的新趋势[51]，它描述了受害者响应似乎来自其银行的网络钓鱼邮件后安装的恶意软件。恶意软件收集财务信息，登录凭据以及有时信用卡信息。

A.6 信息窃取

信息输送器是一种特洛伊木马，它从受感染的系统收集包括机密数据在内的信息，并将其发送给攻击者的系统。被盗的最常见的信息类型包括用户凭证（例如，登录用户名和密码）或财务数据。信息输出器通常会影响传统的计算平台，但最近才开始影响移动平台。最近的报告[52]描述该恶意软件，它利用Android设备的Google Chrome更新并禁用了防病毒应用程序。恶意软件可以收集发送到远程服务器的用户银行信息，呼叫日志，SMS数据和浏览器历史记录。

A.7恶意下载器

恶意下载器是恶意软件，其主要目的是通常从Internet下载内容。下载的内容通常可能包括其他恶意App（通常由下载程序启动），下载程序或系统上安装其他软件的配置或命令，以及其他软件组件以便于攻击。例如，在2017年，攻击者使用嵌入垃圾邮件中的恶意PowerPoint演示文稿来发布银行特洛伊木马[53]。打开PowerPoint文件，只需将鼠标指针悬停在显示的超链接上-无需点击-导致PowerPoint执行下载特洛伊木马的恶意脚本。

A.8短信欺诈

现在通过电子邮件进行的诈骗是通过短信发送的。欺诈性商业交易，网络钓鱼（通过短信发送时称为“短信钓鱼”），虚假的捐款请求，索赔，彩票奖品的费用以及来自交友网站的所有短信诈骗[54]。用户必须警惕来自陌生人或未知号码的未经请求的文本，特别是对金钱或个人/敏感信息的请求。

A.9电话诈骗

电话欺诈是指一些恶意和非法活动。例如，蜂窝服务的一些用户可以接收看起来源自国内区域代码但实际上与国际按次付费服务相关联的呼叫。这些呼叫经常在一次响铃后断开。当目标返回呼叫时，如果受害者留在线路上，则他或她连接到国际线路，该线路收取连接费用以及每分钟的重拨费用。这些费用通常作为高级服务出现在受害者的手机账单上。

A.10中间人攻击（MITM）

中间人攻击（MiTM）被简单地定义为拦截两个系统之间通信的任何方法[55]。移动App特别容易受到这些类型的攻击，因为对它的主要防御的误用/错误配置：传输层安全性（TLS）。接受不受信任的SSL证书，允许使用较弱的TLS模式以及信任模型本身的漏洞可能使移动App容易受到MiTM攻击，从而导致潜在的信息泄露和隐私侵犯。

A.11收费欺诈

当移动设备用户拨打电话时发生收费欺诈-通常使用高级服务-向未授权呼叫的第三方收费。常见的攻击涉及黑客从基于网络的服务租用电话号码，该服务向每个呼叫的呼叫者收费，并向黑客提供一定比例的利润。为了实现利润丰厚的基于欺诈的业务，黑客破坏独立企业的IP语音（VoIP）网络，以便将呼叫转发给黑客的高级服务号码。独立公司对基于网络的服务的呼叫付费，黑客获得一定比例的利润。为了抵御这些类型的攻击，组织必须实施强大的网络安全保护。

附录B- Android App漏洞类型

本附录可识别特定于Android移动设备上运行的App漏洞。本附录的范围包括基于Android移动设备上运行使用Java编写的App漏洞。范围不包括移动平台硬件和通信网络中的漏洞。虽然下面描述的某些漏洞在移动设备环境中很常见，但本附录仅关注特定于Android的漏洞。

本附录中的漏洞分为三个层次级别：A，B和C。A级别称为漏洞类别，是该级别下指定的漏洞的最广泛描述。B级别被称为子类，并尝试将漏洞类的范围缩小为较小的通用的漏洞组。C级别指定已识别的各个漏洞。此层次结构的目的是引导读者尽快找到他们正在寻找的漏洞类型。

表3显示了Android App漏洞的A级一般类别。

表3 -  Android漏洞，A级。

类型	描述	不利后果
权限不正确	权限允许访问受控功能，如摄像头或全球定位系统（GPS），并在程序中请求。未经用户同意，可以隐式授予应用权限。	具有太多权限的App可能会执行App预期功能范围之外的非预期功能。此外，权限很容易被另一个App劫持。如果授予的权限太少，则App将无法执行所需的功能。
暴露的通信	内部通信协议是App在设备内部将消息传递给自身或其他App的方式。外部通信允许信息离开设备。	暴露的内部通信允许应用收集非预期的信息并注入新信息。暴露的外部通信（数据网络，Wi-Fi，蓝牙，近场通信（NFC）等）使信息对泄露或中间人攻击被公开。
暴露的数据存储	Android上的App创建的文件可以存储在内部存储，外部存储或密钥库中。使用外部存储权限的所有其他App可以读取和修改存储在外部存储中的文件。	敏感数据可能被其他App渗透或篡改，或无意中转移到备份中的另一个系统。应该注意，有些App需要此功能才能按预期运行。
潜在的危险功能	受控功能，可访问系统关键资源或用户的个人信息。此功能可以通过API调用或硬编码到App中。	意外功能可以在App功能范围之外执行。
应用合谋	两个或多个App相互传递信息，以便增加一个或两个App超出其声明范围的功能。	共谋可以允许应用获取非预期的数据，例如游戏应用获得对用户的联系人列表的访问权。
混淆	从用户隐藏或隐藏的功能或控制流。出于本附录的目的，混淆被定义为三个标准：外部库调用，反射和本机代码使用。	1.外部库可能包含意外和/或恶意功能。 2.反射调用可能会模糊App的控制流和/或破坏App内的权限。 3.本机代码（在Android中用Java以外的语言编写的代码）可以执行意外和/或恶意功能。
功耗过大	在有意或无意地耗尽电池的设备上运行的功能过多或意外的App。	缩短电池寿命可能会影响执行关键任务功能的能力。
传统软件漏洞	与传统Java代码相关的所有漏洞包括：身份验证和访问控制，缓冲区处理，控制流管理，加密和随机性，错误处理，文件处理，信息泄漏，初始化和关闭，注入，恶意逻辑，数字处理以及指针和引用处理。	常见后果包括意外泄露，资源耗尽，拒绝服务等。

表4显示了从A级到C级的AndroidApp漏洞的层次结构。

表4 - 按级别划分的Android漏洞。

级别A	级别B	级别C
权限不正确	过度授予	过度授予代码
		过度授权API
	授予	根据代码授予
		在API中授予
	开发人员创建的权限	开发人员在代码中创建
		开发人员在API中创建
	隐含权限	通过API授予
		通过其他权限授予
		通过继承授予
暴露的通信	外部通信	蓝牙
		全球定位系统
		网络/数据通信
		NFC接入
	内部通信	未受保护的意图
		未受保护的活动
		未受保护的服务
		未受保护的内容提供商
		未受保护的广播接收器
		调试标志
暴露的数据存储	过度暴露数据	过度暴露外部存储中的敏感数据
		过度暴露内部存储中可读数据
潜在的危险功能	直接寻址	内存访问
		互联网
	可能危险的API	财务敏感API
		个人信息API
		设备管理API
	特权升级	更改文件权限
		访问超级用户/root
应用合谋	内容提供者/意图	未受保护的内容提供商
		权限受保护的内容提供商
		待定意图
	广播接收器	关键消息的广播接收器
	数据创建/更改/删除	创建/更改/删除文件资源
		创建/更改/删除数据库资源
	服务数量	过度检查服务状态
混淆	库调用	使用潜在危险的库
		包含但未使用的潜在恶意库
	本地代码检测
	反射
	打包代码
功耗过大	CPU使用率
	I / O

附录C- iOS App漏洞类型

本附录确定并定义了特定于使用Apple iOS操作系统在移动设备上运行的App的各种类型的漏洞。范围不包括移动平台硬件和通信网络中的漏洞。虽然下面描述的某些漏洞在移动设备环境中很常见，但本附录侧重于iOS特定的漏洞。

本附录中的漏洞分为三个层次级别：A，B和C。A级别称为漏洞类别，是该级别下指定的漏洞的最广泛描述。B级别被称为子类，并尝试将漏洞类的范围缩小为较小的，通用的漏洞组。C级别指定已识别的各个漏洞。此层次结构的目的是引导读者尽快找到他们正在寻找的漏洞类型。

表5显示了iOS App漏洞的A级一般类别。

表5 - iOS漏洞描述，A级

类型	描述	不利后果
权限不正确	权限允许访问受控功能，如相机或GPS，并在程序中请求。未经用户同意，可以隐式授予应用权限。	具有太多权限的App可能会执行App预期功能范围之外的非预期功能。此外，权限很容易被另一个App劫持。如果授予的权限太少，则App将无法执行所需的功能。
暴露的通信 - 内部和外部	内部通信协议允许App处理信息并与其他App通信。外部通信允许信息离开设备。	暴露的内部通信允许应用收集非预期的信息并注入新信息。暴露的外部通信（数据网络，Wi-Fi，蓝牙等）使信息对披露或中间人攻击开放。
潜在的危险功能	受控功能，可访问系统关键资源或用户的个人信息。此功能可以通过API调用调用或硬编码到App中。	意外功能可以在App功能范围之外执行。
应用合谋	两个或多个App相互传递信息，以便增加一个或两个App超出其声明范围的功能。	共谋可以允许应用获取非预期的数据，例如游戏应用获得对用户的联系人列表的访问权。
混淆	从用户隐藏或隐藏的功能或控制流。出于本附录的目的，混淆被定义为三个标准：外部库调用，反射和封装代码。	1.外部库可能包含意外和/或恶意功能。 2.反射调用可能会模糊App的控制流和/或破坏App内的权限。 3.打包代码可防止代码逆向工程，并可用于隐藏恶意软件。
功耗过大	在有意或无意地耗尽电池的设备上运行的功能过多或意外的App。	缩短电池寿命可能会影响执行关键任务功能的能力。
传统软件漏洞	与Objective C和其他相关的所有漏洞。这包括：身份验证和访问控制，缓冲区处理，控制流管理，加密和随机性，错误处理，文件处理，信息泄漏，初始化和关闭，注入，恶意逻辑，数字处理和指针和参考处理。	常见后果包括意外产出，资源耗尽，拒绝服务等。
暴露的数据存储	iOS上的所有文件和钥匙串项都分配了数据保护类。这些指示项目是否1）在设备被锁定时可访问，2）在关联的App关闭时可访问，以及3）项目是否可以转移到另一个设备。	在未使用或无意中将敏感数据传输到备份中的另一个系统时，敏感数据在文件系统上的保护较少。但是，限制此机制的使用可能会削弱App执行所需功能的能力

表6显示了从A级到C级的iOS App漏洞的层次结构。

表6 - 按级别的iOS漏洞。

级别A	级别B	级别C
权限不正确	敏感的信息	联系人
		日历信息
		任务
		提醒
		相片
		蓝牙访问
暴露的通信	外部通信	电话
		蓝牙
		GPS
		SMS / MMS
		网络/数据通信
	内部通信	滥用协议处理程序
暴露的数据存储	过度暴露数据	过度暴露外部存储中的敏感数据
		过度暴露内部存储中可读数据
潜在的危险功能	直接内存映射	内存访问
		文件系统访问
	可能危险的API	财务敏感API
		个人信息API
		设备管理API
应用共谋	数据变更	对共享文件资源的变更
		对共享数据库资源的变更
		对共享内容提供商的变更
	数据创建/删除	创建/删除共享文件资源
混淆	服务数量	过度检查服务状态
	本地代码	包含但未使用的潜在恶意库
		使用潜在危险库
		身份映射
		类自省
	库调用	库自省
		字段自省
		方法自省
	封装代码
功耗过大	CPU使用率
	I / O
暴露的数据存储	过度暴露数据	过度授予文件数据保护类
		过度授予密钥串数据保护类

附录D-缩略语

本文中使用的选定首字母缩写词和缩写词定义如下

API	应用程序接口
BYOD	携带自己的设备办公
CAPEC	常见攻击模式枚举和分类
CERT	计算机应急响应小组
CPU	中央处理器
CVE	通用漏洞和风险
CWE	通用弱点列举
DHS	国土安全部
DoD	国防部
EMM	企业移动管理
GPS	全球定位系统
IEEE	电气和电子工程师协会
I / O	输入输出
IoT	物联网
ISO	国际标准化组织
ITL	信息技术实验室
JVM	Java虚拟机
NFC	近场通信
NIST	国家标准与技术研究所
NVD	国家漏洞数据库
OMB	管理和预算办公室
PII	个人身份信息
PIN	个人身份证号码
PIV	个人身份验证
SAMATE	软件保障指标和工具评估
SCAP	安全内容自动化协议
SLA	服务水平协议
SP	特刊
UI	用户界面
VPN	虚拟专用网
Wi-Fi	无线上网

附录E-词汇表

本出版物中使用的所选术语的定义如下:

管理员	组织的成员，负责部署，维护和保护组织的移动设备，并确保部署的设备及其安装的App符合安全要求。
分析员	利用一个或多个测试工具检查报告和风险评估的组织成员，以及用于验证App的组织特定标准，以满足组织的安全要求。
应用审核流程	组织执行的一系列活动，用于确定移动App是否符合组织的安全要求。
App审核系统	用于管理和自动化App审核流程的系统。
授权官	组织成员，决定是否批准或拒绝组织使用该App。
动态分析	通过使用一组输入用例执行App并分析App的运行行为来检测软件漏洞。
企业移动管理器	一组人员，流程和技术，专注于在商业环境中管理移动设备，无线网络和其他移动计算服务。
功能测试	验证App的用户界面内容和功能是否按设计执行和显示。
一般应用安全要求	应该或不应该存在的App软件和行为特征，以确保App的安全性。
恶意软件	用于执行未经授权的过程的软件或固件，这些过程将对信息系统的机密性，完整性或可用性产生不利影响。感染主机的病毒，蠕虫，特洛伊木马或其他基于代码的实体。间谍软件和某些形式的广告软件也是恶意代码的例子[31]。
移动设备管理	管理移动设备，如智能手机，平板电脑，笔记本电脑和台式电脑。 MDM通常通过第三方产品实施，该产品具有针对特定移动设备供应商的管理功能。
国家安全体系	代理机构或机构或其他组织的承包商代表机构使用或运营的任何信息系统，包括任何电信系统： 其功能，操作或使用涉及情报活动; 涉及与国家安全有关的密码活动; 涉及指挥和控制军队; 涉及作为武器或武器系统不可分割的一部分的设备;或者 （B）项规定对直接履行军事或情报任务至关重要;或者 在任何时候都受到为根据行政命令或国会法规定的标准特别授权的信息而设立的程序的保护，这些程序将被归类为国防或外交政策[56]。 组织特定的安全要求 组织必须遵循的政策，法规和指南，以确保组织的安全状况 个人身份信息 有关个人的信息，恶意行为者可以使用该信息来区分或追踪个人的身份以及与个人相关或可链接的任何其他信息[45]。
风险评估	表示在使用测试工具测试App时度量安全风险级别的值。风险评估通常基于检测到的漏洞被利用的可能性以及检测到的漏洞可能对App或其相关设备或网络产生的影响。风险评估通常表示为类别（例如，低风险，中风险和高风险）。
静态分析	通过检查App的源代码和二进制文件并尝试确定运行时可能出现的所有可能行为来检测软件漏洞。
软件保障	软件没有漏洞的信任程度-无论是故意设计到软件中还是在其生命周期中意外插入-以预期的方式运行。
软件正确性测试	执行程序以查找错误的过程。此测试的目的是改进质量保证，验证和验证所描述的功能或度量可靠性。
软件漏洞	软件中发现的安全漏洞，故障或弱点，可被攻击者利用。
测试工具	测试App以确定是否存在特定软件漏洞的工具或服务。

[1] 注意：术语越狱在工业中通常用于描述Root iOS设备。

[1] 对于移动设备，有一些分析工具将自己标记为执行行为测试。行为测试（也称为行为分析）是一种静态和动态测试形式，试图检测恶意或冒险行为，例如经常被引用的访问联系人列表的手电筒应用程序示例[21]。本出版物假定任何静态或动态测试的提及还包括行为测试作为其功能的子集。

[2] ASM框架[24]是字节代码分析的常用框架。

[3] 如[24-27]。

[4] https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/draft

[5] 第4.2.3节讨论了一个示例标准，即常见漏洞评分系统CVSS。

[6] 示例在2.1节中描述。

[7] https://www.niap-ccevs.org/Ref/Evals.cfm

[1] 漏洞被定义为一个或多个可能被意外触发或故意利用并导致违反所需系统属性的漏洞[1]

[2] 其他威胁和漏洞可以在附录A，B和C中找到。

[3] 为简洁起见，表1中列出了许多但不是所有功能要求。一些是多个相关控件的高级描述。有关完整列表，请参阅NIAP保护配置文件[7]。

[4] 应该注意的是，代码混淆在工业中具有合法用途，作为尝试保护应用和知识产权的方法。在需要分析混淆App的情况下，组织可以利用与App开发人员的业务关系来规避分析期间的这些预防措施。

[5] https://github.com/mitre/vulnerable-mobile-apps

[6] 漏洞数据库通常通过其常见漏洞和披露（CVE）标识符引用漏洞。有关CVE的更多信息，请参阅[12]。

[7] App审查流程还可用于评估其他问题，包括可靠性，性能和可访问性，但主要用于评估与安全相关的问题。

[8] 第4节描述了app审核工具使用的技术和方法。

[9] 通常，解码或反编译的代码不会产生源代码，而是可以分析的中间代码。

[10] 有关MAM技术的概述，请参见第5.2节。