移动应用安全开发指南（Android）--完结篇

概述

认证是用来证明用户身份合法性的过程，授权是用来证明用户可以合法地做哪些事的过程，这两个过程一般是在服务器端执行的，但也有的APP出于性能提升或用户体验等原因，将其做在客户端完成，由此导致客户端绕过等问题。

安全准则

A.      在客户端做认证和授权是很难保证安全的，所以应该把认证和授权做在服务器端。如果确实有特殊的需求，可以和安全工程师进行沟通做单一case分析。

B.      尽可能避免在设备上存储用户名和密码，可以使用登录认证后获得的token进行鉴权（同时注意控制token的有效期）。

详细描述

Item B的典型应用场景是实现自动登录，用户登录认证后在本地存储用户的认证token，用户退出程序时认证token不会被删除，再次打开程序时可直接携带认证token获取数据，同时为了保证了足够的安全性，可以根据当前终端硬件信息产生独立密钥，然后对token进行加密。具体设计参考附录8。

备注

在本地存储对称加密后的用户口令密文，在登录时还原出明文也是实现自动登录的一种可选方案，但其安全性偏低，故在当今已并非一种主流的做法。

概述

开发人员在移动应用中通常会对敏感数据进行加密处理，但是使用不当有可能让其保护强度削弱，甚至大打折扣，因此，正确的选择加解密算法显得非常重要。

安全准则

A.      在不需要还原用户明文密码的场景使用哈希算法，在需要还原用户明文密码的场景下使用对称加密算法，并且始终优先选择使用哈希算法。

B.      使用目前主流的安全加密算法，比如哈希算法可以使用sha256，对称加密算法可以使用AES128/256，不使用过时的不安全算法，比如RC4、RC5、MD5和SHA1。

C.      不使用自定义的加密算法。

D.      密文和密钥不要放在同一文件或同一目录内，应分开存放。

E.       密钥不可硬编码在代码里面。

详细描述

使用AES128加密算法时，密钥应同时满足长度（128bit）和复杂度的要求，建议使用安全的随机数发生器产生安全的密钥，Sha256哈希算法和AES128对称加密算法的使用方法请参考附录1。

备注

注意：在某些不牵涉敏感数据的场景下，不安全的哈希算法仍然是可用的，比如用于校验文件或数据的完整性。

概述

安全开发可以大大降低移动应用的安全风险，同样地，安全的配置和部署可以让风险降到最低。

安全准则

A.      确保使用的第三方组件是从官方下载的，并且是最新版本的。

B.      为应用程序申请最小的Permissions，如果用不上就不要申请。

C.      应用和补丁在发布前建议进行病毒和恶意代码检测。

D.      为敏感数据输入界面提供防截屏措施，对抗木马。

详细描述

在Activity的onCreate()方法的初始化部分加入以下代码可用于防截屏：

getWindow().addFlags(WindowManager.LayoutParams. FLAG_SECURE);

备注

非官方的库可能被植入恶意代码，而使用最新版本的库（非beta版）可以降低漏洞存在的可能性。

概述

通常一个应用发布后可能会面临以下风险：

A．  应用被别人解包植入广告或恶意代码再重打包发布。

B．  应用被暴力破解。

C．  应用的核心关键代码逻辑被逆向。

因此，有必要在技术层面采取一定的缓解措施。

安全准则

A.      对Java代码进行混淆，对抗反编译。

B.      对Native代码进行加壳，对抗反汇编。

C.      应用程序加入动态反调试方法。

D.      应用程序加入防二次打包的方法。

详细描述

A.        可以使用proguard对Java源码进行混淆。

B.        可以使用UPX进行加壳保护，请参考《Android SO加壳指南v1.0》。

C.        预先在AndroidManifest.xml文件插入android:debuggable=”false”，在程序中判断该标志位是否被篡改，此外，android SDK也提供了相关方法来检测调试器是否已连接，可在程序中随机插入检测，关键代码如下（详情参考附录10）：

D.        应用程序被篡改并重打包时必定要重新签名，签名值和原开发者的必定不一样（不考虑证书丢失的情况），另外，重新编译程序classes.dex文件肯定会变，因此可在程序运行时对比签名或CRC值的方法对抗重打包（参考附录11）。

备注

以上方案参考《Android软件安全与逆向分析》一书，但只能提供比较基本的保护措施，如果要进一步提高攻击者的攻击门槛，建议使用第三方的定制方案。

概述

本项作为其它移动客户端项的进一步补充。

安全准则

A.      关键性业务逻辑代码应放在native代码实现，除此以外，尽量使用android SDK做开发，减少对native代码的依赖（native代码一般采用C/C++编写，容易出现缓冲区溢出等漏洞）。

B.      尽量少用动态加载的方式执行代码（比如使用DexClassLoader），如果需要从外部存储动态加载可执行文件或类文件（比如使用DexClassLoader），应经过严格的文件完整性验证。

详细描述

文件完整性校验方案（参考附录9）：

A.        对待动态加载的可执行文件或类文件进行哈希计算，并与存储在服务器端的正确的哈希值进行对比，如果一致则表示文件未被篡改过，否则拒绝执行加载。

备注

存放在外部存储的文件是可公共访问的，可能会被其它恶意进程篡改，动态加载这些文件就有可能导致恶意代码执行。

概述

大部分移动应用并非一个独立的单机程序，需要在服务器的支撑下完成一系列的功能，而服务器一般是以web API、web service等方式为移动客户端提供服务，因此，也同样存在web应用的安全问题，而这部分问题牵涉面广而复杂，无法在单独的item内进行描述，可参考《web安全开发指南》

安全准则

请参考《web安全开发指南》

详细描述

备注