Adrian Ludwig | 2435940 | 2011-11-07 09:24:23 -0800 | [diff] [blame] | 1 | page.title=Designing for Security |
| 2 | @jd:body |
| 3 | |
| 4 | <div id="qv-wrapper"> |
| 5 | <div id="qv"> |
| 6 | <h2>In this document</h2> |
| 7 | <ol> |
| 8 | <li><a href="#Dalvik">Using Davlik Code</a></li> |
| 9 | <li><a href="#Native">Using Native Code</a></li> |
| 10 | <li><a href="#Data">Storing Data</a></li> |
| 11 | <li><a href="#IPC">Using IPC</a></li> |
| 12 | <li><a href="#Permissions">Using Permissions</a></li> |
| 13 | <li><a href="#Networking">Using Networking</a></li> |
| 14 | <li><a href="#DynamicCode">Dynamically Loading Code</a></li> |
| 15 | <li><a href="#Input">Performing Input Validation</a></li> |
| 16 | <li><a href="#UserData">Handling User Data</a></li> |
| 17 | <li><a href="#Crypto">Using Cryptography</a></li> |
| 18 | </ol> |
| 19 | <h2>See also</h2> |
| 20 | <ol> |
| 21 | <li><a href="http://source.android.com/tech/security/index.html">Android |
| 22 | Security Overview</a></li> |
| 23 | <li><a href="{@docRoot}guide/topics/security/security.html">Android Security |
| 24 | And Permissions</a></li> |
| 25 | </ol> |
| 26 | </div></div> |
| 27 | <p>Android was designed so that most developers will be able to build |
| 28 | applications using the default settings and not be confronted with difficult |
| 29 | decisions about security. Android also has a number of security features built |
| 30 | into the operating system that significantly reduce the frequency and impact of |
| 31 | application security issues.</p> |
| 32 | |
| 33 | <p>Some of the security features that help developers build secure applications |
| 34 | include: |
| 35 | <ul> |
| 36 | <li>The Android Application Sandbox that isolates data and code execution on a |
| 37 | per-application basis.</li> |
| 38 | <li>Android application framework with robust implementations of common |
| 39 | security functionality such as cryptography, permissions, and secure IPC.</li> |
| 40 | <li>Technologies like ASLR, NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD |
| 41 | calloc, and Linux mmap_min_addr to mitigate risks associated with common memory |
| 42 | management errors</li> |
| 43 | <li>An encrypted filesystem that can be enabled to protect data on lost or |
| 44 | stolen devices.</li> |
| 45 | </ul></p> |
| 46 | |
| 47 | <p>Nevertheless, it is important for developers to be familiar with Android |
| 48 | security best practices to make sure they take advantage of these capabilities |
| 49 | and to reduce the likelihood of inadvertently introducing security issues that |
| 50 | can affect their applications.</p> |
| 51 | |
| 52 | <p>This document is organized around common APIs and development techniques |
| 53 | that can have security implications for your application and its users. As |
| 54 | these best practices are constantly evolving, we recommend you check back |
| 55 | occasionally throughout your application development process.</p> |
| 56 | |
| 57 | <a name="Dalvik"></a> |
| 58 | <h2>Using Dalvik Code</h2> |
| 59 | <p>Writing secure code that runs in virtual machines is a well-studied topic |
| 60 | and many of the issues are not specific to Android. Rather than attempting to |
| 61 | rehash these topics, we’d recommend that you familiarize yourself with the |
| 62 | existing literature. Two of the more popular resources are: |
| 63 | <ul> |
| 64 | <li><a href="http://www.securingjava.com/toc.html"> |
| 65 | http://www.securingjava.com/toc.html</a></li> |
| 66 | <li><a |
| 67 | href="https://www.owasp.org/index.php/Java_Security_Resources"> |
| 68 | https://www.owasp.org/index.php/Java_Security_Resources</a></li> |
| 69 | </ul></p> |
| 70 | |
| 71 | <p>This document is focused on the areas which are Android specific and/or |
| 72 | different from other environments. For developers experienced with VM |
| 73 | programming in other environments, there are two broad issues that may be |
| 74 | different about writing apps for Android: |
| 75 | <ul> |
| 76 | <li>Some virtual machines, such as the JVM or .net runtime, act as a security |
| 77 | boundary, isolating code from the underlying operating system capabilities. On |
| 78 | Android, the Dalvik VM is not a security boundary -- the application sandbox is |
| 79 | implemented at the OS level, so Dalvik can interoperate with native code in the |
| 80 | same application without any security constraints.</li> |
| 81 | <li>Given the limited storage on mobile devices, it’s common for developers |
| 82 | to want to build modular applications and use dynamic class loading. When |
| 83 | doing this consider both the source where you retrieve your application logic |
| 84 | and where you store it locally. Do not use dynamic class loading from sources |
| 85 | that are not verified, such as unsecured network sources or external storage, |
| 86 | since that code can be modified to include malicious behavior.</li> |
| 87 | </ul></p> |
| 88 | |
| 89 | <a name="Native"></a> |
| 90 | <h2>Using Native Code</h2> |
| 91 | |
| 92 | <p>In general, we encourage developers to use the Android SDK for most |
| 93 | application development, rather than using native code. Applications built |
| 94 | with native code are more complex, less portable, and more like to include |
| 95 | common memory corruption errors such as buffer overflows.</p> |
| 96 | |
| 97 | <p>Android is built using the Linux kernel and being familiar with Linux |
| 98 | development security best practices is especially useful if you are going to |
| 99 | use native code. This document is too short to discuss all of those best |
| 100 | practices, but one of the most popular resources is “Secure Programming for |
| 101 | Linux and Unix HOWTO”, available at <a |
| 102 | href="http://www.dwheeler.com/secure-programs"> |
| 103 | http://www.dwheeler.com/secure-programs</a>.</p> |
| 104 | |
| 105 | <p>An important difference between Android and most Linux environments is the |
| 106 | Application Sandbox. On Android, all applications run in the Application |
| 107 | Sandbox, including those written with native code. At the most basic level, a |
| 108 | good way to think about it for developers familiar with Linux is to know that |
| 109 | every application is given a unique UID with very limited permissions. This is |
| 110 | discussed in more detail in the <a |
| 111 | href="http://source.android.com/tech/security/index.html">Android Security |
| 112 | Overview</a> and you should be familiar with application permissions even if |
| 113 | you are using native code.</p> |
| 114 | |
| 115 | <a name="Data"></a> |
| 116 | <h2>Storing Data</h2> |
| 117 | |
| 118 | <h3>Using internal files</h3> |
| 119 | |
| 120 | <p>By default, files created on <a |
| 121 | href="{@docRoot}guide/topics/data/data-storage.html#filesInternal">internal |
| 122 | storage</a> are only accessible to the application that created the file. This |
| 123 | protection is implemented by Android and is sufficient for most |
| 124 | applications.</p> |
| 125 | |
| 126 | <p>Use of <a |
| 127 | href="{@docRoot}reference/android/content/Context.html#MODE_WORLD_WRITEABLE"> |
| 128 | world writable</a> or <a |
| 129 | href="{@docRoot}reference/android/content/Context.html#MODE_WORLD_READABLE |
| 130 | ">world readable</a> files for IPC is discouraged because it does not provide |
| 131 | the ability to limit data access to particular applications, nor does it |
| 132 | provide any control on data format. As an alternative, you might consider using |
| 133 | a ContentProvider which provides read and write permissions, and can make |
| 134 | dynamic permission grants on a case-by-case basis.</p> |
| 135 | |
| 136 | <p>To provide additional protection for sensitive data, some applications |
| 137 | choose to encrypt local files using a key that is not accessible to the |
| 138 | application. (For example, a key can be placed in a <code><a |
| 139 | href={@docRoot}reference/java/security/KeyStore.html">KeyStore</a></code> and |
| 140 | protected with a user password that is not stored on the device). While this |
| 141 | does not protect data from a root compromise that can monitor the user |
| 142 | inputting the password, it can provide protection for a lost device without <a |
| 143 | href="http://source.android.com/tech/encryption/index.html">file system |
| 144 | encryption</a>.</p> |
| 145 | |
| 146 | <h3>Using external storage</h3> |
| 147 | |
| 148 | <p>Files created on <a |
| 149 | href="{@docRoot}guide/topics/data/data-storage.html#filesExternal">external |
| 150 | storage</a>, such as SD Cards, are globally readable and writable. Since |
| 151 | external storage can be removed by the user and also modified by any |
| 152 | application, applications should not store sensitive information using |
| 153 | external storage.</p> |
| 154 | |
| 155 | <p>As with data from any untrusted source, applications should perform input |
| 156 | validation when handling data from external storage (see Input Validation |
| 157 | section). We strongly recommend that applications not store executables or |
| 158 | class files on external storage prior to dynamic loading. If an application |
| 159 | does retrieve executable files from external storage they should be signed and |
| 160 | cryptographically verified prior to dynamic loading.</p> |
| 161 | |
| 162 | <h3>Using content providers</h3> |
| 163 | |
| 164 | <p>ContentProviders provide a structured storage mechanism that can be limited |
| 165 | to your own application, or exported to allow access by other applications. By |
| 166 | default, a <code> |
| 167 | <a href="{@docRoot}reference/android/content/ContentProvider.html"> |
| 168 | ContentProvider</a></code> is |
| 169 | <a href="{@docRoot}guide/topics/manifest/provider-element.html#exported">exported |
| 170 | </a> for use by other applications. If you do not intend to provide other |
| 171 | applications with access to your<code> |
| 172 | <a href="{@docRoot}reference/android/content/ContentProvider.html"> |
| 173 | ContentProvider</a></code>, mark them as <code><a |
| 174 | href="{@docRoot}guide/topics/manifest/provider-element.html#exported"> |
| 175 | android:exported=false</a></code> in the application manifest.</p> |
| 176 | |
| 177 | <p>When creating a <code> |
| 178 | <a href="{@docRoot}reference/android/content/ContentProvider.html">ContentProvider |
| 179 | </a></code> that will be exported for use by other applications, you can specify |
| 180 | a single |
| 181 | <a href="{@docRoot}guide/topics/manifest/provider-element.html#prmsn">permission |
| 182 | </a> for reading and writing, or distinct permissions for reading and writing |
| 183 | within the manifest. We recommend that you limit your permissions to those |
| 184 | required to accomplish the task at hand. Keep in mind that it’s usually |
| 185 | easier to add permissions later to expose new functionality than it is to take |
| 186 | them away and break existing users.</p> |
| 187 | |
| 188 | <p>If you are using a <code> |
| 189 | <a href="{@docRoot}reference/android/content/ContentProvider.html"> |
| 190 | ContentProvider</a></code> for sharing data between applications built by the |
| 191 | same developer, it is preferable to use |
| 192 | <a href="{@docRoot}guide/topics/manifest/permission-element.html#plevel">signature |
| 193 | level permissions</a>. Signature permissions do not require user confirmation, |
| 194 | so they provide a better user experience and more controlled access to the |
| 195 | <code> |
| 196 | <a href="{@docRoot}reference/android/content/ContentProvider.html"> |
| 197 | ContentProvider</a></code>.</p> |
| 198 | |
| 199 | <p>ContentProviders can also provide more granular access by declaring the <a |
| 200 | href="{@docRoot}guide/topics/manifest/provider-element.html#gprmsn"> |
| 201 | grantUriPermissions</a> element and using the <code><a |
| 202 | href="{@docRoot}reference/android/content/Intent.html#FLAG_GRANT_READ_URI_PERMIS |
| 203 | SION">FLAG_GRANT_READ_URI_PERMISSION</a></code> and <code><a |
| 204 | href="{@docRoot}reference/android/content/Intent.html#FLAG_GRANT_WRITE_URI_PERMI |
| 205 | SSION">FLAG_GRANT_WRITE_URI_PERMISSION</a></code> flags in the Intent object |
| 206 | that activates the component. The scope of these permissions can be further |
| 207 | limited by the <code><a |
| 208 | href="{@docRoot}guide/topics/manifest/grant-uri-permission-element.html"> |
| 209 | grant-uri-permission element</a></code>.</p> |
| 210 | |
| 211 | <p>When accessing a <code> |
| 212 | <a href="{@docRoot}reference/android/content/ContentProvider.html"> |
| 213 | ContentProvider</a></code>, use parameterized query methods such as <code> |
| 214 | <a href="{@docRoot}reference/android/content/ContentProvider.html#query(android.net |
| 215 | .Uri,%20java.lang.String[],%20java.lang.String,%20java.lang.String[],%20java.lan |
| 216 | g.String)">query()</a></code>, <code><a |
| 217 | href="{@docRoot}reference/android/content/ContentProvider.html#update(android.ne |
| 218 | t.Uri,%20android.content.ContentValues,%20java.lang.String,%20java.lang.String[] |
| 219 | )">update()</a></code>, and <code><a |
| 220 | href="{@docRoot}reference/android/content/ContentProvider.html#delete(android.ne |
| 221 | t.Uri,%20java.lang.String,%20java.lang.String[])">delete()</a></code> to avoid |
| 222 | potential <a href="http://en.wikipedia.org/wiki/SQL_injection">SQL |
| 223 | Injection</a> from untrusted data. Note that using parameterized methods is not |
| 224 | sufficient if the <code>selection</code> is built by concatenating user data |
| 225 | prior to submitting it to the method.</p> |
| 226 | |
| 227 | <p>Do not have a false sense of security about the write permission. Consider |
| 228 | that the write permission allows SQL statements which make it possible for some |
| 229 | data to be confirmed using creative <code>WHERE</code> clauses and parsing the |
| 230 | results. For example, an attacker might probe for presence of a specific phone |
| 231 | number in a call-log by modifying a row only if that phone number already |
| 232 | exists. If the content provider data has predictable structure, the write |
| 233 | permission may be equivalent to providing both reading and writing.</p> |
| 234 | |
| 235 | <a name="IPC"></a> |
| 236 | <h2>Using Interprocess Communication (IPC)</h2> |
| 237 | |
| 238 | <p>Some Android applications attempt to implement IPC using traditional Linux |
| 239 | techniques such as network sockets and shared files. We strongly encourage the |
| 240 | use of Android system functionality for IPC such as Intents, Binders, Services, |
| 241 | and Receivers. The Android IPC mechanisms allow you to verify the identity of |
| 242 | the application connecting to your IPC and set security policy for each IPC |
| 243 | mechanism.</p> |
| 244 | |
| 245 | <p>Many of the security elements are shared across IPC mechanisms. <a |
| 246 | href="{@docRoot}reference/android/content/BroadcastReceiver.html"> |
| 247 | Broadcast Receivers</a>, <a |
| 248 | href="{@docRoot}reference/android/R.styleable.html#AndroidManifestActivity"> |
| 249 | Activities</a>, and <a |
| 250 | href="{@docRoot}reference/android/R.styleable.html#AndroidManifestService"> |
| 251 | Services</a> are all declared in the application manifest. If your IPC mechanism is |
| 252 | not intended for use by other applications, set the android:exported property |
| 253 | to false. This is useful for applications that consist of multiple processes |
| 254 | within the same UID, or if you decide late in development that you do not |
| 255 | actually want to expose functionality as IPC but you don’t want to rewrite |
| 256 | the code.</p> |
| 257 | |
| 258 | <p>If your IPC is intended to be accessible to other applications, you can |
| 259 | apply a security policy by using the <a |
| 260 | href="{@docRoot}reference/android/R.styleable.html#AndroidManifestPermission"> |
| 261 | Permission</a> tag. If IPC is between applications built by the same developer, |
| 262 | it is preferable to use <a |
| 263 | href="{@docRoot}guide/topics/manifest/permission-element.html#plevel">signature |
| 264 | level permissions</a>. Signature permissions do not require user confirmation, |
| 265 | so they provide a better user experience and more controlled access to the IPC |
| 266 | mechanism.</p> |
| 267 | |
| 268 | <p>One area that can introduce confusion is the use of intent filters. Note |
| 269 | that Intent filters should not be considered a security feature -- components |
| 270 | can be invoked directly and may not have data that would conform to the intent |
| 271 | filter. You should perform input validation within your intent receiver to |
| 272 | confirm that it is properly formatted for the invoked receiver, service, or |
| 273 | activity.</p> |
| 274 | |
| 275 | <h3>Using intents</h3> |
| 276 | |
| 277 | <p>Intents are the preferred mechanism for asynchronous IPC in Android. |
| 278 | Depending on your application requirements, you might use <code><a |
| 279 | href="{@docRoot}reference/android/content/Context.html#sendBroadcast(android.con |
| 280 | tent.Intent)">sendBroadcast()</a></code>, <code><a |
| 281 | href="{@docRoot}reference/android/content/Context.html#sendOrderedBroadcast(andr |
| 282 | oid.content.Intent,%20java.lang.String)">sendOrderedBroadcast()</a></code>, or |
| 283 | direct an intent to a specific application component.</p> |
| 284 | |
| 285 | <p>Note that ordered broadcasts can be “consumed” by a recipient, so they |
| 286 | may not be delivered to all applications. If you are sending an Intent where |
| 287 | delivery to a specific receiver is required, the intent must be delivered |
| 288 | directly to the receiver.</p> |
| 289 | |
| 290 | <p>Senders of an intent can verify that the recipient has a permission |
| 291 | specifying a non-Null Permission upon sending. Only applications with that |
| 292 | Permission will receive the intent. If data within a broadcast intent may be |
| 293 | sensitive, you should consider applying a permission to make sure that |
| 294 | malicious applications cannot register to receive those messages without |
| 295 | appropriate permissions. In those circumstances, you may also consider |
| 296 | invoking the receiver directly, rather than raising a broadcast.</p> |
| 297 | |
| 298 | <h3>Using binder and AIDL interfaces</h3> |
| 299 | |
| 300 | <p><a href="{@docRoot}reference/android/os/Binder.html">Binders</a> are the |
| 301 | preferred mechanism for RPC-style IPC in Android. They provide a well-defined |
| 302 | interface that enables mutual authentication of the endpoints, if required.</p> |
| 303 | |
| 304 | <p>We strongly encourage designing interfaces in a manner that does not require |
| 305 | interface specific permission checks. Binders are not declared within the |
| 306 | application manifest, and therefore you cannot apply declarative permissions |
| 307 | directly to a Binder. Binders generally inherit permissions declared in the |
| 308 | application manifest for the Service or Activity within which they are |
| 309 | implemented. If you are creating an interface that requires authentication |
| 310 | and/or access controls on a specific binder interface, those controls must be |
| 311 | explicitly added as code in the interface.</p> |
| 312 | |
| 313 | <p>If providing an interface that does require access controls, use <code><a |
| 314 | href="{@docRoot}reference/android/content/Context.html#checkCallingPermission(ja |
| 315 | va.lang.String)">checkCallingPermission()</a></code> to verify whether the |
| 316 | caller of the Binder has a required permission. This is especially important |
| 317 | before accessing a Service on behalf of the caller, as the identify of your |
| 318 | application is passed to other interfaces. If invoking an interface provided |
| 319 | by a Service, the <code><a |
| 320 | href="{@docRoot}reference/android/content/Context.html#bindService(android.conte |
| 321 | nt.Intent,%20android.content.ServiceConnection,%20int)">bindService()</a></code> |
| 322 | invocation may fail if you do not have permission to access the given Service. |
| 323 | If calling an interface provided locally by your own application, it may be |
| 324 | useful to use the <code><a |
| 325 | href="{@docRoot}reference/android/os/Binder.html#clearCallingIdentity()"> |
| 326 | clearCallingIdentity()</a></code> to satisfy internal security checks.</p> |
| 327 | |
| 328 | <h3>Using broadcast receivers</h3> |
| 329 | |
| 330 | <p>Broadcast receivers are used to handle asynchronous requests initiated via |
| 331 | an intent.</p> |
| 332 | |
| 333 | <p>By default, receivers are exported and can be invoked by any other |
| 334 | application. If your <code><a |
| 335 | href={@docRoot}reference/android/content/BroadcastReceiver.html"> |
| 336 | BroadcastReceivers</a></code> is intended for use by other applications, you |
| 337 | may want to apply security permissions to receivers using the <code><a |
| 338 | href="{@docRoot}reference/android/R.styleable.html#AndroidManifestReceiver"> |
| 339 | <receiver></a></code> element within the application manifest. This will |
| 340 | prevent applications without appropriate permissions from sending an intent to |
| 341 | the <code><a |
| 342 | href={@docRoot}reference/android/content/BroadcastReceiver.html"> |
| 343 | BroadcastReceivers</a></code>.</p> |
| 344 | |
| 345 | <h3>Using Services</h3> |
| 346 | |
| 347 | <p>Services are often used to supply functionality for other applications to |
| 348 | use. Each service class must have a corresponding <service> declaration in its |
| 349 | package's AndroidManifest.xml.</p> |
| 350 | |
| 351 | <p>By default, Services are exported and can be invoked by any other |
| 352 | application. Services can be protected using the android:permission attribute |
| 353 | within the manifest’s <code><a |
| 354 | href="{@docRoot}reference/android/R.styleable.html#AndroidManifestService"> |
| 355 | <service></a></code> tag. By doing so, other applications will need to declare |
| 356 | a corresponding <code><a |
| 357 | href="{@docRoot}reference/android/R.styleable.html#AndroidManifestService_permis |
| 358 | sion"><uses-permission></a></code> element in their own manifest to be |
| 359 | able to start, stop, or bind to the service.</p> |
| 360 | |
| 361 | <p>A Service can protect individual IPC calls into it with permissions, by |
| 362 | calling <code><a |
| 363 | href="{@docRoot}reference/android/content/Context.html#checkCallingPermission(ja |
| 364 | va.lang.String)">checkCallingPermission()</a></code>before executing |
| 365 | the implementation of that call. We generally recommend using the |
| 366 | declarative permissions in the manifest, since those are less prone to |
| 367 | oversight.</p> |
| 368 | |
| 369 | <h3>Using Activities</h3> |
| 370 | |
| 371 | <p>Activities are most often used for providing the core user-facing |
| 372 | functionality of an application. By default, Activities are exported and |
| 373 | invokable by other applications only if they have an intent filter or binder |
| 374 | declared. In general, we recommend that you specifically declare a Receiver or |
| 375 | Service to handle IPC, since this modular approach reduces the risk of exposing |
| 376 | functionality that is not intended for use by other applications.</p> |
| 377 | |
| 378 | <p>If you do expose an Activity for purposes of IPC, the <code><a |
| 379 | href="{@docRoot}reference/android/R.styleable.html#AndroidManifestActivity_permi |
| 380 | ssion">android:permission</a></code> attribute in the <code><a |
| 381 | href="{@docRoot}reference/android/R.styleable.html#AndroidManifestActivity"> |
| 382 | <activity></a></code> declaration in the application manifest can be used to |
| 383 | restrict access to only those applications which have the stated |
| 384 | permissions.</p> |
| 385 | |
| 386 | <a name="Permissions"></a> |
| 387 | <h2>Using Permissions</h2> |
| 388 | |
| 389 | <h3>Requesting Permissions</h3> |
| 390 | |
| 391 | <p>We recommend minimizing the number of permissions requested by an |
| 392 | application. Not having access to sensitive permissions reduces the risk of |
| 393 | inadvertently misusing those permissions, can improve user adoption, and makes |
| 394 | applications less attractive targets for attackers.</p> |
| 395 | |
| 396 | <p>If it is possible to design your application in a way that does not require |
| 397 | a permission, that is preferable. For example, rather than requesting access |
| 398 | to device information to create an identifier, create a <a |
| 399 | href="{@docRoot}reference/java/util/UUID.html">GUID</a> for your application. |
| 400 | (This specific example is also discussed in Handling User Data) Or, rather than |
| 401 | using external storage, store data in your application directory.</p> |
| 402 | |
| 403 | <p>If a permission is not required, do not request it. This sounds simple, but |
| 404 | there has been quite a bit of research into the frequency of over-requesting |
| 405 | permissions. If you’re interested in the subject you might start with this |
| 406 | research paper published by U.C. Berkeley: <a |
| 407 | href="http://www.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-48.pdf"> |
| 408 | http://www.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-48.pdf</a></p> |
| 409 | |
| 410 | <p>In addition to requesting permissions, your application can use <a |
| 411 | href="{@docRoot}guide/topics/manifest/permission-element.html">permissions</a> |
| 412 | to protect IPC that is security sensitive and will be exposed to other |
| 413 | applications -- such as a <code><a |
| 414 | href="{@docRoot}reference/android/content/ContentProvider.html"> |
| 415 | ContentProvider</a></code>. In general, we recommend using access controls |
| 416 | other than user confirmed permissions where possible since permissions can |
| 417 | be confusing for users. For example, consider using the <a |
| 418 | href="{@docRoot}guide/topics/manifest/permission-element.html#plevel">signature |
| 419 | protection level</a> on permissions for IPC communication between applications |
| 420 | provided by a single developer.</p> |
| 421 | |
| 422 | <p>Do not cause permission re-delegation. This occurs when an app exposes data |
| 423 | over IPC that is only available because it has a specific permission, but does |
| 424 | not require that permission of any clients of it’s IPC interface. More |
| 425 | details on the potential impacts, and frequency of this type of problem is |
| 426 | provided in this research paper published at USENIX: <a |
| 427 | href="http://www.cs.berkeley.edu/~afelt/felt_usenixsec2011.pdf">http://www.cs.be |
| 428 | rkeley.edu/~afelt/felt_usenixsec2011.pdf</a></p> |
| 429 | |
| 430 | <h3>Creating Permissions</h3> |
| 431 | |
| 432 | <p>Generally, you should strive to create as few permissions as possible while |
| 433 | satisfying your security requirements. Creating a new permission is relatively |
| 434 | uncommon for most applications, since <a |
| 435 | href="{@docRoot}reference/android/Manifest.permission.html"> |
| 436 | system-defined permissions</a> cover many situations. Where appropriate, |
| 437 | perform access checks using existing permissions.</p> |
| 438 | |
| 439 | <p>If you must create a new permission, consider whether you can accomplish |
| 440 | your task with a Signature permission. Signature permissions are transparent |
| 441 | to the user and only allow access by applications signed by the same developer |
| 442 | as application performing the permission check. If you create a Dangerous |
| 443 | permission, then the user needs to decide whether to install the application. |
| 444 | This can be confusing for other developers, as well as for users.</p> |
| 445 | |
| 446 | <p>If you create a Dangerous permission, there are a number of complexities |
| 447 | that you need to consider. |
| 448 | <ul> |
| 449 | <li>The permission must have a string that concisely expresses to a user the |
| 450 | security decision they will be required to make.</li> |
| 451 | <li>The permission string must be localized to many different languages.</li> |
| 452 | <li>Uses may choose not to install an application because a permission is |
| 453 | confusing or perceived as risky.</li> |
| 454 | <li>Applications may request the permission when the creator of the permission |
| 455 | has not been installed.</li> |
| 456 | </ul></p> |
| 457 | |
| 458 | <p>Each of these poses a significant non-technical challenge for an application |
| 459 | developer, which is why we discourage the use of Dangerous permission.</p> |
| 460 | |
| 461 | <a name="Networking"></a> |
| 462 | <h2>Using Networking</h2> |
| 463 | |
| 464 | <h3>Using IP Networking</h3> |
| 465 | |
| 466 | <p>Networking on Android is not significantly different from Linux |
| 467 | environments. The key consideration is making sure that appropriate protocols |
| 468 | are used for sensitive data, such as <a |
| 469 | href="{@docRoot}reference/javax/net/ssl/HttpsURLConnection.html">HTTPS</a> for |
| 470 | web traffic. We prefer use of HTTPS over HTTP anywhere that HTTPS is |
| 471 | supported on the server, since mobile devices frequently connect on networks |
| 472 | that are not secured, such as public WiFi hotspots.</p> |
| 473 | |
| 474 | <p>Authenticated, encrypted socket-level communication can be easily |
| 475 | implemented using the <code><a |
| 476 | href="{@docRoot}reference/javax/net/ssl/SSLSocket.html">SSLSocket</a></code> |
| 477 | class. Given the frequency with which Android devices connect to unsecured |
| 478 | wireless networks using WiFi, the use of secure networking is strongly |
| 479 | encouraged for all applications.</p> |
| 480 | |
| 481 | <p>We have seen some applications use <a |
| 482 | href="http://en.wikipedia.org/wiki/Localhost">localhost</a> network ports for |
| 483 | handling sensitive IPC. We discourage this approach since these interfaces are |
| 484 | accessible by other applications on the device. Instead, use an Android IPC |
| 485 | mechanism where authentication is possible such as a Service and Binder. (Even |
| 486 | worse than using loopback is to bind to INADDR_ANY since then your application |
| 487 | may receive requests from anywhere. We’ve seen that, too.)</p> |
| 488 | |
| 489 | <p>Also, one common issue that warrants repeating is to make sure that you do |
| 490 | not trust data downloaded from HTTP or other insecure protocols. This includes |
| 491 | validation of input in <code><a |
| 492 | href="{@docRoot}reference/android/webkit/WebView.html">WebView</a></code> and |
| 493 | any responses to intents issued against HTTP.</p> |
| 494 | |
| 495 | <h3>Using Telephony Networking</h3> |
| 496 | |
| 497 | <p>SMS is the telephony protocol most frequently used by Android developers. |
| 498 | Developers should keep in mind that this protocol was primarily designed for |
| 499 | user-to-user communication and is not well-suited for some application |
| 500 | purposes. Due to the limitations of SMS, we strongly recommend the use of <a |
| 501 | href="http://code.google.com/android/c2dm/">C2DM</a> and IP networking for |
| 502 | sending data messages to devices.</p> |
| 503 | |
| 504 | <p>Many developers do not realize that SMS is not encrypted or strongly |
| 505 | authenticated on the network or on the device. In particular, any SMS receiver |
| 506 | should expect that a malicious user may have sent the SMS to your application |
| 507 | -- do not rely on unauthenticated SMS data to perform sensitive commands. |
| 508 | Also, you should be aware that SMS may be subject to spoofing and/or |
| 509 | interception on the network. On the Android-powered device itself, SMS |
| 510 | messages are transmitted as Broadcast intents, so they may be read or captured |
| 511 | by other applications that have the READ_SMS permission.</p> |
| 512 | |
| 513 | <a name="DynamicCode"></a> |
| 514 | <h2>Dynamically Loading Code</h2> |
| 515 | |
| 516 | <p>We strongly discourage loading code from outside of the application APK. |
| 517 | Doing so significantly increases the likelihood of application compromise due |
| 518 | to code injection or code tampering. It also adds complexity around version |
| 519 | management and application testing. Finally, it can make it impossible to |
| 520 | verify the behavior of an application, so it may be prohibited in some |
| 521 | environments.</p> |
| 522 | |
| 523 | <p>If your application does dynamically load code, the most important thing to |
| 524 | keep in mind about dynamically loaded code is that it runs with the same |
| 525 | security permissions as the application APK. The user made a decision to |
| 526 | install your application based on your identity, and they are expecting that |
| 527 | you provide any code run within the application, including code that is |
| 528 | dynamically loaded.</p> |
| 529 | |
| 530 | <p>The major security risk associated with dynamically loading code is that the |
| 531 | code needs to come from a verifiable source. If the modules are included |
| 532 | directly within your APK, then they cannot be modified by other applications. |
| 533 | This is true whether the code is a native library or a class being loaded using |
| 534 | <a href="{@docRoot}reference/dalvik/system/DexClassLoader.html"> |
| 535 | <code>DexClassLoader</code></a>. We have seen many instances of applications |
| 536 | attempting to load code from insecure locations, such as downloaded from the |
| 537 | network over unencrypted protocols or from world writable locations such as |
| 538 | external storage. These locations could allow someone on the network to modify |
| 539 | the content in transit, or another application on a users device to modify the |
| 540 | content, respectively.</p> |
| 541 | |
| 542 | |
| 543 | <h3>Using WebView</h3> |
| 544 | |
| 545 | <p>Since WebView consumes web content that can include HTML and JavaScript, |
| 546 | improper use can introduce common web security issues such as <a |
| 547 | href="http://en.wikipedia.org/wiki/Cross_site_scripting">cross-site-scripting</a |
| 548 | > (JavaScript injection). Android includes a number of mechanisms to reduce |
| 549 | the scope of these potential issues by limiting the capability of WebView to |
| 550 | the minimum functionality required by your application.</p> |
| 551 | |
| 552 | <p>If your application does not directly use JavaScript within a <code><a |
| 553 | href="{@docRoot}reference/android/webkit/WebView.html">WebView</a></code>, do |
| 554 | not call |
Adrian Ludwig | a15562f | 2011-12-15 15:37:33 -0800 | [diff] [blame] | 555 | <a href="{@docRoot}reference/android/webkit/WebSettings.html#setJavaScriptEnabled(boolean)"> |
Adrian Ludwig | 2435940 | 2011-11-07 09:24:23 -0800 | [diff] [blame] | 556 | <code>setJavaScriptEnabled()</code></a>. We have seen this method invoked |
| 557 | in sample code that might be repurposed in production application -- so |
| 558 | remove it if necessary. By default, <code><a |
| 559 | href="{@docRoot}reference/android/webkit/WebView.html">WebView</a></code> does |
| 560 | not execute JavaScript so cross-site-scripting is not possible.</p> |
| 561 | |
| 562 | <p>Use <code><a |
| 563 | href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(jav |
| 564 | a.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> with |
| 565 | particular care because it allows JavaScript to invoke operations that are |
| 566 | normally reserved for Android applications. Only expose <code><a |
| 567 | href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(jav |
| 568 | a.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> to |
| 569 | sources from which all input is trustworthy. If untrusted input is allowed, |
| 570 | untrusted JavaScript may be able to invoke Android methods. In general, we |
| 571 | recommend only exposing <code><a |
| 572 | href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(jav |
| 573 | a.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> to |
| 574 | JavaScript that is contained within your application APK.</p> |
| 575 | |
| 576 | <p>Do not trust information downloaded over HTTP, use HTTPS instead. Even if |
| 577 | you are connecting only to a single website that you trust or control, HTTP is |
| 578 | subject to <a |
| 579 | href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack">MiTM</a> attacks |
| 580 | and interception of data. Sensitive capabilities using <code><a |
| 581 | href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(jav |
| 582 | a.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> should |
| 583 | not ever be exposed to unverified script downloaded over HTTP. Note that even |
| 584 | with the use of HTTPS, |
| 585 | <code><a |
| 586 | href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(jav |
| 587 | a.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> |
| 588 | increases the attack surface of your application to include the server |
| 589 | infrastructure and all CAs trusted by the Android-powered device.</p> |
| 590 | |
| 591 | <p>If your application accesses sensitive data with a <code><a |
| 592 | href="{@docRoot}reference/android/webkit/WebView.html">WebView</a></code>, you |
| 593 | may want to use the <code><a |
| 594 | href="{@docRoot}reference/android/webkit/WebView.html#clearCache(boolean)"> |
| 595 | clearCache()</a></code> method to delete any files stored locally. Server side |
| 596 | headers like no-cache can also be used to indicate that an application should |
| 597 | not cache particular content.</p> |
| 598 | |
| 599 | <a name="Input"></a> |
| 600 | <h2>Performing Input Validation</h2> |
| 601 | |
| 602 | <p>Insufficient input validation is one of the most common security problems |
| 603 | affecting applications, regardless of what platform they run on. Android does |
| 604 | have platform-level countermeasures that reduce the exposure of applications to |
| 605 | input validation issues, you should use those features where possible. Also |
| 606 | note that selection of type-safe languages tends to reduce the likelihood of |
| 607 | input validation issues. We strongly recommend building your applications with |
| 608 | the Android SDK.</p> |
| 609 | |
| 610 | <p>If you are using native code, then any data read from files, received over |
| 611 | the network, or received from an IPC has the potential to introduce a security |
| 612 | issue. The most common problems are <a |
| 613 | href="http://en.wikipedia.org/wiki/Buffer_overflow">buffer overflows</a>, <a |
| 614 | href="http://en.wikipedia.org/wiki/Double_free#Use_after_free">use after |
| 615 | free</a>, and <a |
| 616 | href="http://en.wikipedia.org/wiki/Off-by-one_error">off-by-one errors</a>. |
| 617 | Android provides a number of technologies like ASLR and DEP that reduce the |
| 618 | exploitability of these errors, but they do not solve the underlying problem. |
| 619 | These can be prevented by careful handling of pointers and managing of |
| 620 | buffers.</p> |
| 621 | |
| 622 | <p>Dynamic, string based languages such as JavaScript and SQL are also subject |
| 623 | to input validation problems due to escape characters and <a |
| 624 | href="http://en.wikipedia.org/wiki/Code_injection">script injection</a>.</p> |
| 625 | |
| 626 | <p>If you are using data within queries that are submitted to SQL Database or a |
| 627 | Content Provider, SQL Injection may be an issue. The best defense is to use |
| 628 | parameterized queries, as is discussed in the ContentProviders section. |
| 629 | Limiting permissions to read-only or write-only can also reduce the potential |
| 630 | for harm related to SQL Injection.</p> |
| 631 | |
| 632 | <p>If you are using <code><a |
| 633 | href="{@docRoot}reference/android/webkit/WebView.html">WebView</a></code>, then |
| 634 | you must consider the possibility of XSS. If your application does not |
| 635 | directly use JavaScript within a <code><a |
| 636 | href="{@docRoot}reference/android/webkit/WebView.html">WebView</a></code>, do |
| 637 | not call setJavaScriptEnabled() and XSS is no longer possible. If you must |
| 638 | enable JavaScript then the WebView section provides other security best |
| 639 | practices.</p> |
| 640 | |
| 641 | <p>If you cannot use the security features above, we strongly recommend the use |
| 642 | of well-structured data formats and verifying that the data conforms to the |
| 643 | expected format. While blacklisting of characters or character-replacement can |
| 644 | be an effective strategy, these techniques are error-prone in practice and |
| 645 | should be avoided when possible.</p> |
| 646 | |
| 647 | <a name="UserData"></a> |
| 648 | <h2>Handling User Data</h2> |
| 649 | |
| 650 | <p>In general, the best approach is to minimize use of APIs that access |
| 651 | sensitive or personal user data. If you have access to data and can avoid |
| 652 | storing or transmitting the information, do not store or transmit the data. |
| 653 | Finally, consider if there is a way that your application logic can be |
| 654 | implemented using a hash or non-reversible form of the data. For example, your |
| 655 | application might use the hash of an an email address as a primary key, to |
| 656 | avoid transmitting or storing the email address. This reduces the chances of |
| 657 | inadvertently exposing data, and it also reduces the chance of attackers |
| 658 | attempting to exploit your application.</p> |
| 659 | |
| 660 | <p>If your application accesses personal information such as passwords or |
| 661 | usernames, keep in mind that some jurisdictions may require you to provide a |
| 662 | privacy policy explaining your use and storage of that data. So following the |
| 663 | security best practice of minimizing access to user data may also simplify |
| 664 | compliance.</p> |
| 665 | |
| 666 | <p>You should also consider whether your application might be inadvertently |
| 667 | exposing personal information to other parties such as third-party components |
| 668 | for advertising or third-party services used by your application. If you don't |
| 669 | know why a component or service requires a personal information, don’t |
| 670 | provide it. In general, reducing the access to personal information by your |
| 671 | application will reduce the potential for problems in this area.</p> |
| 672 | |
| 673 | <p>If access to sensitive data is required, evaluate whether that information |
| 674 | must be transmitted to a server, or whether the operation can be performed on |
| 675 | the client. Consider running any code using sensitive data on the client to |
| 676 | avoid transmitting user data.</p> |
| 677 | |
| 678 | <p>Also, make sure that you do not inadvertently expose user data to other |
| 679 | application on the device through overly permissive IPC, world writable files, |
| 680 | or network sockets. This is a special case of permission redelegation, |
| 681 | discussed in the Requesting Permissions section.</p> |
| 682 | |
| 683 | <p>If a GUID is required, create a large, unique number and store it. Do not |
| 684 | use phone identifiers such as the phone number or IMEI which may be associated |
| 685 | with personal information. This topic is discussed in more detail in the <a |
| 686 | href="http://android-developers.blogspot.com/2011/03/identifying-app-installatio |
| 687 | ns.html">Android Developer Blog</a>.</p> |
| 688 | |
Adrian Ludwig | a15562f | 2011-12-15 15:37:33 -0800 | [diff] [blame] | 689 | <p>Application developers should be careful writing to on-device logs. |
| 690 | In Android, logs are a shared resource, and are available |
| 691 | to an application with the |
| 692 | <a href="{@docRoot}reference/android/Manifest.permission.html#READ_LOGS"> |
| 693 | <code>READ_LOGS</code></a> permission. Even though the phone log data |
| 694 | is temporary and erased on reboot, inappropriate logging of user information |
| 695 | could inadvertently leak user data to other applications.</p> |
| 696 | |
| 697 | |
Adrian Ludwig | 2435940 | 2011-11-07 09:24:23 -0800 | [diff] [blame] | 698 | <h3>Handling Credentials</h3> |
| 699 | |
| 700 | <p>In general, we recommend minimizing the frequency of asking for user |
| 701 | credentials -- to make phishing attacks more conspicuous, and less likely to be |
| 702 | successful. Instead use an authorization token and refresh it.</p> |
| 703 | |
| 704 | <p>Where possible, username and password should not be stored on the device. |
| 705 | Instead, perform initial authentication using the username and password |
| 706 | supplied by the user, and then use a short-lived, service-specific |
| 707 | authorization token.</p> |
| 708 | |
| 709 | <p>Services that will be accessible to multiple applications should be accessed |
| 710 | using <code> |
| 711 | <a href="{@docRoot}reference/android/accounts/AccountManager.html"> |
| 712 | AccountManager</a></code>. If possible, use the <code><a |
| 713 | href="{@docRoot}reference/android/accounts/AccountManager.html"> |
| 714 | AccountManager</a></code> class to invoke a cloud-based service and do not store |
| 715 | passwords on the device.</p> |
| 716 | |
| 717 | <p>After using <code><a |
| 718 | href="{@docRoot}reference/android/accounts/AccountManager.html"> |
| 719 | AccountManager</a></code> to retrieve an Account, check the <code><a |
| 720 | href="{@docRoot}reference/android/accounts/Account.html#CREATOR">CREATOR</a> |
| 721 | </code> before passing in any credentials, so that you do not inadvertently pass |
| 722 | credentials to the wrong application.</p> |
| 723 | |
| 724 | <p>If credentials are to be used only by applications that you create, then you |
| 725 | can verify the application which accesses the <code><a |
| 726 | href="{@docRoot}reference/android/accounts/AccountManager.html"> |
| 727 | AccountManager</a></code> using <code><a href="<code><a |
| 728 | href="{@docRoot}h/reference/android/content/pm/PackageManager.html#checkSignatur |
| 729 | es(java.lang.String,%20java.lang.String)">checkSignature()</a></code>. |
| 730 | Alternatively, if only one application will use the credential, you might use a |
| 731 | <code><a |
| 732 | href={@docRoot}reference/java/security/KeyStore.html">KeyStore</a></code> for |
| 733 | storage.</p> |
| 734 | |
| 735 | <a name="Crypto"></a> |
| 736 | <h2>Using Cryptography</h2> |
| 737 | |
| 738 | <p>In addition to providing data isolation, supporting full-filesystem |
| 739 | encryption, and providing secure communications channels Android provides a |
| 740 | wide array of algorithms for protecting data using cryptography.</p> |
| 741 | |
| 742 | <p>In general, try to use the highest level of pre-existing framework |
| 743 | implementation that can support your use case. If you need to securely |
| 744 | retrieve a file from a known location, a simple HTTPS URI may be adequate and |
| 745 | require no knowledge of cryptography on your part. If you need a secure |
| 746 | tunnel, consider using |
| 747 | <a href="{@docRoot}reference/javax/net/ssl/HttpsURLConnection.html"> |
| 748 | <code>HttpsURLConnection</code></a> or <code><a |
| 749 | href="{@docRoot}reference/javax/net/ssl/SSLSocket.html">SSLSocket</a></code>, |
| 750 | rather than writing your own protocol.</p> |
| 751 | |
| 752 | <p>If you do find yourself needing to implement your own protocol, we strongly |
| 753 | recommend that you not implement your own cryptographic algorithms. Use |
| 754 | existing cryptographic algorithms such as those in the implementation of AES or |
| 755 | RSA provided in the <code><a |
| 756 | href="{@docRoot}reference/javax/crypto/Cipher.html">Cipher</a></code> class.</p> |
| 757 | |
| 758 | <p>Use a secure random number generator ( |
| 759 | <a href="http://developer.android.com/reference/java/security/SecureRandom.html"> |
| 760 | <code>SecureRandom</code></a>) to initialize any cryptographic keys (<a |
| 761 | href="http://developer.android.com/reference/javax/crypto/KeyGenerator.html"> |
| 762 | <code>KeyGenerator</code></a>). Use of a key that is not generated with a secure random |
| 763 | number generator significantly weakens the strength of the algorithm, and may |
| 764 | allow offline attacks.</p> |
| 765 | |
| 766 | <p>If you need to store a key for repeated use, use a mechanism like <code><a |
| 767 | href={@docRoot}reference/java/security/KeyStore.html">KeyStore</a></code> that |
| 768 | provides a mechanism for long term storage and retrieval of cryptographic |
| 769 | keys.</p> |
| 770 | |
| 771 | <h2>Conclusion</h2> |
| 772 | |
| 773 | <p>Android provides developers with the ability to design applications with a |
| 774 | broad range of security requirements. These best practices will help you make |
| 775 | sure that your application takes advantage of the security benefits provided by |
| 776 | the platform.</p> |
| 777 | |
| 778 | <p>You can receive more information on these topics and discuss security best |
| 779 | practices with other developers in the <a |
| 780 | href="http://groups.google.com/group/android-security-discuss">Android Security |
| 781 | Discuss</a> Google Group</p> |