Actually.. this was the real point of my message:
Anm wrote:
> I'm wondering if
> anything exists in the APIs or automatically behind the scenes to
> sanitize the strings coming into a ContentProvider.
In other words, I recognize there are ways around it. I'm wonder if
solutions already exist so I don't have to write another.
On Oct 18, 6:53 pm, Mark Murphy <[EMAIL PROTECTED]> wrote:
> The API makes passing values into the SQLiteDatabase API easy.
I would argue that this API is falsely easy, luring into developers
into very unsafe practices. Yes it works, but it opens you code up to
a number of potential exploits, most of which are much harder to code
around than you seem to imply.
The problem is that Android will likely becomes several very closely
related distribution, both because of various distributions and
released versions. Each version can have different parse bugs and
semantic interpretations, and any sanitizer would have to re-implement
all those nuances. You'll see these types of problems in web
development and HTML sanitizers also. In reality, only the specific
Android distribution know the precise parse algorithm, and so as much
of the sanitizing should be done there.
On Oct 18, 7:19 pm, "Jeff Hamilton" <[EMAIL PROTECTED]> wrote:
> 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.
Interesting point, but in the case of the ContentProvider methods, the
selection string that places the arguments also comes from the
external request. I guess one easy sanitation filter would involve
whitelisting allowed selection strings, forcing everything else to be
an argument like you demonstrate.
> 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.
I've thought about this, and find it somewhat strange. This freedom/
flexibility of defining the selection method is powerful, but the
requires the client to have special knowledge about the
ContentProvider implementation. Does it prefer URI pathname, URI
argument, or SQL clauses? Can it take any mix of them? Seems counter
to the point of a open and standard API, but its not that critical
since other implementation data seems necessary also (e.g., content
URI, column names).
I know its too late in the game for this, but given the potential
problems, I would have preferred to see the arguments passed in as an
abstract syntax trees of those clauses. Simple methods to generate
the syntax trees from strings (throwing any parse errors in the client-
side code) would allow the client-side code to be nearly as simple.
This should preserve the goals making SQL easy, while still allowing
other implementations to interpret the syntax in a manner appropriate
for their own data-store backing.
Anm
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
