安全性测试
我们常说的安全性测试大多指的是技术层面的，如网络安全，系统漏洞，加密解密等等。在实际的工作过程中，我基本上没有过相关的工作经验，也只是找过一些第三方的安全团队帮忙对客户端进行过安全性测试，或者是询问过程序有关一些漏洞，预防相关的事项。
其实安全性测试的思想更接近测试工作的终极目标：预防问题。所以安全性测试是一个结构复杂、内容繁多、实践性很强的工作，需要更高的专业性和技术能力。我并不具备这方面的能力，也没有过相关的工作经验，但日常工作中还是总结了一些业务方面的安全性内容，我觉得也可以介绍一下。之所以将安全性测试也单独列为一个模块，是因为考虑到将来我也许还会进一步学习和积累，到时可以再继续进行补充。
核心逻辑校验：服务端判断、协议检查、并发处理、客户端加速、客户端随机概率再把结果发给服务端
敏感信息保护
客户端加壳
代码混淆：脚本、配置表加密
安全漏洞主要有： Web组件远程代码执行 HTTPS敏感数据劫 私有文件泄漏 BroadcastReveiver组件暴露 Activity组件暴露
应对办法： 1、核心逻辑要有服务端验证 2、使用成熟的引擎架构，如Unity 3、多考虑异步、并发的处理情况 4、进行协议测试，发送错误的参数给服务端 5、客户端服务端之间有时间戳校验 6、本地存档加密
腾讯白皮书里还有相关的一些改进建议：
二次判断
第三方安全性测试的结果
曾经工作过的一个公司楼下有家专门做安全性测试的，不知怎的拿到了我的联系方式，然后就交流了几次，并且拿当时一款线上的产品交给他们做下安全性评测，等于试用下他们的服务。拿到评测的结果后看了一下，觉得很多方面的问题其实意义不是很大。结果大致如下：
| 测试目的 | 问题描述 | 危险等级 | 解决方案 | 结果点评 |
|---|---|---|---|---|
| 检测java层代码是否采用保护措施，例如代码混淆等，是否存在被反编译的风险。 | App代码未保护，可能面临被反编译的风险。反编译是将二进制程序转换成人们易读的一种描述语言的形式。反编译的结果是应用程序的代码，这样就暴露了客户端的所有逻辑，比如与服务端的通讯方式，加解密算法、密钥，转账业务流程、软键盘技术实现等等。攻击者可以利用这些信息窃取客户端的敏感数据，包括手机号、密码；截获与服务器之间的通信数据；绕过业务安全认证流程，直接篡改用户账号信息；对服务器接口发起攻击等。 | 高 | 使用XXX公司的安全加固方案的防反编译功能，防止应用被反编译。 | 我们产品的客户端是用Unity3D开发的，主要的逻辑代码是用C#写的，java代码只很少一部分，应该是基于Android配置用的，即便被反编译也看不出什么信息，更不要说有什么代码逻辑。 |
| 检测apk中的组件是否存在导出的风险。 | 该Apk中的组件具有导出权限，存在组件导出风险。组成Apk的四个组件，Activity，Service，Broadcast Receiver 和Content Provider，如果设置了导出权限，都可能被系统或者第三方的应用程序直接调出并使用。组件导出可能导致登录界面被绕过、信息泄露、数据库SQL注入、DOS、恶意调用等风险。 | 中 | 关闭AndroidManifest.xml中的组件导出权限，对于必须导出的组件必须限制于授权用户或者应用组件。 | |
| 检测App程序中是否调用了调试日志函数。 | 该App存在调试日志函数的调用，可能发生重要日志信息泄露的风险。调试日志函数可能输出重要的日志文件，其中包含的信息可能导致客户端用户信息泄露，暴露客户端代码逻辑等，为发起攻击提供便利，例如：Activity的组件名，是Activity劫持需要的信息；通信交互的日志，会成为发动服务器攻击的依据；跟踪的变量值，可能泄露一些敏感数据，输入的账号、密码等。 | 关闭调试日志函数调用，或者确保日志的输出使用了正确的级别，涉及敏感数据的日志信息在发布版本中被关闭。 | 高 | 测试报告里输出的调试日志函数，主要都是接入的SDK的，并不是产品本身的调试日志接口。 |
| 检测客户端App运行时是否面临动态注入的风险。 | 该App存在动态注入的风险。动态注入是指通过OS特定机制，利用系统API将代码写入到目标进程并让其执行。通过动态注入，攻击者可以将一段恶意代码写到目标进程，这段代码可以加载其它可执行程序，进而实施hook，监控程序运行、获取敏感信息等。常见的动态注入，可以实现窃取输入的登录账号、密码、支付密码，修改转账的目标账号、金额，窃取通讯数据等。 | 使用XXX安全加固方案的反动态注入功能，防止应用被动态注入。 | 高 | |
| 检测客户端的源代码、资源文件、配置文件等被篡改后，是否可以重新打包并正常运行。 | 该Apk存在篡改后被二次打包的风险。Apk篡改后二次打包不仅已经严重危害开发者版权和经济利益，而且也使app用户遭受到不法应用的恶意侵害。对客户端程序添加或修改代码，修改客户端资源图片，配置信息、图标,添加广告，推广自己的产品，再生成新的客户端程序,可导致大量盗版应用的出现分食开发者的收入；恶意的二次打包还能实现应用钓鱼、添加病毒代码、添加恶意代码，从而窃取登录账号密码、支付密码，拦截验证码短信，修改转账目标账号、金额等等。 | 使用XXX安全加固方案的防篡改功能，防止应用被二次打包。 | 高 | 我们的产品是网游，大部分的逻辑判断主要还是看服务端，包括付费也都是在服务端，即便客户端被篡改也不会带来太大的影响。 |
| 检测app程序是否使用HTTPS协议对传输数据进行加密。无线传输的数据能被第三方轻易截获，由于客户端与服务器之间的传输数据遵循通信协议指定的格式和内容类型，如果未使用加密措施，传输数据可被还原成网络层的数据包并进行解包分析，直接暴露用户的各种关键数据，例如用户名，密码等。加入了SSL（Secure Socket Layer）子层实现的HTTPS协议可确保数据在网络上加密传输，即使传输的数据被截获，也无法解密和还原。 | 该App应用中使用了未加密的HTTP协议进行数据传输。 | 使用HTTPS协议对传输数据进行加密保护。 | 高 | iOS上确实对产品的http访问做了要求，一定要用https，不过这个测试报告里列出的http访问都是官网、sdk上报以及获取服务器列表之类的数据，不涉及核心内容。 |
| 检测App程序在使用HTTPS协议传输数据时是否对服务器证书进行完整校验。 | 该App应用在使用HTTPS进行数据传输时未校验服务器证书或者未校验主机名。使用HTTPS协议时，客户端必须对服务器证书进行完整校验，以验证服务器是真实合法的目标服务器。如果没有校验，客户端可能与仿冒的服务器建立通信链接，即“中间人攻击”。仿冒的中间人可以冒充服务器与银行客户端进行交互，同时冒充银行客户端与银行服务器进行交互，在充当中间人转发信息的时候，窃取手机号，账号，密码等敏感信息。 | 在使用https时对服务器证书进行校验，并且使用STRICT_HOSTNAME_VERIFIER严格校验主机名。 | 中 | 测试报告里列出的访问接口好像是开源代码部分的，另外网络游戏本身转发协议没有太大的意义，即便被盗取账号，也很难带来现实利益。对于银行业务来说，确实比较重要。 |