移动设备应用的灰盒测试与评估的三步走
所谓移动设备应用的灰盒测试是指，将传统的源代码检查（白盒测试）与前期测试（黑盒测试）结合起来的一种技术。测试人员必须检查应用程序的代码库，审查关键功能代码，审查常见的错误编码或非法编码方法。此外，测试人员还可以执行黑盒测试来审查应用，并根据所确认的漏洞定位找到代码库中的目标代码。
为什么要执行移动应用的灰盒测试与评估呢？答案很简单：找到高风险代码；确认漏洞的根本原因。
灰盒测试应当遵循如下三大步骤：
一、威胁建模
威胁建模可以使测试团队首先确认有可能对移动应用产生大影响的威胁。测试人员在这个阶段的主要目的是区分特定应用组件或代码的优先顺序。测试团队通过理解应用程序架构的文档资料，应当逐渐熟知移动应用的基本架构和使用情况。
收集信息
通过与移动应用的开发团队协作，测试团队应当获得有助于帮助其理解移动应用的设计和功能的文档资料。这些文档资料中所描述的细节，可以为威胁建模过程中的所有步骤提供基础。
执行侦察和应用映射
理解移动应用如何实现其功能对于创建移动应用模型至关重要。在此阶段，测试团队应当人工检查移动应用的实例。然后，团队应当检查移动应用的匿名部分和认证部分，同时关注处理敏感数据和功能的部分。在此阶段，要提供架构、配置、过程、用户、技术等各方面的证明文件，以利于下一阶段的使用。
需要重点关注并用于下一阶段针对性测试的方面有：管理界面、敏感信息的传输、外部或第三方应用的接口、移动协议（如SMS、MMS、WAP等）的使用。
测试团队应当记录在此期间的每一种请求和响应，以便于使用本地代理工具和网络嗅探工具进行日后分析。
定义系统和可信边界
在检查的下一阶段，评估团队应当构建一个移动应用及数据流程图中的系列过程的可视化模型。数据流程图要确认系统边界和围绕移动应用的每一个组件的可信边界。确认系统边界可以使测试团队初步明确数据流入或流出系统或其组件（即数据入口和出口点）的所有位置。随后，在代码检查阶段，测试团队应当检验在每一个系统边界是否执行了适当的验证和编码技术。与此类似，确定可信边界可以查明测试团队能够检验代码中的认证和授权部分。
将威胁映射到功能
在定义了所有的流程图要素后，测试团队应当将所有要素映射到资产威胁，其目的在于定义移动应用中的“热点”，进而可以构建一个测试计划。在针对性的代码检查阶段，测试团队应当全面测试计划中的每一个项目。
二、漏洞确认
在应用程序的评估过程中，应当重点检查前一阶段所确认的热点源码。除了要检查源代码检查不易发现的应用程序漏洞，企业还应当执行黑盒类的评估，用以确认网络或主机层的漏洞。为了补充应用程序组件的人工检查，这个测试阶段应当采用自动化的扫描。
代码分析和扫描
自动化扫描工具可以分析全部源代码，从而初步发现安全问题。在此阶段，测试者应当利用商业类工具和私有工具来扫描有安全问题征兆的代码和可导致漏洞的常见编程错误。源代码分析阶段应当设法确认可影响到主机、服务器和网络的漏洞。
人工分析
在此阶段，我们建议详细检查应用程序的代码，其目的是为了发现应用程序架构所独有的安全漏洞。在检查代码时，建议将以下几种技术结合使用：
1、许可分析：许多平台要求移动应用声明在执行期间试图访问哪些功能。然后，设备将对应用程序限制使用这些特定的功能。测试人员可以针对这些功能发动攻击，并尝试绕过这些限制，以检验其效果。
2、控制流分析：该技术用于分析代码中的逻辑条件。这种方法可以使测试人员确认常见的逻辑漏洞，例如，程序无法处理例外、不适当的授权限制等。
3、数据流分析：该技术跟踪从输入点到输出点的数据，尤其适用于确认常见的输入验证错误，如SQL注入和跨站脚本利用。
为应用这些技术，我们建议企业将移动应用分割成不同的功能组件。测试者应当检查每一个组件，以查找常见的不安全的编程方法，这些方法包括：
1、认证：弱口令要求、用户名穷举、账户停用、cookie重放攻击、后门等。
2、授权：特权提升、不适当的权力分配、机密数据的暴露、数据受损等。
3、会话管理：会话陷阱、会话超时、会话劫持、不适当的会话终止、会话重放、中间人攻击等。
4、配置管理：对管理界面的非授权访问、对配置文件的非授权访问、配置数据的检索、分配给过程和服务账户的过多特权。
5、输入验证：参数损害、缓冲区域溢出、跨站脚本攻击、SQL注入、XPATH劫持、命令劫持等。
6、数据保护：对移动应用或用户的私密进行硬编码、网络通信嗅探、错误的密钥生成或密钥管理，弱加密等。
7、例外处理：信息泄露、拒绝服务等。
8、审计和日志：日志伪造、操纵日志文件、日志文件破坏等。
9、缓存：在移动应用的生命周期内，击键、快照、剪贴板内容和文件有可能被缓存到设备的不同存储位置。
10、发布通知：将数据从服务器传输到应用。
11、基于位置的服务：试图泄露或欺骗位置数据。
此外，还有以明文形式将口令存放到数据库中等。
检查代码中的架构安全问题
如果应用程序使用了特定的安全机制，或者具备可以减轻某些“臭名昭著”的安全威胁的功能，这一步相当重要了。后的代码检查用于验证应用程序架构的特定安全功能：
加密：由于定制的加密方案一般都没有强健的加密机制，所以企业应当检查方案，以验证其是否可以对敏感数据提供充分的保护。
协议：测试人员应当检查应用通信的私有协议，用以决定其应对破坏和侦听的能力。
会话管理：测试者应检查如下两方面，一是创建特定会话标识符的企图，二是会话管理进程。这样做的目的是为了衡量其会话发生管理错误时的保护能力。
访问限制：测试者要检查特定HTTP头的使用或者其它的特定协议要素，用以控制访问，防止未授权的访问。
安全代码：有些代码是为解决以前所发现的安全问题而编写的，对此测试者要专门检查，以检验其功效。
服务器架构：测试者要检查用来支持移动应用的外部Web服务和服务器。
三、漏洞利用
在这个阶段，测试者必须制定测试计划，其目的是为了对源代码进行深入分析，查找是否存在常见的不安全编码方法。然后，重点检查移动应用的特定安全机制。测试者还要查找、检查代码中的架构安全问题。
验证所确认的问题
测试团队要分析来自漏洞扫描的结果，去掉那些似是而非的信息，并着手构建可利用漏洞的案例。
利用移动应用的独有功能
灰盒测试方法的主要好处是能够大限度地利用漏洞。在此阶段中，测试者要尝试利用在移动应用的实例中表现不明显的认证漏洞和授权漏洞。这些漏洞可能会导致对功能或数据的非法访问，并给企业带来巨大风险。测试者还要利用业务逻辑（用于控制用户如何在移动应用中执行操作）中的缺陷。这些缺陷一般被用于欺诈移动应用的用户或公司。
将漏洞利用与源代码联系起来
在测试者证明了可利用的漏洞后，要将可利用的漏洞与相关的特定代码部分联系起来。这可以使开发人员快速地理解问题，并可以评估进行漏洞修复需要花费的工作量。
分析风险
测试者要评估可利用的漏洞，并根据每个漏洞给公司带来的风险，对漏洞进行评级。对于漏洞，测试者还要评估在漏洞被利用后，它可能对公司造成的影响。如果测试者能够利用多个漏洞并带来更大的影响，那么这种分析具有多重意义。
提供具体的技术建议
在评估了每个可利用漏洞的风险后，测试者要给出移动应用架构和代码编写的具体建议，如果可能好包括源代码。然后，开发者可以利用这些建议来减轻或修复漏洞，从而减少应用风险。测试者的建议还可以提供安全的编码指南，用以解决或修复移动应用的漏洞。
在这里提出几条移动安全的建议，供开发者和测试者参考：把移动安全理念纳入到开发项目中；构建并实施一种可以监管移动应用的开发并确保可理解性的策略；培训移动应用的开发人员，帮助其实施安全的编码；测试是否可以限制传输到移动设备的敏感数据；评估针对Web应用和基础架构的威胁。
