120 likes | 261 Views
Developing Security Mobile Applications for Android. Author, Jesse Burns of iSEC Partners. Presenter, Joel Elixson. Approach. Discuss the appropriate contextual use for particular Android Components and security-specific features Discuss other guidelines, dos-and-don’ts, what have you.
E N D
Developing Security Mobile Applications for Android Author, Jesse Burns of iSEC Partners Presenter, Joel Elixson
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?