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 -~----------~----~----~----~------~----~------~--~---
