Developing Security Mobile Applications for Android

Presenter, Joel Elixson

Author, Jesse Burns of iSEC Partners

Approach

• Discuss the appropriate contextual use for particular Android Components and security-specific features

• Discuss other guidelines, dos-and-don’ts, what have you

Permissions

• Create new permissions sparingly• Make new permissions easily understood

– e.g., SEND_LOCATION_MESSAGE obviously sends a GPS location using SMS

• Use cleverness as an alternative whenever possible– e.g., Confirm any data changes with the user (UI)

Intent Filters• Intent Filters can be bypassed via

Intent.setComponent()

• They don’t make any guarantees about the message itself

• Bad data can easily sneak through; always check and sanitize Intent data

• Intent Filters are device-public; if you’re certain your Activity/Service doesn’t need to be exposed, consider calling it directly

Intents

• Don’t put sensitive information into an Intent that starts an Activity

• It’s susceptible to interception techniques that “squat” using the same IntentFilter (but with a higher priority) as the intended target

Broadcast Receivers (BRs)

• Prefer broadcasting for inter-process communication

• Receiving and sending broadcasts implements an easy-to-use, permissions-checking scheme to ensure a broadcast or BR is trusted

• Again, the message a BR receives could still be malicious (in the case of an unwary and too-eager user installing apps all willy-nilly), so data should still be screened in the BR

Broadcast Receivers: Exception

• Sticky broadcasts can’t require a BR have permission to receive it

• Obviously, don’t use a sticky broadcast for sensitive information

Services and Binders

• Validate your Service connections before use• Can check the Service’s package name or explicitly

call the exact Service your want (not ideal)• Check the permissions of anyone accessing your

application through a Binder interface – no exceptions

Pending Intents

• Prefer Pending Intents as the better message format in inter-process communication

• Pending Intents address the issue of “Intent Reflection,” which is the act of tricking another Component (Binder or Service, usually) into sending (successfully) an Intent they wouldn’t normally be able to send

• Pending Intent is always sent as the process that created it

Content Providers and SQL

• Content Providers might not be appropriate for all occasions (even when made private)

• Sanitize SQL to avoid SQL-Injection attacks; SQLiteQueryBuilder does some of this for you

File System

• Generally, it isn’t a good idea to make shared preferences or local files world-writable (a malicious writer could fill up your device memory)

• When using mass storage, understand that data written to it is world-readable

Questions

• Have any?