1 / 12

Developing Security Mobile Applications for Android

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.

dante
Télécharger la présentation

Developing Security Mobile Applications for Android

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  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?

More Related