Developing Security Mobile Applications for Android Author, Jesse Burns of iSEC Partners

advertisement
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?
Download