送你的圣诞收藏夹-Android安全性清单

Android开发者会感到困惑，因为从安全角度出发他们并不清楚什么样的做法才是最好的，这样一种情况并不让人觉得奇怪。已知有太多的安全性清单列表，但你很难弄清楚哪些才是最重要的。

下面是我们将要了解的一些主要的清单列表。

PCI移动支付受理安全指南。

Google Security。

HIPAA Secure。

2014年OWASP移动风险Top 10。

Forrester Research发布的在移动应用开发中非技术性安全问题的Top 10。

每一个安全性清单列表都有其各自的价值，但其中最为突出的是OWASP Top 10。不管怎样，我们都对这些清单做一个简要的介绍。

1. PCI移动支付受理安全指南

PCI指的是支付卡行业安全标准委员会，该组织是在2006年由信用卡行业建立的，用于负责在线支付或者其他支付方式的安全性问题。因此，这个清单的重点放在移动设备中信用卡支付的安全性上。这个清单并没有为Android指定单独的内容，它也可以用在iOS或者Windows Phone手机上。

这里必须要指出的是，PCI移动支付受理安全指南只是指导性的，而非强制性的，所以，如果你没有满足这些规范，也不会受到处罚。以下是2012年9月发布的清单。

（1）防止在移动设备中输入账户数据时被窃听。

（2）防止账户数据在移动设备中处理和存储时被破解。

（3）防止移动设备向外传输时账户数据被窃听。

（4）阻止逻辑上未授权的设备访问。

（5）建立服务器端的控制并且报告未经授权的访问。

（6）阻止权限的提升。

（7）有能力远程禁用支付应用。

（8）可以检测到设备被盗或者丢失。

（9）强化支持系统。

（10）优先选择在线交易。

（11）遵循安全编码、设计、测试标准。

（12）防范已知的漏洞。

（13）防止移动设备使用未经授权的应用程序。

（14）保护移动设备使其免受恶意软件入侵。

（15）保护移动设备使其免受未经授权的附加装置入侵。

（16）设计实现和使用程序的指导性内容。

（17）提供安全的商家收据。

（18）提供一个安全状态的指示。

这个清单最主要的观点就是确保在信用卡数据被输入到设备上以及它被传输到服务器上时你都对其进行了加密。

2. Google Security

Google并没有提供类似的Top 10的清单列表，但却有一个安全最佳实践的培训资料，我们列举在下面。跟之前的清单不一样的是，它是由Google提供的，也就不奇怪这个清单是专门针对Android的了。

（1）避免通过MODEWORLD_WRITEABLE或者MODE_WORLD READABLE模式打开文件，因为这样其他应用程序也可以读取这些文件。

（2）不要将敏感信息存储在外部存储器当中，因为别人可以在SD卡上查看到不受任何保护的数据。

（3）如果你不打算让其他应用程序访问你的ContentProvider，那么就在应用的manifest文件给这些ContentProvider加上android:exported=false属性。

（4）将你应用请求的权限减到最少，不要申请你不需要的权限。

（5）在服务器上能够使用HTTPS的地方都使用HTTPS，而不使用HTTP。

（6）使用Google Cloud Messaging（GCM）和IP网络从Web服务器发送数据消息给用户设备上你的那个应用。

（7）使用SQL参数化查询防止SQL注入。

（8）如果你能避免存储或者传输数据，那么就不要存储或者传输数据。

（9）为了避免XSS攻击，不要在WebView中直接使用JavaScript，不要调用setJavaScriptEnabled()方法。

（10）使用已经存在的加密算法，不要自己去写一个，使用SecureRandom这种安全的随机数生成器来初始化加密密钥。

（11）如果你为了重复使用需要存储一个密钥，那么使用像KeyStore这种提供长期存储和获取加密密钥的机制。

（12）如果broadcast intent中的数据比较敏感，你需要考虑为这个broadcast intent设置一个权限，确保恶意应用在没有这个相应权限的情况下不能注册一个receiver来接收broadcast当中的那些数据。

（13）Binder或者Messenger是Android中RPC（远程过程调用）形式的IPC（进程间通信）的优先选择。

（14）不要从你的应用APK之外加载代码。

（15）出于缓存溢出的考虑避免使用native代码。

从目前来看，其中的一些条目，比如用MODE_WORLD_READABLE打开文件，没有Eclipse或者Android Studio提示的话是很难注意到的。当在你的Android项目上使用lint时，所有像MODE_WORLD_READABLE这样的问题以及更多的细节都会有所提示。我们在贯穿本书的过程中会看到更多这些问题的细节。

3. HIPAA Secure

在美国，移动安全在医疗领域深受HIPAA影响，HIPAA指的是医疗保险电子数据交换法案。其他的国家或地区也有类似的法案。符合HIPAA安全规范意味着你没有泄露任何受保护的健康信息。这里要提示的是HIPAA并没有跟上移动领域的快速发展。除了计算机不再固定在办公室桌面上这种问题之外，通过一些常识，我们可以判断哪些场景是可以使用HIPAA中的一些原则的。

HealthIT.gov网站提供了一个安全风险评估工具，你可以从这里开始来确定你的应用是否符合HIPAA规范。你可以在www.healthit.gov/providers-professionals/security-risk-assessment-tool获取到这个工具，工具分为3个部分，行政、技术和物理的保护措施。表1列出的T1到T45是其中的技术保护措施，我们加粗显示了从Android角度看也比较有用的措施。这些保护措施被分成Standard（标准的）、Required（必须的）、Addressable（需处理的）3类。Standard和Required是要全部实现的。按HIPAA文档的说法Addressable跟Alternative（可用别的方案替代）是类似的一个意思，所以对于Addressable类型的措施要求是否要完全实现还有一些争议。但是，如果它适用于你的情况，那么就应该被实现。

表1　SRA风险评估工具—技术部分

T1

标准的

你的实践是否有相关的策略和流程让保护措施限制人们和软件程序只能访问到符合他们角色的电子健康信息（Electronic protected health information，ePHI）

T2

标准的

你的实践是否有相关的策略和流程基于人们和软件程序的角色赋予他们合适的权限

T3

标准的

你的实践是否分析了使用应用的全体员工和服务提供商的活动识别出各自需要访问受保护的ePHI的范围

T4

标准的

你的实践是否区分了控制访问的信息系统和电子设备的安全设置

T5

必须的

你的实践是否有相关的策略和流程为每一个授权用户赋予唯一标示符

T6

必须的

你的实践是否要求每个授权用户在访问ePHI之前都要输入为其分配的用户标识符

T7

必须的

你的实践是否有相关的策略和流程允许紧急情况下访问ePHI

T8

必须的

你的实践是怎么定义紧急情况并且如何区分各种可能发生的紧急情况的

T9

必须的

你的实践是否有相关的政策和流程来为ePHI建立一个一模一样的拷贝作为备份

T10

必须的

你的实践是否通过将副本存储在磁盘、磁带或者像云存储那样的虚拟存储来备份ePHI

T11

必须的

你的实践是否有备份的信息系统以便可以在发生紧急情况或者主系统不可用的时候对ePHI进行访问

T12

必须的

你的实践是否有能力在出现灾难性事件时激活这个信息系统的紧急访问

T13

必须的

在有需要的时候，你的实践是否有相关的策略和流程来区分出负责启用紧急访问设置的这类角色

T14

必须的

你的实践是否指定了一名员工，让其可以激活你信息系统的紧急访问设置

T15

必须的

当评估紧急状况下继续访问ePHI和其他健康记录的能力时，你的实践是否进行了测试访问

T16

必须的

你的实践是否能够有效地从紧急状态下恢复，继续正常的操作和访问ePHI

T17

需处理的

你的实践是否有相关的策略和流程在预先设定的不活动周期时间之后自动注销授权用户的session

T18

需处理的

你的实践是否有责任人了解其信息系统和电子设备的自动登出设置

T19

需处理的

你的实践是否启用了自动登出，在预先设定的用户不活动周期之后终止电子会话

T20

需处理的

你的实践是否有相关的策略和流程来实现ePHI加密和解密的机制

T21

需处理的

你的实践是否了解信息系统和电子设备的加密能力

T22

需处理的

你的实践是否通过加密解密来阻止未授权用户的访问，以此控制对eHPI和其他健康信息的访问

T23

标准的

你的实践是否有相关的策略和流程来识别记录或检查信息系统活动的硬件、软件或者程序的机制

T24

标准的

你的实践是否能够区分创建、存储和传输ePHI的这些活动以及支持这些业务流程的信息系统

T25

标准的

你的实践是否基于风险分析，把创建、传输或者存储ePHI的活动和信息系统分成高中低3个风险级别

T26

标准的

在识别跟踪的活动时，你的实践是否使用风险分析中的评估来帮助决定其被审查的频率和范围

T27

标准的

你的实践是否有用来监控、记录、检查信息系统活动的审查控制机制

T28

标准的

你的实践是否有相关的策略和流程来创建、保留和分发审查报告给相应的员工做检查

T29

标准的

你的实践是否生成了审查报告并分发给相应的人做检查

T30

标准的

你的实践是否有相关的策略和流程来确定出于审查目的的保留条件

T31

标准的

你的实践是否保留了应用审查/访问记录的副本

T32

标准的

你的实践是否有相关的策略和流程来保护ePHI不受未授权的修改和销毁

T33

需处理的

你的实践是否有相关的机制来证实ePHI未被未授权的方式更改、修改或者破坏

T34

必须的

你的实践是否有相关的政策和流程来核实寻求ePHI访问的人或者实体是他们声明的那个人或者实体

T35

必须的

你的实践是否了解信息系统和电子设备的验证能力，确保唯一标识的用户的确是他所声明的那个

T36

必须的

你的实践是否使用风险分析的评估来选择相应的验证机制

T37

必须的

你的实践是否保护了包含访问控制记录的文档（授权用户和密码的清单）的机密性

T38

标准的

你的实践是否有相关的策略和流程来保护ePHI在电子网络上传输时不受未授权的访问

T39

标准的

你的实践是否实施保护措施来保证ePHI在路由去接收者的途中不被访问

T40

需处理的

你的实践是否了解加密ePHI从一端发送至另一端这个加密的能力有多少

T41

需处理的

你的实践是否采取了步骤来降低ePHI在通过电子传输时被窃听或者修改的风险

T42

需处理的

你的实践是否实现了加密作为保护措施来确保ePHI从一端传输至另一端的时候没有被破解

T44

需处理的

你的实践是否有相关的策略和流程在认为合理和适当的时候对ePHI进行加密

T45

需处理的

当进行风险分析时，你的实践是否考虑到为确保ePHI的完整性在其存储或者传输的时候不被访问或者修改所做的加密的价值

安全性不仅是指应用安全，它也指当应用被破解时你用什么来通知人们，以及找出被破解的内容并做出报告。大多数移动开发甚至都没在这个移动安全的级别上做出深入思考，移动安全目前还只是包含极少数或者说根本没有监控用户是如何访问应用信息的。

SRA工具包含了比这个表多得多的信息，是一个很有用的资源。

我们将在书中介绍HIPAA的一些细节。

4. OWASP移动风险Top 10

2014年OWASP移动风险Top 10所示如下，并在接下来的段落中做了进一步解释。

M1：薄弱的服务器端控制。

M2：不安全的数据存储。

M3：传输层保护不充分。

M4：无意的数据泄露。

M5：较差的授权和身份认证。

M6：被破译的加密。

M7：客户端注入。

M8：通过不被信任的输入做出的安全决策。

M9：不正确的会话处理。

M10：缺少对二进制文件的保护。

OWASP移动风险Top 10名单最近进行了更新，移除了一些重复的内容，减少重复内容带来的困惑。

大多数移动应用都需要通过某些方式连接后端服务器来进行一些实际的工作。如果通信是通过Web Service做的，那么可以通过SOAP或者更常用的RESTful Web Service。在过去20年当中应用到Web服务器安全方面的最佳实践同样可以应用到移动应用使用的Web服务器上。

安全问题最常见的地方可能就是Android开发者把不安全的用户名、密码、ID、密钥、数据库等内容留在了shared preferences里以及database文件夹当中。

所有通过互联网传输的敏感信息都应该通过安全连接来传输。你的应用是否使用了带SSL签名证书的SSL，让SSL代理工具不能从中读取信息？

这包括了发送用户未授权的个人信息给第三方。这会发生在当你发送数据到事件日志或者文件当中，而其他应用能够读取到时。它也可能是第三方广告库引起的，这些广告库收集地理位置（或者其他）信息，然后在你不知情的情况下发送回另一个数据库。

如果应用允许用户创建一个账户，那么密码应该包含4个以上的字符。4位的PIN码并不安全，是否针对暴力破解攻击做了检查？如果应用允许离线使用，密码存储在哪？别人是不是可以在Android文件系统上找到密码？

查看用来解密密码或者其他数据的密钥是否存储在源代码中或者存储在一个本地的数据库中。

混合的或者跨平台的应用可以用SQL注入攻击破解。确保SQL注入在用户名和密码等字段不起作用。

别人会滥用开发者无条件的信任，所以我们需要知道怎么避免落入这种陷阱。注意其他应用和来源输入不安全的数据的迹象。Android intents用来在应用间传递信息，别人可以用intent来绕过IPC或者说进程间通信的Android权限问题。

用户登录的session通常在关掉应用程序之后都没终止。这让应用关掉之后，下一次别人在平板电脑上启动这个应用的时候，用户在应用中还是处于登录状态，那别人继续使用这个应用的时候，用户的信用卡信息以及其他信息都可以被别人看到了。

混淆你的代码，这样它就不会被逆向工程完全转换回源代码了。不幸的是混淆并不是万能的。使用混淆让黑客破解你的应用更繁琐一点，但不要因此认为没有人能够反编译你的APK了。

5. Forrester Research发布的在移动应用开发中非技术性安全问题的Top 10

Forrester Research公司的Tyler Shields提出了一个很不一样的非技术性移动安全风险Top 10的清单，但是它和前面的清单一样是适用的。这份清单很好地解释了当前移动开发方面的安全状态。

（1）缺乏开发者激励。

（2）缺少移动方面的安全教育。

（3）缺乏移动开发安全方面可用的资源。

（4）安全问题没有考虑到人的因素。

（5）去除了开发者在安全方面的责任。

（6）忽略了业务需求。

（7）保护移动安全，也就意味着保护敏捷开发的安全性。

（8）关注安全性从而忽略了隐私保护。

（9）设计、开发和质量保证都缺乏安全性。

（10）作为附加的安全性：产品后期处理的安全性。

下面的清单简单地对每个Top 10条目进行了解释。

（1）缺乏开发者激励。开发者没有得到适当的激励来编写安全的代码。

（2）缺少移动方面的安全教育。开发者不理解移动应用和一般的应用在结构和安全性上的细微差别。

（3）缺乏移动开发安全方面可用的资源。移动开发安全方面的资源严重不足且负担过重，使得缺少安全性成为意料之中的事。

（4）安全问题没有考虑到人的因素。移动安全方面的人的因素和非移动方面是很不一样的。安全问题如果不考虑人的因素，就会导致做出不是最合适的决策和控制。

（5）去除了开发者在安全方面的责任。改进工具和框架的安全性，但是不能仅仅依靠工具来加强安全编码的方法。

（6）忽略了业务需求。开发者需要理解他们开发的产品的业务需求。在什么都不清楚的情况下会开发出很差劲的业务解决方案。

（7）保护移动安全，也就意味着保护敏捷开发的安全性。移动开发已经改变了开发的形式。更短的开发周期以及更小的开发团队使得企业开发团队要重新思考他们的开发流程。

（8）关注安全性从而忽略了隐私保护。安全和隐私问题是相互缠绕不可分离的。如果你忽略了其中一个，那么另一个也不会好到哪里去。

（9）设计、开发和质量评价时缺乏安全性考虑。安全的开发生命周期这个概念已经被讨论了很长时间了。它甚至依然还可以应用在我们看到的修改过的移动开发周期上。改进你的SDLC（secure development lifecycle）来减少你的缺陷数量。

（10）作为附加的安全性工具：产品后期处理的安全性。作为产品后期处理的安全性工具，应用加壳和应用加固可以提高你发布产品的安全性的标准。这不会影响到你应用中其他安全层面的内容。

以上内容节选自《构建安全的Android App》

内容简介

本书适合Android开发人员、安全技术人员阅读，也可以作为大中专院校相关专业师生的学习用书和培训机构的教材。

本文转载自异步社区。

Web应用防火墙 WAF

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。