The APIs that accept selection strings, i.e. a WHERE clause, also
accept and array of strings that you can use for arguments to that
selection. If you're using SQLite you can use a ? for constant values
and pass the WHERE string directly to SQLite. You then pass in the
arguments array, and they are filled in for the ?s post SQL
parsing/compilation and treated as raw data. No need to worry about
escaping, or even quoting at all. For example, if you wanted to look
up student by a name that is coming from an untrusted sourcee you
could do this:
Cursor c = getContentResolver().query(Students.CONTENT_URI,
PROJECTION, Students.NAME + " = ?", new String[] { untrustedName },
null);
As long as the provider supports this feature you don't have to worry
about untrustedName or even escape it.
You can also do something like design your provider to not accept
WHERE clauses at all, and instead use REST style URIs. For example:
Uri uri = Uri.withAppendedPath(Students.CONTENT_SEARCH_URI, untrustedName);
Cursor c = getContentResolver().query(uri, PROJECTION, null, null, null);
and then ensure in the provider that the leaf path node is properly
escaped when used to query whatever data source is backing the
provider.
-Jeff
On Sat, Oct 18, 2008 at 6:53 PM, Mark Murphy <[EMAIL PROTECTED]> wrote:
>
> Anm wrote:
>> If I understand the ContentProvider API correctly, much of the API
>> comes from passing SQL snippets for projects, selection, sort, etc.
>
> The API makes passing values into the SQLiteDatabase API easy. It does
> not mandate the use of SQLite, or even SQL. It does not prohibit you
> from doing your own data validation, including sanitizing your inputs.
>
>> This strikes me as particularly dangerous, as these snippets can
>> easily come from malicious, third party apps. http://xkcd.com/327/
>> comes to mind, but this seems worse, as we're dealing with actual SQL,
>> rather than just string parameters that can be encoded.
>
> If Android itself is not examining the parameters, that merely means
> programming for Android is not significantly different than programming
> for just about any other platform developed by mankind. If you don't
> want "Little Bobby Tables" problems, sanitize your inputs.
>
> If you feel that SQL is the language of Satan, use an object database --
> I seem to recall db4o or somebody was porting theirs to Android. Most
> likely, you can still provide a ContentProvider interface atop it.
>
> If you wish to write a database defense layer that encapsulates the act
> of sanitizing inputs, make it open source, and encourage people to use
> it, you'll be applauded.
>
> There's any number of ways the community can solve this "fundamental
> design flaw". How about we let Google/OHA focus on the things that are
> harder, like, say, video recording?
>
> --
> Mark Murphy (a Commons Guy)
> http://commonsware.com
> _The Busy Coder's Guide to Android Development_ Version 1.3 Published!
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
