移动APP安全涉及事项补充
1、内存、缓存
移动设备很容易受到安全漏洞的影响，因为很容易访问到内部的缓存信息。开发一个应用程序，设定清理周期，智能进行缓存清理或输入密码进行清理。黑客为了解析我们的代码逻辑，从日志下手对他们来说是非常常见而且有效的手段。日志中往往隐藏了对黑客来说非常重要的关键词和代码逻辑。所以为了减少信息的泄漏或者说增加代码被解析的难读，版本的日志屏蔽是非常重要的。
2、系统崩溃
在应用程序崩溃的情况下，在iOS禁用存储调试信息的NSLog语句，对于Android用户，可在设备重启时清除日志。
3、加密复杂度简单
加密算法升级，尽可能避免使用低级的加密算法，防止分析信息和广告信息的泄露。
4、越狱、刷机
企业移动管理解决方案极大的保护设备免遭越狱或刷机。这样可以避免移除移动操作系统提供的内置安全性，保证数据的安全。在应用程序启动之前对用户身份进行验证的机制。
5、设备丢失
如设备丢失或被盗，系统应支持注销或冻结该用户。
6、组件安全问题。
第一个是Activity，首先是访问权限控制，组建处理不好会导致你的应用被恶意程序进行恶意的页面调用私有的Activity不应该被其他应用启动且应该确保相对是安全的；关于Intent的使用要谨慎处理接受的Intent，以及其携带的信息尽量不发送敏感信息，并进行数据校验。设置Android：exported属性，不需要被外部程序调用的组建应该添加android:exported=”false”属性。
私有activity：只能有APP内部使用的activity，最安全的activity。
公共activity：任意APP都能启动此类activity。
伙伴activity：合作伙伴APP才能启动的activity，授权。
内部activity：只有内部APP才能启动，全家桶。
第二个组建安全是Service劫持、拒绝服务。常见的漏洞有空指针异常导致拒绝服务和类型转换异常导致的拒绝服务两种。应对 Service 带来的安全问题：一我们应用在内部尽量使用 Service 设为私有，如果确认这个服务是自己私有的服务，就把它确认为私有，不要作为一个公开的服务；针对 Service 接收到的数据应该进行校验；内部的Service需要使用签名级别的 protectionle。
7、数据传输安全。
敏感数据加解密采用单独服务的方式部署在公司内网，便于扩展被多个服务调用，部署在内网可以增加密钥的安全性； 外部调用服务与内部服务器之间数据传输采用非对称公私钥加密传输保证传输安全。
8、应用安全层。
可以对代码进行一些混淆，如配置，如果觉得这还不够，也可以使用一些第三方的工具，比如APK文件。对于更加讲究安全性的经营类的企业，可以选择加固，使用脱壳程序，最后形成一个新的Dex包，最后完成对一个程序的加固。
9、编码安全
其实程序员的编码规范很重要。在Java中，对于一些重要的类、方法、变量，我们在定义的时候一定要想这么几个问题。
· 定义的类或者变量到底返回什么？
· 它们获得什么作为参数？
· 是否能够绕过安全线？
· 它是否含有能够绕过边界，从而绕过保护的方法变量？
有了这种思想之后，对于一些安全性的风险代码为了防止暴露，我们可以做一些操作，说限制对变量的访问，让每个量的方法都成为Final，尽量使你的类不要被克隆，如果一旦允许被克隆，它可能会绕过这个类轻易地复制类的属性。安卓中很多会使用到序列化，如果自己觉得这个类是有风险的，或者说安全性是很高的，尽量不要让它序列化。最后是避免硬编码影响数据。
10、 存储安全
要为敏感数据提供额外的保护，可以选择使用该应用无法直接访问的密钥来对本地文件进行加密。在外部存储设备（例如 SD 卡）上创建的文件不受任何读取和写入权限的限制。对于外部存储设备中的内容，不仅用户可以将其移除，而且任何应用都可以对其进行修改，因此最好不要使用外部存储设备来存储敏感信息。就像处理来源不受信任的数据一样，应对外部存储设备中的数据执行输入验证。
11、数据安全
请参考
12、建立运维机制及办法
系统上线后应对应用程序、网络、端口、硬件等进行不定期检测及程序的迭代更新。如新发布的系统漏洞APP是否规避、加密算法是否先进。
13、灾难性事故应急措施
发生灾难后系统恢复措施。
