1. Developing Security Mobile Applications for Android Presenter, Joel Elixson Author, Jesse Burns of iSEC Partners

2. Approach Discuss the appropriate contextual use for particular Android Components and security-specific features Discuss other guidelines, dos-and-don’ts, what have you

3. 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)

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. Questions Have any?