| page.title=Security Tips |
| page.article=true |
| @jd:body |
| |
| <div id="tb-wrapper"> |
| <div id="tb"> |
| <h2>In this document</h2> |
| <ol class="nolist"> |
| <li><a href="#StoringData">Storing Data</a></li> |
| <li><a href="#Permissions">Using Permissions</a></li> |
| <li><a href="#Networking">Using Networking</a></li> |
| <li><a href="#InputValidation">Performing Input Validation</a></li> |
| <li><a href="#UserData">Handling User Data</a></li> |
| <li><a href="#WebView">Using WebView</a></li> |
| <li><a href="#Crypto">Using Cryptography</a></li> |
| <li><a href="#IPC">Using Interprocess Communication</a></li> |
| <li><a href="#DynamicCode">Dynamically Loading Code</a></li> |
| <li><a href="#Dalvik">Security in a Virtual Machine</a></li> |
| <li><a href="#Native">Security in Native Code</a></li> |
| </ol> |
| <h2>See also</h2> |
| <ul> |
| <li><a href="http://source.android.com/tech/security/index.html">Android |
| Security Overview</a></li> |
| <li><a href="{@docRoot}guide/topics/security/permissions.html">Permissions</a></li> |
| </ul> |
| </div></div> |
| |
| |
| <p>Android has security features built |
| into the operating system that significantly reduce the frequency and impact of |
| application security issues. The system is designed so you can typically build your apps with |
| default system and file permissions and avoid difficult decisions about security.</p> |
| |
| <p>Some of the core security features that help you build secure apps |
| include: |
| <ul> |
| <li>The Android Application Sandbox, which isolates your app data and code execution |
| from other apps.</li> |
| <li>An application framework with robust implementations of common |
| security functionality such as cryptography, permissions, and secure |
| <acronym title="Interprocess Communication">IPC</acronym>.</li> |
| <li>Technologies like ASLR, NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD |
| calloc, and Linux mmap_min_addr to mitigate risks associated with common memory |
| management errors.</li> |
| <li>An encrypted filesystem that can be enabled to protect data on lost or |
| stolen devices.</li> |
| <li>User-granted permissions to restrict access to system features and user data.</li> |
| <li>Application-defined permissions to control application data on a per-app basis.</li> |
| </ul> |
| |
| <p>Nevertheless, it is important that you be familiar with the Android |
| security best practices in this document. Following these practices as general coding habits |
| will reduce the likelihood of inadvertently introducing security issues that |
| adversely affect your users.</p> |
| |
| |
| |
| <h2 id="StoringData">Storing Data</h2> |
| |
| <p>The most common security concern for an application on Android is whether the data |
| that you save on the device is accessible to other apps. There are three fundamental |
| ways to save data on the device:</p> |
| |
| <h3 id="InternalStorage">Using internal storage</h3> |
| |
| <p>By default, files that you create on <a |
| href="{@docRoot}guide/topics/data/data-storage.html#filesInternal">internal |
| storage</a> are accessible only to your app. This |
| protection is implemented by Android and is sufficient for most |
| applications.</p> |
| |
| <p>You should generally avoid using the {@link android.content.Context#MODE_WORLD_WRITEABLE} or |
| {@link android.content.Context#MODE_WORLD_READABLE} modes for |
| <acronym title="Interprocess Communication">IPC</acronym> files because they do not provide |
| the ability to limit data access to particular applications, nor do they |
| provide any control on data format. If you want to share your data with other |
| app processes, you might instead consider using a |
| <a href="{@docRoot}guide/topics/providers/content-providers.html">content provider</a>, which |
| offers read and write permissions to other apps and can make |
| dynamic permission grants on a case-by-case basis.</p> |
| |
| <p>To provide additional protection for sensitive data, you might |
| choose to encrypt local files using a key that is not directly accessible to the |
| application. For example, a key can be placed in a {@link java.security.KeyStore} |
| and protected with a user password that is not stored on the device. While this |
| does not protect data from a root compromise that can monitor the user |
| inputting the password, it can provide protection for a lost device without <a |
| href="http://source.android.com/tech/encryption/index.html">file system |
| encryption</a>.</p> |
| |
| |
| <h3 id="ExternalStorage">Using external storage</h3> |
| |
| <p>Files created on <a |
| href="{@docRoot}guide/topics/data/data-storage.html#filesExternal">external |
| storage</a>, such as SD Cards, are globally readable and writable. Because |
| external storage can be removed by the user and also modified by any |
| application, you should not store sensitive information using |
| external storage.</p> |
| |
| <p>As with data from any untrusted source, you should <a href="#InputValidation">perform input |
| validation</a> when handling data from external storage. |
| We strongly recommend that you not store executables or |
| class files on external storage prior to dynamic loading. If your app |
| does retrieve executable files from external storage, the files should be signed and |
| cryptographically verified prior to dynamic loading.</p> |
| |
| |
| <h3 id="ContentProviders">Using content providers</h3> |
| |
| <p><a href="{@docRoot}guide/topics/providers/content-providers.html">Content providers</a> |
| offer a structured storage mechanism that can be limited |
| to your own application or exported to allow access by other applications. |
| If you do not intend to provide other |
| applications with access to your {@link android.content.ContentProvider}, mark them as <code><a |
| href="{@docRoot}guide/topics/manifest/provider-element.html#exported"> |
| android:exported=false</a></code> in the application manifest. Otherwise, set the <code><a |
| href="{@docRoot}guide/topics/manifest/provider-element.html#exported">android:exported</a></code> |
| attribute {@code "true"} to allow other apps to access the stored data. |
| </p> |
| |
| <p>When creating a {@link android.content.ContentProvider} |
| that will be exported for use by other applications, you can specify a single |
| <a href="{@docRoot}guide/topics/manifest/provider-element.html#prmsn">permission |
| </a> for reading and writing, or distinct permissions for reading and writing |
| within the manifest. We recommend that you limit your permissions to those |
| required to accomplish the task at hand. Keep in mind that it’s usually |
| easier to add permissions later to expose new functionality than it is to take |
| them away and break existing users.</p> |
| |
| <p>If you are using a content provider |
| for sharing data between only your own apps, it is preferable to use the |
| <a href="{@docRoot}guide/topics/manifest/permission-element.html#plevel">{@code |
| android:protectionLevel}</a> attribute set to {@code "signature"} protection. |
| Signature permissions do not require user confirmation, |
| so they provide a better user experience and more controlled access to the |
| content provider data when the apps accessing the data are |
| <a href="{@docRoot}tools/publishing/app-signing.html">signed</a> with |
| the same key.</p> |
| |
| <p>Content providers can also provide more granular access by declaring the <a |
| href="{@docRoot}guide/topics/manifest/provider-element.html#gprmsn">{@code |
| android:grantUriPermissions}</a> attribute and using the {@link |
| android.content.Intent#FLAG_GRANT_READ_URI_PERMISSION} and {@link |
| android.content.Intent#FLAG_GRANT_WRITE_URI_PERMISSION} flags in the |
| {@link android.content.Intent} object |
| that activates the component. The scope of these permissions can be further |
| limited by the <code><a |
| href="{@docRoot}guide/topics/manifest/grant-uri-permission-element.html"> |
| <grant-uri-permission element></a></code>.</p> |
| |
| <p>When accessing a content provider, use parameterized query methods such as |
| {@link android.content.ContentProvider#query(Uri,String[],String,String[],String) query()}, |
| {@link android.content.ContentProvider#update(Uri,ContentValues,String,String[]) update()}, and |
| {@link android.content.ContentProvider#delete(Uri,String,String[]) delete()} to avoid |
| potential SQL injection from untrusted sources. Note that using parameterized methods is not |
| sufficient if the <code>selection</code> argument is built by concatenating user data |
| prior to submitting it to the method.</p> |
| |
| <p>Do not have a false sense of security about the write permission. Consider |
| that the write permission allows SQL statements which make it possible for some |
| data to be confirmed using creative <code>WHERE</code> clauses and parsing the |
| results. For example, an attacker might probe for presence of a specific phone |
| number in a call-log by modifying a row only if that phone number already |
| exists. If the content provider data has predictable structure, the write |
| permission may be equivalent to providing both reading and writing.</p> |
| |
| |
| |
| |
| |
| |
| |
| <h2 id="Permissions">Using Permissions</h2> |
| |
| <p>Because Android sandboxes applications from each other, applications must explicitly |
| share resources and data. They do this by declaring the permissions they need for additional |
| capabilities not provided by the basic sandbox, including access to device features such as |
| the camera.</p> |
| |
| |
| <h3 id="RequestingPermissions">Requesting Permissions</h3> |
| |
| <p>We recommend minimizing the number of permissions that your app requests. |
| Not having access to sensitive permissions reduces the risk of |
| inadvertently misusing those permissions, can improve user adoption, and makes |
| your app less vulnerable for attackers. Generally, |
| if a permission is not required for your app to function, do not request it.</p> |
| |
| <p>If it's possible to design your application in a way that does not require |
| any permissions, that is preferable. For example, rather than requesting access |
| to device information to create a unique identifier, create a <a |
| href="{@docRoot}reference/java/util/UUID.html">GUID</a> for your application |
| (see the section about <a href="#UserData">Handling User Data</a>). Or, rather than |
| using external storage (which requires permission), store data |
| on the internal storage.</p> |
| |
| <p>In addition to requesting permissions, your application can use the <a |
| href="{@docRoot}guide/topics/manifest/permission-element.html">{@code <permissions>}</a> |
| to protect IPC that is security sensitive and will be exposed to other |
| applications, such as a {@link android.content.ContentProvider}. |
| In general, we recommend using access controls |
| other than user confirmed permissions where possible because permissions can |
| be confusing for users. For example, consider using the <a |
| href="{@docRoot}guide/topics/manifest/permission-element.html#plevel">signature |
| protection level</a> on permissions for IPC communication between applications |
| provided by a single developer.</p> |
| |
| <p>Do not leak permission-protected data. This occurs when your app exposes data |
| over IPC that is only available because it has a specific permission, but does |
| not require that permission of any clients of it’s IPC interface. More |
| details on the potential impacts, and frequency of this type of problem is |
| provided in this research paper published at USENIX: <a |
| href="http://www.cs.berkeley.edu/~afelt/felt_usenixsec2011.pdf">http://www.cs.be |
| rkeley.edu/~afelt/felt_usenixsec2011.pdf</a></p> |
| |
| |
| |
| <h3 id="CreatingPermissions">Creating Permissions</h3> |
| |
| <p>Generally, you should strive to define as few permissions as possible while |
| satisfying your security requirements. Creating a new permission is relatively |
| uncommon for most applications, because the <a |
| href="{@docRoot}reference/android/Manifest.permission.html">system-defined |
| permissions</a> cover many situations. Where appropriate, |
| perform access checks using existing permissions.</p> |
| |
| <p>If you must create a new permission, consider whether you can accomplish |
| your task with a <a |
| href="{@docRoot}guide/topics/manifest/permission-element.html#plevel">"signature" |
| protection level</a>. Signature permissions are transparent |
| to the user and only allow access by applications signed by the same developer |
| as application performing the permission check.</p> |
| |
| <p>If you create a permission with the <a |
| href="{@docRoot}guide/topics/manifest/permission-element.html#plevel">"dangerous" |
| protection level</a>, there are a number of complexities |
| that you need to consider: |
| <ul> |
| <li>The permission must have a string that concisely expresses to a user the |
| security decision they will be required to make.</li> |
| <li>The permission string must be localized to many different languages.</li> |
| <li>Users may choose not to install an application because a permission is |
| confusing or perceived as risky.</li> |
| <li>Applications may request the permission when the creator of the permission |
| has not been installed.</li> |
| </ul> |
| |
| <p>Each of these poses a significant non-technical challenge for you as the developer |
| while also confusing your users, |
| which is why we discourage the use of the "dangerous" permission level.</p> |
| |
| |
| |
| |
| |
| <h2 id="Networking">Using Networking</h2> |
| |
| <p>Network transactions are inherently risky for security, because it involves transmitting |
| data that is potentially private to the user. People are increasingly aware of the privacy |
| concerns of a mobile device, especially when the device performs network transactions, |
| so it's very important that your app implement all best practices toward keeping the user's |
| data secure at all times.</p> |
| |
| <h3 id="IPNetworking">Using IP Networking</h3> |
| |
| <p>Networking on Android is not significantly different from other Linux |
| environments. The key consideration is making sure that appropriate protocols |
| are used for sensitive data, such as {@link javax.net.ssl.HttpsURLConnection} for |
| secure web traffic. We prefer use of HTTPS over HTTP anywhere that HTTPS is |
| supported on the server, because mobile devices frequently connect on networks |
| that are not secured, such as public Wi-Fi hotspots.</p> |
| |
| <p>Authenticated, encrypted socket-level communication can be easily |
| implemented using the {@link javax.net.ssl.SSLSocket} |
| class. Given the frequency with which Android devices connect to unsecured |
| wireless networks using Wi-Fi, the use of secure networking is strongly |
| encouraged for all applications that communicate over the network.</p> |
| |
| <p>We have seen some applications use <a |
| href="http://en.wikipedia.org/wiki/Localhost">localhost</a> network ports for |
| handling sensitive IPC. We discourage this approach since these interfaces are |
| accessible by other applications on the device. Instead, you should use an Android IPC |
| mechanism where authentication is possible such as with a {@link android.app.Service}. (Even |
| worse than using loopback is to bind to INADDR_ANY since then your application |
| may receive requests from anywhere.)</p> |
| |
| <p>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 {@link android.webkit.WebView} and |
| any responses to intents issued against HTTP.</p> |
| |
| |
| <h3>Using Telephony Networking</h3> |
| |
| <p>The <acronym title="Short Message Service">SMS</acronym> protocol was primarily designed for |
| user-to-user communication and is not well-suited for apps that want to transfer data. |
| Due to the limitations of SMS, we strongly recommend the use of <a |
| href="{@docRoot}google/gcm/index.html">Google Cloud Messaging</a> (GCM) |
| and IP networking for sending data messages from a web server to your app on a user device.</p> |
| |
| <p>Beware that SMS is neither encrypted nor strongly |
| authenticated on either the network or 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 {@link android.Manifest.permission#READ_SMS} |
| permission.</p> |
| |
| |
| |
| |
| |
| <h2 id="InputValidation">Performing Input Validation</h2> |
| |
| <p>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 and you should use those features where possible. Also |
| note that selection of type-safe languages tends to reduce the likelihood of |
| input validation issues.</p> |
| |
| <p>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 are <a |
| href="http://en.wikipedia.org/wiki/Buffer_overflow">buffer overflows</a>, <a |
| href="http://en.wikipedia.org/wiki/Double_free#Use_after_free">use after |
| free</a>, and <a |
| href="http://en.wikipedia.org/wiki/Off-by-one_error">off-by-one errors</a>. |
| Android provides a number of technologies like <acronym |
| title="Address Space Layout Randomization">ASLR</acronym> and <acronym |
| title="Data Execution Prevention">DEP</acronym> that reduce the |
| exploitability of these errors, but they do not solve the underlying problem. |
| You can prevent these vulneratbilities by careful handling pointers and managing |
| buffers.</p> |
| |
| <p>Dynamic, string based languages such as JavaScript and SQL are also subject |
| to input validation problems due to escape characters and <a |
| href="http://en.wikipedia.org/wiki/Code_injection">script injection</a>.</p> |
| |
| <p>If you are using data within queries that are submitted to an 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 above section about <a |
| href="#ContentProviders">content providers</a>. |
| Limiting permissions to read-only or write-only can also reduce the potential |
| for harm related to SQL injection.</p> |
| |
| <p>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.</p> |
| |
| |
| |
| |
| |
| <h2 id="UserData">Handling User Data</h2> |
| |
| <p>In general, the best approach for user data security is to minimize the use of APIs that access |
| sensitive or personal user data. If you have access to user 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.</p> |
| |
| <p>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.</p> |
| |
| <p>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.</p> |
| |
| <p>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.</p> |
| |
| <p>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 leaking permission-protected data, |
| discussed in the <a href="#RequestingPermissions">Requesting Permissions</a> section.</p> |
| |
| <p>If a <acronym title="Globally Unique Identifier">GUID</acronym> |
| 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 <a |
| href="http://android-developers.blogspot.com/2011/03/identifying-app-installations.html">Android |
| Developer Blog</a>.</p> |
| |
| <p>Be careful when writing to on-device logs. |
| In Android, logs are a shared resource, and are available |
| to an application with the {@link android.Manifest.permission#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.</p> |
| |
| |
| |
| |
| |
| |
| <h2 id="WebView">Using WebView</h2> |
| |
| <p>Because {@link android.webkit.WebView} consumes web content that can include HTML and JavaScript, |
| improper use can introduce common web security issues such as <a |
| href="http://en.wikipedia.org/wiki/Cross_site_scripting">cross-site-scripting</a> |
| (JavaScript injection). Android includes a number of mechanisms to reduce |
| the scope of these potential issues by limiting the capability of {@link android.webkit.WebView} to |
| the minimum functionality required by your application.</p> |
| |
| <p>If your application does not directly use JavaScript within a {@link android.webkit.WebView}, do |
| <em>not</em> call {@link android.webkit.WebSettings#setJavaScriptEnabled setJavaScriptEnabled()}. |
| Some sample code uses this method, which you might repurpose in production |
| application, so remove that method call if it's not required. By default, |
| {@link android.webkit.WebView} does |
| not execute JavaScript so cross-site-scripting is not possible.</p> |
| |
| <p>Use {@link android.webkit.WebView#addJavascriptInterface |
| addJavaScriptInterface()} with |
| particular care because it allows JavaScript to invoke operations that are |
| normally reserved for Android applications. If you use it, expose |
| {@link android.webkit.WebView#addJavascriptInterface addJavaScriptInterface()} only to |
| web pages from which all input is trustworthy. If untrusted input is allowed, |
| untrusted JavaScript may be able to invoke Android methods within your app. In general, we |
| recommend exposing {@link android.webkit.WebView#addJavascriptInterface |
| addJavaScriptInterface()} only to JavaScript that is contained within your application APK.</p> |
| |
| <p>If your application accesses sensitive data with a |
| {@link android.webkit.WebView}, you may want to use the |
| {@link android.webkit.WebView#clearCache clearCache()} method to delete any files stored |
| locally. Server-side |
| headers like <code>no-cache</code> can also be used to indicate that an application should |
| not cache particular content.</p> |
| |
| <p>Devices running platforms older than Android 4.4 (API level 19) |
| use a version of {@link android.webkit webkit} that has a number of security issues. |
| As a workaround, if your app is running on these devices, it |
| should confirm that {@link android.webkit.WebView} objects display only trusted |
| content. You should also use the updatable security {@link |
| java.security.Provider Provider} object to make sure your app isn’t exposed to |
| potential vulnerabilities in SSL, as described in <a |
| href="{@docRoot}training/articles/security-gms-provider.html">Updating Your |
| Security Provider to Protect Against SSL Exploits</a>. If your application must |
| render content from the open web, consider providing your own renderer so |
| you can keep it up to date with the latest security patches.</p> |
| |
| |
| <h3 id="Credentials">Handling Credentials</h3> |
| |
| <p>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.</p> |
| |
| <p>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.</p> |
| |
| <p>Services that will be accessible to multiple applications should be accessed |
| using {@link android.accounts.AccountManager}. If possible, use the |
| {@link android.accounts.AccountManager} class to invoke a cloud-based service and do not store |
| passwords on the device.</p> |
| |
| <p>After using {@link android.accounts.AccountManager} to retrieve an |
| {@link android.accounts.Account}, {@link android.accounts.Account#CREATOR} |
| before passing in any credentials, so that you do not inadvertently pass |
| credentials to the wrong application.</p> |
| |
| <p>If credentials are to be used only by applications that you create, then you |
| can verify the application which accesses the {@link android.accounts.AccountManager} using |
| {@link android.content.pm.PackageManager#checkSignatures checkSignature()}. |
| Alternatively, if only one application will use the credential, you might use a |
| {@link java.security.KeyStore} for storage.</p> |
| |
| |
| |
| |
| |
| <h2 id="Crypto">Using Cryptography</h2> |
| |
| <p>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.</p> |
| |
| <p>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 |
| requires no knowledge of cryptography. If you need a secure |
| tunnel, consider using {@link javax.net.ssl.HttpsURLConnection} or |
| {@link javax.net.ssl.SSLSocket}, rather than writing your own protocol.</p> |
| |
| <p>If you do find yourself needing to implement your own protocol, we strongly |
| recommend that you <em>not</em> implement your own cryptographic algorithms. Use |
| existing cryptographic algorithms such as those in the implementation of AES or |
| RSA provided in the {@link javax.crypto.Cipher} class.</p> |
| |
| <p>Use a secure random number generator, {@link java.security.SecureRandom}, |
| to initialize any cryptographic keys, {@link javax.crypto.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.</p> |
| |
| <p>If you need to store a key for repeated use, use a mechanism like |
| {@link java.security.KeyStore} that |
| provides a mechanism for long term storage and retrieval of cryptographic |
| keys.</p> |
| |
| |
| |
| |
| |
| <h2 id="IPC">Using Interprocess Communication</h2> |
| |
| <p>Some apps attempt to implement IPC using traditional Linux |
| techniques such as network sockets and shared files. We strongly encourage you to instead |
| use Android system functionality for IPC such as {@link android.content.Intent}, |
| {@link android.os.Binder} or {@link android.os.Messenger} with a {@link |
| android.app.Service}, and {@link android.content.BroadcastReceiver}. |
| The Android IPC mechanisms allow you to verify the identity of |
| the application connecting to your IPC and set security policy for each IPC |
| mechanism.</p> |
| |
| <p>Many of the security elements are shared across IPC mechanisms. |
| If your IPC mechanism is not intended for use by other applications, set the |
| {@code android:exported} attribute to {@code "false"} in the component's manifest element, |
| such as for the <a |
| href="{@docRoot}guide/topics/manifest/service-element.html#exported">{@code <service>}</a> |
| element. This is useful for applications that consist of multiple processes |
| within the same UID, or if you decide late in development that you do not |
| actually want to expose functionality as IPC but you don’t want to rewrite |
| the code.</p> |
| |
| <p>If your IPC is intended to be accessible to other applications, you can |
| apply a security policy by using the <a |
| href="{@docRoot}guide/topics/manifest/permission-element.html">{@code <permission>}</a> |
| element. If IPC is between your own separate apps that are signed with the same key, |
| it is preferable to use {@code "signature"} level permission in the <a |
| href="{@docRoot}guide/topics/manifest/permission-element.html#plevel">{@code |
| android:protectionLevel}</a>.</p> |
| |
| |
| |
| |
| <h3>Using intents</h3> |
| |
| <p>Intents are the preferred mechanism for asynchronous IPC in Android. |
| Depending on your application requirements, you might use {@link |
| android.content.Context#sendBroadcast sendBroadcast()}, {@link |
| android.content.Context#sendOrderedBroadcast sendOrderedBroadcast()}, |
| or an explicit intent to a specific application component.</p> |
| |
| <p>Note that ordered broadcasts can be “consumed” by a recipient, so they |
| may not be delivered to all applications. If you are sending an intent that must be delivered |
| to a specific receiver, then you must use an explicit intent that declares the receiver |
| by nameintent.</p> |
| |
| <p>Senders of an intent can verify that the recipient has a permission |
| specifying a non-Null permission with the method call. Only applications with that |
| permission will receive the intent. If data within a broadcast intent may be |
| sensitive, you should consider applying a permission to make sure that |
| malicious applications cannot register to receive those messages without |
| appropriate permissions. In those circumstances, you may also consider |
| invoking the receiver directly, rather than raising a broadcast.</p> |
| |
| <p class="note"><strong>Note:</strong> Intent filters should not be considered |
| a security feature—components |
| can be invoked with explicit intents and may not have data that would conform to the intent |
| filter. You should perform input validation within your intent receiver to |
| confirm that it is properly formatted for the invoked receiver, service, or |
| activity.</p> |
| |
| |
| |
| |
| <h3 id="Services">Using services</h3> |
| |
| <p>A {@link android.app.Service} is often used to supply functionality for other applications to |
| use. Each service class must have a corresponding <a |
| href="{@docRoot}guide/topics/manifest/service-element.html">{@code <service>}</a> declaration in its |
| manifest file.</p> |
| |
| <p>By default, services are not exported and cannot be invoked by any other |
| application. However, if you add any intent filters to the service declaration, then it is exported |
| by default. It's best if you explicitly declare the <a |
| href="{@docRoot}guide/topics/manifest/service-element.html#exported">{@code |
| android:exported}</a> attribute to be sure it behaves as you'd like. |
| Services can also be protected using the <a |
| href="{@docRoot}guide/topics/manifest/service-element.html#prmsn">{@code android:permission}</a> |
| attribute. By doing so, other applications will need to declare |
| a corresponding <code><a |
| href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><uses-permission></a> |
| </code> element in their own manifest to be |
| able to start, stop, or bind to the service.</p> |
| |
| <p>A service can protect individual IPC calls into it with permissions, by |
| calling {@link android.content.Context#checkCallingPermission |
| checkCallingPermission()} before executing |
| the implementation of that call. We generally recommend using the |
| declarative permissions in the manifest, since those are less prone to |
| oversight.</p> |
| |
| |
| |
| <h3>Using binder and messenger interfaces</h3> |
| |
| <p>Using {@link android.os.Binder} or {@link android.os.Messenger} is the |
| preferred mechanism for RPC-style IPC in Android. They provide a well-defined |
| interface that enables mutual authentication of the endpoints, if required.</p> |
| |
| <p>We strongly encourage designing interfaces in a manner that does not require |
| interface specific permission checks. {@link android.os.Binder} and |
| {@link android.os.Messenger} objects are not declared within the |
| application manifest, and therefore you cannot apply declarative permissions |
| directly to them. They generally inherit permissions declared in the |
| application manifest for the {@link android.app.Service} or {@link |
| android.app.Activity} within which they are |
| implemented. If you are creating an interface that requires authentication |
| and/or access controls, those controls must be |
| explicitly added as code in the {@link android.os.Binder} or {@link android.os.Messenger} |
| interface.</p> |
| |
| <p>If providing an interface that does require access controls, use {@link |
| android.content.Context#checkCallingPermission checkCallingPermission()} |
| to verify whether the |
| caller has a required permission. This is especially important |
| before accessing a service on behalf of the caller, as the identify of your |
| application is passed to other interfaces. If invoking an interface provided |
| by a {@link android.app.Service}, the {@link |
| android.content.Context#bindService bindService()} |
| invocation may fail if you do not have permission to access the given service. |
| If calling an interface provided locally by your own application, it may be |
| useful to use the {@link android.os.Binder#clearCallingIdentity clearCallingIdentity()} |
| to satisfy internal security checks.</p> |
| |
| <p>For more information about performing IPC with a service, see |
| <a href="{@docRoot}guide/components/bound-services.html">Bound Services</a>.</p> |
| |
| |
| |
| <h3 id="BroadcastReceivers">Using broadcast receivers</h3> |
| |
| <p>A {@link android.content.BroadcastReceiver} handles asynchronous requests initiated by |
| an {@link android.content.Intent}.</p> |
| |
| <p>By default, receivers are exported and can be invoked by any other |
| application. If your {@link android.content.BroadcastReceiver} |
| is intended for use by other applications, you |
| may want to apply security permissions to receivers using the <code><a |
| href="{@docRoot}guide/topics/manifest/receiver-element.html"> |
| <receiver></a></code> element within the application manifest. This will |
| prevent applications without appropriate permissions from sending an intent to |
| the {@link android.content.BroadcastReceiver}.</p> |
| |
| |
| |
| |
| |
| |
| |
| |
| <h2 id="DynamicCode">Dynamically Loading Code</h2> |
| |
| <p>We strongly discourage loading code from outside of your 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.</p> |
| |
| <p>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.</p> |
| |
| <p>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 |
| {@link dalvik.system.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 on the device, respectively.</p> |
| |
| |
| |
| |
| |
| <h2 id="Dalvik">Security in a Virtual Machine</h2> |
| |
| <p>Dalvik is Android's runtime virtual machine (VM). Dalvik was built specifically for Android, |
| but many of the concerns regarding secure code in other virtual machines also apply to Android. |
| In general, you shouldn't concern yourself with security issues relating to the virtual machine. |
| Your application runs in a secure sandbox environment, so other processes on the system cannnot |
| access your code or private data.</p> |
| |
| <p>If you're interested in diving deeper on the subject of virtual machine security, |
| we recommend that you familiarize yourself with some |
| existing literature on the subject. Two of the more popular resources are: |
| <ul> |
| <li><a href="http://www.securingjava.com/toc.html"> |
| http://www.securingjava.com/toc.html</a></li> |
| <li><a |
| href="https://www.owasp.org/index.php/Java_Security_Resources"> |
| https://www.owasp.org/index.php/Java_Security_Resources</a></li> |
| </ul></p> |
| |
| <p>This document is focused on the areas which are Android specific or |
| different from other VM environments. For developers experienced with VM |
| programming in other environments, there are two broad issues that may be |
| different about writing apps for Android: |
| <ul> |
| <li>Some virtual machines, such as the JVM or .net runtime, act as a security |
| boundary, isolating code from the underlying operating system capabilities. On |
| Android, the Dalvik VM is not a security boundary—the application sandbox is |
| implemented at the OS level, so Dalvik can interoperate with native code in the |
| same application without any security constraints.</li> |
| |
| <li>Given the limited storage on mobile devices, it’s common for developers |
| to want to build modular applications and use dynamic class loading. When |
| doing this, consider both the source where you retrieve your application logic |
| and where you store it locally. Do not use dynamic class loading from sources |
| that are not verified, such as unsecured network sources or external storage, |
| because that code might be modified to include malicious behavior.</li> |
| </ul> |
| |
| |
| |
| <h2 id="Native">Security in Native Code</h2> |
| |
| <p>In general, we encourage developers to use the Android SDK for |
| application development, rather than using native code with the |
| <a href="{@docRoot}tools/sdk/ndk/index.html">Android NDK</a>. Applications built |
| with native code are more complex, less portable, and more like to include |
| common memory corruption errors such as buffer overflows.</p> |
| |
| <p>Android is built using the Linux kernel and being familiar with Linux |
| development security best practices is especially useful if you are going to |
| use native code. Linux security practices are beyond the scope of this document, |
| but one of the most popular resources is “Secure Programming for |
| Linux and Unix HOWTO”, available at <a |
| href="http://www.dwheeler.com/secure-programs"> |
| http://www.dwheeler.com/secure-programs</a>.</p> |
| |
| <p>An important difference between Android and most Linux environments is the |
| Application Sandbox. On Android, all applications run in the Application |
| Sandbox, including those written with native code. At the most basic level, a |
| good way to think about it for developers familiar with Linux is to know that |
| every application is given a unique <acronym title="User Identifier">UID</acronym> |
| with very limited permissions. This is discussed in more detail in the <a |
| href="http://source.android.com/tech/security/index.html">Android Security |
| Overview</a> and you should be familiar with application permissions even if |
| you are using native code.</p> |
| |