android top 10 risk control

前 10 项无线风险：

1、   不安全或不必要的客户端数据存储

2、   数据传输中缺少数据保护

3、   个人信息泄漏

4、   未保护需要授权访问的资源

5、   未执行最少授权策略

6、   客户端注入

7、   客户端 DOS

8、   恶意第三方代码

9、   客户端缓冲区溢出

10、 未部署服务端控制

附加考虑点：

1、   滥用付费资源

2、   未恰当处理 inbound SMS

3、   未恰当处理 outbound SMS

4、   来自 Appstore 的恶意或虚假的应用程序

5、   一个应用程序查看数据或与其它应用程序通信的能力

6、   在一个事务期间切换网络

7、   未保护敏感数据 a rest

8、   在应用程序中未禁用平台不安全特征 ( 缓存按键、屏幕数据 )

 

Top 10 无线控制和设计原则

1、   在移动设备上标识和保护敏感数据

移动设备容易丢失或被偷，所以，引入必要的保护来尽量减少敏感数据的丢失。

在设计阶段，首先，要确定什么数据是属于敏感的，需要被保护和引入适当控制的。比如，用户个人 / 私人数据，密码证书等等。如果存放这些数据不是在客户端，而在服务器的话，也要引入保护。

利用移动 OS 或硬件 (SIM 卡 ) 提供的加密和 key-store 机制来保护重要的数据。

不要把敏感数据存储或 cache 到可移除介质，除非他们是防干扰和有密码保护的。

只使用受保护的临时或 cache 目录，而不是存在一个可读目录中。

自动从设备上删除不再需要的数据。

cache 和临时存储是一种可能泄漏的渠道。

共享数据存储 ( 地址簿， media gallery) 是一种泄漏渠道

被管理的设备应该利用远程擦除或去掉开关来从设备移除敏感信息。

根据时间来删除 schedule ，而不是根据 push-pop 基础 ( 为了阻止数据永久保存在 cache 中 ) 。

使用安全的删除过程，例如，与 NIST 800-88 保持一致。

当心与其它应用共享 cache 数据。

执行一个特定的检测，检测所有与 web server 后端的通信以及其它与可信边界通信的接口 ( 例如，在文件元数据里是本地或其它信息在传输 ) 。

在编写你的应用的时候，考虑整个数据生命周期的安全 ( 比如线上，临时存储， caching ，备份，删除等等 ) 。

根据敏感星，在哪个方面可以分类存储数据，应用相应的控制 ( 例如密码，联系人数据，地点，出错日志 ) 。

采取最小暴露的策略，仅收集和暴露应用需要的数据。

无论在什么地方，和其它应用使用不共享的非永久性标识符，例如不使用设备 ID 号码作为标识符，除非有一个很好的理由来这么做。

2 、安全处理设备上的密码证书

与其使用密码不如考虑用更长的授权 token ，它能安全地存放在设备上。这个 token 可以加密存放和传输。当验证过用户身份之后，可以由后端服务器发布这个 token 。而且，这个 token 可以绑定特定的服务，在丢失的情况下，可以把危害减到最少。

在密码需要被存放在设备上的情况下，可以利用由移动 OS/ 硬件提供的加密和 key-store 机制来存放密码证书。

提供给移动用户改变 / 删除设备上密码的机制。

密码证书应该被标记，以避免被拷贝来备份。

访问高度敏感数据应该被 PIN 保护。

考虑使用基于 visual/patten 的密码来提高可用性。

确保密码等在 cache 或日志中不可见。

建议一次性编码或密码不应该通过 SMS 传递，可以考虑用客户端认证的 HTTPS 来阻止 Zeus-in-the-mobile 类型的攻击。

3 、确保敏感数据在传输中是受保护的

网络欺骗攻击、侦听大多数智能机，传输载体 (wifi 、 3G/GSM 、 bluetooth) 。敏感数据通过不安全的通道会被截获。

保护传输中的数据 ( 假设最槽糕情况，用户坐在一个公共的未保护的 wifi 下上网 ) 。

当在有线 / 无线发送敏感数据的时候，应用应该强制用户使用 end-end 安全通道 (SSL/TLS)( 不要想当然认为传输加密 ) 。

对于敏感数据，为减少中间人攻击 (SSL Proxy) ，只有在验证远端的身份后才建立安全连接。

不要禁用或忽略 SSL 链验证 (chain validation) 。

SMS,MMS, 或通知不应该用来发送敏感数据到终端移动设备。

一次性密码考虑使用客户端授权和 https ，而不是 SMS 。

考虑 GSM 的 encryption-on 标志来验证 GSM 加密是打开的。

不要训练用户跟随不可信路径 ( 例如接受无效证书 ) 。

提供一个报告钓鱼应用的通道 ( 例如假设你是一个浏览器插件的开发者 ) 。

4 、保持后端 API 和移动终端安全

Web Services/SOAP/REST ，安全最好的实践 (placeholder)

输入验证

不要使用总所周知的秘密来保证后端的完整性 ( 像在代码中嵌入密码 )

确保授权控制的过程在后端的 API 中是正确的。

确保后端平台正允许在一个最近安全补丁的硬配置。

确保速率和流量限制，测试 DDOS 漏洞。

5 、执行用户授权 / 认证和 session 管理

用户授权必须基于用户的身份

使用高熵不可预测的 session ID 。

不要使用设备 ID(UDID 或 IMEI) 作为 session ID 。当连接到其它数据，设备 ID 容易被欺骗，也可能泄漏私人信息。

Session token 能使用操作系统特性来加密 cache ，存放在设备同理。

对于应用行为造成任何花费，警告用户并获取用户同意。

6 、确保高危漏洞和打补丁管理适当

所有的移动应用的后端 API(WebServices/REST) 必须周期性漏洞测试。

开发者需要用静态代码分析工具和 fuzzing 工具来测试和发掘安全缺陷。

应用必须被设计成允许更新安全补丁， taking into account the requirements for approval by app-stores and the extra delay this may imply 。

理解和测试你的补丁程序，以及与 app-store 的交互。没有 app-store 的同意就执行任何更新的典型时段？

应用程序的团队应该负责跟踪所有在移动应用中的第三方架构 /APIs 的安全补丁行为。

7 、第三方后端应用完整性检测

如果有任何个人数据被收集或发送，用户应该获得通知。

在没有之前同意的情况下，非敏感数据或非用户个人数据被发送，或与第三方网站共享，需要通知用户。

在应用处理之前，验证所有接收到的来自不可信的第三方的数据。

应用某项功能不需要数据，就不要给它发数据，除非你得到用户的明确同意。

9、  以最小许可权限来允许移动客户端

在操作系统平台下，以应用能运行的最小权限来运行。

不要授权代码或应用执行 root/sa 特权。

总是作为一个标准用户和特权用户一起测试。

最少特权。注意 API 的缺省特权，并禁用。

不要在客户端设备上打开特定的应用监听端口。使用 OS 提供的通信机制。

9 、 10 、。。。

11 、使用安全编码 / 开发过程

输入验证，输出 encoding

审计应用中用到的第三方代码或库的安全性

在一些移动平台上的代码签名暗示安装在相同移动设备上的应用程序间继承信任 ( 相同代码特征 ) 。恰当地实施代码签名机制。

使用静态或二进制代码分析来查找缺陷。

使用安全的字符串函数，避免缓冲区或整数溢出

对于使用 JNI 的应用程序使用第三方验证来确保无漏洞

在发布之前删除所有测试代码

发布版本中有恰当地日志。不是可执行，敏感的用户信息。

候选：

移动应用的二进制可能较容易被逆向，所以，不要讲密码或秘密放在应用程序的二进制中。

保护你的应用远离设备上的其它恶意程序。

Original list (kept for review)

1. Protect data at rest
2. Protect data in transport
3. Multi-factor authentication
4. Session management
5. Least privilege access control
6. Untrusted data validation
7. Output encoding
8. Enterprise device management
9. Keep business logic on the server
10. Platform security