android - 为安全而设计 - 3 - 开发文档翻译 - 12

We prefer use of HTTPS over HTTP anywhere that HTTPS is supported on the server, since mobile devices frequently connect on networks that are not secured, such as public WiFi hotspots.

android上面的网络与Linux环境上的差别不是很大

主要考虑的是保证对敏感数据使用适当的协议，比如使用HTTPS进行网络传输

我们在任何服务器支持HTTPS的地方更愿意使用HTTPS而不是HTTP，因为移动设备频繁连接不安全的网络，比如公共的WiFi热点。

Authenticated, encrypted socket-level communication can be easily implemented using the SSLSocket class.

Given the frequency with which Android devices connect to unsecured wireless networks using WiFi, the use of secure networking is strongly encouraged for all applications.

认证的、加密的socket级别的通信可以使用SSLSocket类轻松的实现

根据Android设备使用WiFi连接不安全网络的频率，对于所有应用来说，使用安全网络是强烈被支持的。

We have seen some applications use localhost network ports for handling sensitive IPC.

We discourage this approach since these interfaces are accessible by other applications on the device.

Instead, use an Android IPC mechanism where authentication is possible such as a Service and Binder. (Even worse than using loopback is to bind to INADDR_ANY since then your application may receive requests from anywhere. We’ve seen that, too.)

我们见过一些应用使用本地网络端口处理敏感的IPC

我们不鼓励这种方法因为这些接口是可以被设备上的其他应用访问的

取而代之，在可以认证的地方使用一个android IPC机制，例如Service和Binder。（比使用回环还糟的是绑定INADDR_ANY，因为你的应用也许收到任何地方来的请求。我们也已经见识过了）

Also, one common issue that warrants repeating is to make sure that you do not trust data downloaded from HTTP or other insecure protocols.

This includes validation of input in WebView and any responses to intents issued against HTTP.

一个有必要重复的常见的议题是，保证你不信任从HTTP或者其他不安全协议下载的数据

这包括在WebView中的输入验证和相对于http的intent任何相应

Using Telephony Networking

使用电话网络

SMS is the telephony protocol most frequently used by Android developers.

Developers should keep in mind that this protocol was primarily designed for user-to-user communication and is not well-suited for some application purposes.

Due to the limitations of SMS, we strongly recommend the use of C2DM and IP networking for sending data messages to devices.

SMS是Android开发者使用最频繁的电话协议

开发者应该记住这个协议主要是设计为用户与用户之间的交流，它并不适用一些应用的目的

由于SMS的限制，我们强烈建议适用C2DM和IP网络发送数据消息给设备

Many developers do not realize that SMS is not encrypted or strongly authenticated on the network or on the device.

In particular, any SMS receiver should expect that a malicious user may have sent the SMS to your application -- do not rely on unauthenticated SMS data to perform sensitive commands.

Also, you should be aware that SMS may be subject to spoofing and/or interception on the network.

On the Android-powered device itself, SMS messages are transmitted as Broadcast intents, so they may be read or captured by other applications that have the READ_SMS permission.

很多开发者没有意识到SMS在网络上或者设备上不是加密的或者牢固验证的

尤其是，任何SMS接收者应该预料到恶意用户也许已经给你的应用发送了SMS -- 不要指望未验证的SMS数据执行敏感操作

你也应该注意到SMS在网络上也许会遭到冒名顶替并且/或者拦截

在Android设备本身上面，SMS消息是通过广播intent传递的，所以他们也许会被其他拥有READ_SMS许可的应用阅读或者掠夺

Dynamically Loading Code

动态加载代码

We strongly discourage loading code from outside of the application APK.

Doing so significantly increases the likelihood of application compromise due to code injection or code tampering.

It also adds complexity around version management and application testing.

Finally, it can make it impossible to verify the behavior of an application, so it may be prohibited in some environments.

我们强烈不鼓励从应用apk文件外加载代码

这样做显著增加了应用泄漏的可能，取决于代码注入或者代码篡改

也增加了版本管理和应用测试的复杂性

最终，它会使得不可验证一个应用的行为，所以它也许在一些环境下被进制

If your application does dynamically load code, the most important thing to keep in mind about dynamically loaded code is that it runs with the same security permissions as the application APK.

The user made a decision to install your application based on your identity, and they are expecting that you provide any code run within the application, including code that is dynamically loaded.

如果你的应用确实动态加载了代码，最重要的事情是记住运行动态加载的代码与应用apk具有相同的安全许可

用户决定安装你的应用是基于你的id，他们期望你提供任何在应用内运行的代码，包括动态加载的代码

The major security risk associated with dynamically loading code is that the code needs to come from a verifiable source.

If the modules are included directly within your APK, then they cannot be modified by other applications.

This is true whether the code is a native library or a class being loaded using DexClassLoader.

We have seen many instances of applications attempting to load code from insecure locations, such as downloaded from the network over unencrypted protocols or from world writable locations such as external storage.

These locations could allow someone on the network to modify the content in transit, or another application on a users device to modify the content, respectively.

与动态加载代码结合的重要的安全风险是代码需要代码需要来自可信资源

如果这个模块是之间在你的apk中包含，那么他们不能被其他应用修改

不论代码是本地库或者是使用DexClassLoader加载的类这都是事实

我们见过很多应用实例尝试从不安全的位置加载代码，比如从网络上通过非加密的协议下载或者从world writable位置（比如外部存储）

这些位置会允许网络上的人在传输过程中修改其内容，或者允许用户设备上的另一个应用修改其内容

Using WebView

使用WebView

Since WebView consumes web content that can include HTML and JavaScript, improper use can introduce common web security issues such as cross-site-scripting (JavaScript injection).

Android includes a number of mechanisms to reduce the scope of these potential issues by limiting the capability of WebView to the minimum functionality required by your application.

因为WebView能包含HTML和JavaScript浏览网络内容，不恰当的使用会引入常见的web安全问题，比如跨站脚本攻击（JavaScript注入）

Android包含一些机制通过限制WebView的能力到你应用请求的功能最小化来减少这些潜在问题的范围

If your application does not directly use JavaScript within a WebView, do not call setJavaScriptEnabled().

We have seen this method invoked in sample code that might be repurposed in production application -- so remove it if necessary.

By default, WebView does not execute JavaScript so cross-site-scripting is not possible.

如果你的应用没有在WebView内直接使用JavaScript，不要调用setJavaScriptEnabled()

我们见过这个方法在简单的代码中执行，也许会导致在产品应用中改变用途 -- 所以如果必要的化移除它

默认的，WebView不执行JavaScript，所以跨站脚本攻击不可能产生

Use addJavaScriptInterface() with particular care because it allows JavaScript to invoke operations that are normally reserved for Android applications.

Only expose addJavaScriptInterface() to sources from which all input is trustworthy.

If untrusted input is allowed, untrusted JavaScript may be able to invoke Android methods.

In general, we recommend only exposing addJavaScriptInterface() to JavaScript that is contained within your application APK.

使用addJavaScriptInterface()要特别的小心，因为它允许JavaScript执行通常保留给Android应用的操作

只把addJavaScriptInterface()暴露给可靠的输入源

如果不受信任的输入是被允许的，不受信任的JavaScript也许会执行Android方法

总的来说，我们建议只把addJavaScriptInterface()暴露给你应用apk内包含的JavaScript

Do not trust information downloaded over HTTP, use HTTPS instead.

Even if you are connecting only to a single website that you trust or control, HTTP is subject to MiTM attacks and interception of data.

Sensitive capabilities using addJavaScriptInterface() should not ever be exposed to unverified script downloaded over HTTP.

Note that even with the use of HTTPS, addJavaScriptInterface() increases the attack surface of your application to include the server infrastructure and all CAs trusted by the Android-powered device.

不要信任通过HTTP下载的信息，取而代之，使用HTTPS

即使你只是正在连接一个你信任或者你控制的网站，HTTP也是受控于中间人攻击和拦截数据的

使用addJavaScriptInterface()的敏感的能力绝不应该暴露给通过HTTP下载的未验证的脚本

注意，即使使用HTTPS，addJavaScriptInterface()也会增加你应用的攻击面来包含服务器基本结构和所有Android设备信任的CA

If your application accesses sensitive data with a WebView, you may want to use the clearCache() method to delete any files stored locally.

Server side headers like no-cache can also be used to indicate that an application should not cache particular content.

如果你的应用通过WebView访问敏感数据，你也许想要使用clearCache()方法来删除任何存储到本地的文件

服务端的header，比如no-cache，能用于指示应用不应该缓存特定的内容

Performing Input Validation

执行输入验证

Insufficient input validation is one of the most common security problems affecting applications, regardless of what platform they run on.

Android does have platform-level countermeasures that reduce the exposure of applications to input validation issues, you should use those features where possible.

Also note that selection of type-safe languages tends to reduce the likelihood of input validation issues.

We strongly recommend building your applications with the Android SDK.

不管应用运行在什么平台上，功能不完善的输入验证是最常见的影响应用安全问题之一

Android有平台级别的对策，用于减少应用的公开输入验证问题，你应该在可能的地方使用这些功能

同样需要注意的是，安全类型语言的选择倾向去减少输入验证问题的可能

我们强烈建议使用Android SDK建立你的应用

If you are using native code, then any data read from files, received over the network, or received from an IPC has the potential to introduce a security issue.

The most common problems arebuffer overflows,use after free, andoff-by-one errors.

Android provides a number of technologies like ASLR and DEP that reduce the exploitability of these errors, but they do not solve the underlying problem.

These can be prevented by careful handling of pointers and managing of buffers.

如果你使用native代码，那么任何从文件读取的数据，通过网络接收的，或者通过IPC接收的都有可能引入安全问题

最常见的问题是缓存溢出，释放后使用，和off-by-one错误

Android提供一些技术比如ASLR和DEP减少这些错误的可利用性，但是他们没有解决基本的问题

小心处理指针和管理缓存可以预防这些问题

Dynamic, string based languages such as JavaScript and SQL are also subject to input validation problems due to escape characters andscript injection.

动态，基于语言的字符串，比如JavaScript和SQL，都常遭受由转义字符和脚本注入带来的输入验证问题

If you are using data within queries that are submitted to SQL Database or a Content Provider, SQL Injection may be an issue.

The best defense is to use parameterized queries, as is discussed in the ContentProviders section.

Limiting permissions to read-only or write-only can also reduce the potential for harm related to SQL Injection.

如果你使用提交到SQL Database或者Content Provider查询中数据，SQL也许会是个问题

最好的防御是使用参数化的查询，同ContentProviders中讨论的那样

限制权限为只读或者只写可以减少SQL注入潜在危害

If you are using WebView, then you must consider the possibility of XSS.

If your application does not directly use JavaScript within a WebView, do not call setJavaScriptEnabled() and XSS is no longer possible.

If you must enable JavaScript then the WebView section provides other security best practices.

如果你使用WebView，那么你必须考虑XSS的可能性

如果你的应用没有直接在WebView内使用JavaScript，不要调用setJavaScriptEnabled()，那么XSS攻击就不再有效了

如果你必须启用JavaScript，那么WebView章节提供其他安全最佳实践

If you cannot use the security features above, we strongly recommend the use of well-structured data formats and verifying that the data conforms to the expected format.

While blacklisting of characters or character-replacement can be an effective strategy, these techniques are error-prone in practice and should be avoided when possible.

如果你不能使用上面提到的安全功能，我们强烈建议使用结构严谨的数据格式并且验证符合期望的格式

零壹方面，黑名单中的字符或者要替换的字符是一种有效的策略，这些技术在实践中是易错并且当可能发生的时候应该避免

Handling User Data

处理用户数据

In general, the best approach is to minimize use of APIs that access sensitive or personal user data.

If you have access to data and can avoid storing or transmitting the information, do not store or transmit the data.

Finally, consider if there is a way that your application logic can be implemented using a hash or non-reversible form of the data.

For example, your application might use the hash of an an email address as a primary key, to avoid transmitting or storing the email address.

This reduces the chances of inadvertently exposing data, and it also reduces the chance of attackers attempting to exploit your application.

大体上说，最好的处理方法是最小化反问敏感或个人数据的API使用

如果你有对数据的访问并且可以避免存储或者传输信息，那就不要存储或者传输数据

最后，考虑如果有一种你的应用逻辑可能被实现为使用hash或者不可逆形式的数据的方法

例如，你的应用也许使用一个email地址的hash作为主键，避免传输或存储email地址

这减少无意暴露数据的机会，并且它也能减少攻击者尝试利用你的应用的机会

If your application accesses personal information such as passwords or usernames, keep in mind that some jurisdictions may require you to provide a privacy policy explaining your use and storage of that data.

So following the security best practice of minimizing access to user data may also simplify compliance.

如果你的应用访问私人数据，比如密码或者用户名，记住司法权也许要求你提供一个你使用和存储这些数据的隐私策略的解释

所以采用最小化访问用户数据的安全最佳实践也许也是单纯的顺从

You should also consider whether your application might be inadvertently exposing personal information to other parties such as third-party components for advertising or third-party services used by your application.

If you don't know why a component or service requires a personal information, don’t provide it.

In general, reducing the access to personal information by your application will reduce the potential for problems in this area.

你也应该考虑你应用是否会疏忽的暴露个人信息给其他方，比如广告第三方组件或者你应用使用的第三方服务。

如果你不知道为什么一个组件或者服务请求个人信息，那么就不要提供给它

大体上说，通过减少你应用中访问个人信息，将会减少这个区域潜在的问题

If access to sensitive data is required, evaluate whether that information must be transmitted to a server, or whether the operation can be performed on the client.

Consider running any code using sensitive data on the client to avoid transmitting user data.

如果必须访问敏感数据，

评估这个信息是否必须要传到服务器，或者是否可以被客户端操作

考虑客户端上使用敏感数据运行的任何代码避免传输用户数据

Also, make sure that you do not inadvertently expose user data to other application on the device through overly permissive IPC, world writable files, or network sockets.

This is a special case of permission redelegation, discussed in the Requesting Permissions section.

保证你不会无意中通过过渡自由的IPC，world writable文件，或者网络socket暴露用户数据给其他设备上的应用

这事一个再次授权的特别的例子，在请求权限章节中讨论

If a GUID is required, create a large, unique number and store it.

Do not use phone identifiers such as the phone number or IMEI which may be associated with personal information.

This topic is discussed in more detail in the Android Developer Blog.

如果请求全球唯一标识符，建立一个大的，唯一的数字并保存它

不要使用电话标识，比如与个人信息相关的电话号码或者IMEI

这个话题在Android Developer Blog中有更详细的讨论

Application developers should be careful writing to on-device logs.

In Android, logs are a shared resource, and are available to an application with the READ_LOGS permission.

Even though the phone log data is temporary and erased on reboot, inappropriate logging of user information could inadvertently leak user data to other applications.

应用开发这应该谨慎的把log写到机器上

在Android中，log是共享资源，一个带有READ_LOGS许可的应用可以访问

即使电话log数据是临时的并且在重启之后会擦除，不恰当的记录用户信息也会无意的泄漏用户数据给其他应用

Handling Credentials

处理证书

In general, we recommend minimizing the frequency of asking for user credentials -- to make phishing attacks more conspicuous, and less likely to be successful.

Instead use an authorization token and refresh it.

大体上说，我们建议请求用户证书频率最小化 -- 使得钓鱼攻击更明显，并且降低其成功的可能

取而代之使用授权令牌然后刷新它

Where possible, username and password should not be stored on the device.

Instead, perform initial authentication using the username and password supplied by the user, and then use a short-lived, service-specific authorization token.

可能的情况下，用户名和密码不应该存储到设备上

取而代之，使用用户提供的用户名和密码执行初始认证，然后使用一个短暂的，特定服务的授权令牌

Services that will be accessible to multiple applications should be accessed using AccountManager.

If possible, use the AccountManager class to invoke a cloud-based service and do not store passwords on the device.

可以被多个应用访问的service应该使用AccountManager访问

如果可能的话，使用AccountManager类来执行基于云的服务并且不把密码存储到设备上

After using AccountManager to retrieve an Account, check the CREATOR before passing in any credentials, so that you do not inadvertently pass credentials to the wrong application.

使用AccountManager获取Account之后，进入任何证书前检查CREATOR，这样你就不会因为疏忽而把证书传递给错误的应用

If credentials are to be used only by applications that you create, then you can verify the application which accesses the AccountManager using checkSignature(). Alternatively, if only one application will use the credential, you might use a KeyStore for storage.

如果证书只是用于你建立的应用，那么你能使用checkSignature()验证访问AccountManager的应用

另一种选择，如果一个应用要使用证书，你可以使用一个KeyStore来储存

Using Cryptography

使用加密技术

In addition to providing data isolation, supporting full-filesystem encryption, and providing secure communications channels

Android provides a wide array of algorithms for protecting data using cryptography.

除了提供数据隔离之外，支持完整的文件系统加密，并且提供安全交流通道

Android提供大量加密算法来保护数据

In general, try to use the highest level of pre-existing framework implementation that can support your use case.

If you need to securely retrieve a file from a known location, a simple HTTPS URI may be adequate and require no knowledge of cryptography on your part.

If you need a secure tunnel, consider using HttpsURLConnection or SSLSocket, rather than writing your own protocol.

大体上说，尝试使用最高级别的以存在framework的实现能支持你的用例

如果你需要安全的从一个已知的位置取回一个文件，一个简单的HTTPS URI也许就足够了，并且这部分不要求任何加密知识

如果你需要一个安全隧道，考虑使用HttpsURLConnection或者SSLSocket，要比使用你自己的协议好

If you do find yourself needing to implement your own protocol, we strongly recommend that you not implement your own cryptographic algorithms.

Use existing cryptographic algorithms such as those in the implementation of AES or RSA provided in the Cipher class.

如果你发现你的确需要实现你自己的协议，我们强烈建议你不要实现你自己的加密算法

使用已经存在的加密算法，比如Cipher类中提供的AES或者RSA的实现

Use a secure random number generator ( SecureRandom) to initialize any cryptographic keys ( KeyGenerator).

Use of a key that is not generated with a secure random number generator significantly weakens the strength of the algorithm, and may allow offline attacks.

使用一个安全的随机数生成器（SecureRandom）来初始化加密的key（KeyGenerator）

使用一个不受由安全随机数生成器生成的key严重削弱算法的优点，而且有能允许线下攻击

If you need to store a key for repeated use, use a mechanism like KeyStore that provides a mechanism for long term storage and retrieval of cryptographic keys.

如果你需要存储一个key来重复使用，使用类似于KeyStore的机制，提供一种机制长期储存和检索加密的key

Conclusion

结论

Android provides developers with the ability to design applications with a broad range of security requirements.

These best practices will help you make sure that your application takes advantage of the security benefits provided by the platform.

Android为有能力的开发者提供广泛的安全需求设计应用

这些最佳实践将会帮助你保证你的应用利用系统提供的安全性优点

You can receive more information on these topics and discuss security best practices with other developers in the Android Security Discuss Google Group

你可以在这些话题上获得更多信息，同其他开发者在Android Security DiscussGoogle Group讨论安全最佳实践

原文地址如下，英文水平实在有限，希望拍砖同时能给予指正。

http://developer.android.com/guide/practices/security.html

转贴请保留以下链接

本人blog地址

http://su1216.iteye.com/

http://blog.csdn.net/su1216/

分享到：