Android Security : ContentProviders

10/11/2010 2:04:43 PM
Android has the ContentProvider mechanism to allow applications to share raw data. This can be implemented to share SQL data, images, sounds, or whatever you like; the interface is obviously designed to be used with a SQL backend, and one is even provided. ContentProviders are implemented by applications to expose their data to the rest of the system. The <provider> tag in the application’s AndroidManifest.xml file registers a provider as available and defines permissions for accessing it.

The Android security documentation mentions that there can be separate read and write permissions for reading and writing on a provider. It states that “holding only the write permission does not mean you can read from a provider” (Google, 2008).

People familiar with SQL will probably realize that it isn’t generally possible to have write-only SQL queries. For example, an updateQuery() or deleteQuery() call results in the generation of a SQL statement in which a where clauses is provided by the caller. This is true even if the caller has only write permission. Controlling a where clause doesn’t directly return data, but the ability to change a statement’s behavior based on the stored data value effectively reveals it. Through watching the side effects of a series of calls with clever where clauses, callers can slowly reconstruct whatever data is stored. As an example of this, attackers exploiting “blind” SQL injection flaws use this technique of repeated queries on for flaws that don’t directly expose query results in order to reconstruct the database of vulnerable systems. You could certainly create a provider for which this is not the case, especially if the provider is file or memory based, but it isn’t likely that this will just work for simple SQL-based providers. Keep this in mind before designing a system that relies on write-only provider access.

Declare the read and write permissions you wish enforced by the system directly in AndroidMainfext.xml’s <provider> tag. These tags are android:readPermission and android:writePermission. These permissions are enforced at access time, subject to the limitations of the implementations discussed earlier. A general permission tag needed for any access can also be required.


Assume clients with write access to a content provider also have read access. Describe any write permission you create as granting read-write access to SQL-based providers. Consider creating permissions like ACCESS_RESOURCE rather than separate READ_RESOURCE and WRITE_ RESOURCE permissions when dealing with SQL-based providers.

Implementing a provider that is shared with other applications involves accepting some risks. For example, will those other applications properly synchronize their accesses of the data and send the right notifications on changes? ContentProviders are very powerful, but you don’t always need all that power. Consider simpler ways of coordinating data access where convenient.

An advanced feature providers may use is dynamic granting and revoking of access to other programs. The programs granted access are identified by their package name, which is the name they registered with the system on install (in their <manifest> tags, android:package attribute). Packages are granted temporary access to a particular Uniform Resource Identifier (URI). Generally, granting this kind of access doesn’t seem like a great idea, though, because the granting isn’t directly validated by the user and there may not be correct restrictions on the query strings the caller can use. Also, I haven’t worked with this option enough to give advice about using it securely. It can be used by marking your provider tag with the attribute android:grantUriPermissions=“true” and a subsequent <grant-uri-permission> with attributes specifying which URIs are permitted. (You can find the rather weak documentation for this at Providers may then use the grantUriPermission() and revokeUriPermission() methods to give add and remove permissions dynamically. The right can also be granted with special Intent flags: FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION. Code that does this kind of thing would be a great place to start looking for security holes, although the open source Android code did not use this feature as of version 1.5.

Top 20
Android Security Tools
Network Programming with Windows Sockets : A Socket Message Receive Function
Customizing Windows 7’s Desktop (part 2) - Getting Around the Start Menu
Upload a File with FTP
Windows Server 2008: Improvements for Thin Client Remote Desktop Services
Programming Microsoft SQL Server 2005: Using the Data Mining Wizard and Data Mining Designer (part 2) - Creating a Mining Model
Get File Security Description
Working with Basic and Dynamic Disks
Controlling Access to Files and Folders with NTFS Permissions
Optimizing for Vertical Search : Optimizing for Local Search (part 1) - Check Your Local Listings
Debugging Tools For Parallel Tasks
Troubleshooting Common Disk Problems
Upgrading to SQL Server 2008
Customizing Windows 7’s Desktop (part 1) - Getting Around the Desktop
Mobile Application Security : The Apple iPhone - Permissions and User Controls
Hacking - Advanced Camouflage
Mobile Application Security: Application Format
Algorithms for Compiler Design: RIGHT LINEAR AND LEFT LINEAR GRAMMAR
The SQL Programming Language : Creating Tables and Entering Data
Building Android Apps : Controlling the Phone with JavaScript (part 1) - Beep, Vibrate, and Alert