On Thu, Jan 7, 2010 at 10:02 AM, Brady Eidson <[email protected]> wrote:
> > On Jan 6, 2010, at 2:55 PM, Dumitru Daniliuc wrote: > > while doing a security review of chromium's implementation of HTML5 DBs, > chris noted that some sqlite functions are potential security risks. thus, > we would like to blacklist them (or rather, have a list of whitelisted > functions). currently, WebCore's sqlite authorizer allows all functions, but > has a FIXME comment that wonders what the right thing to do is > (WebCore/storage/DatabaseAuthorizer.cpp:281). > > > This code has long since shipped and although it hasn't achieved what you > might call "wide use," a widespread change in behavior might break important > clients. > > That said... the less function surface area available, the better. > > here are the functions we'd like to whitelist: > http://www.sqlite.org/lang_corefunc.html: all of them, except > load_extension(), random() and randomblob() (once we fix some layout tests > that currently use randomblob()). > > > No argument on disallowing load_extension(). > > Are random() and randomblob() security risks? Could you point us to a > source explaining this? > > http://www.sqlite.org/lang_datefunc.html: all of them > > http://www.sqlite.org/lang_aggfunc.html: all of them > > > Seems okay. > > in addition to these standard functions, we'd like to whitelist some > functions from a few extensions chromium uses: > full text search (fts2.c): whitelist snippet(), offsets(), optimize(), but > not fts2_tokenizer(). > unicode data (icu.c): whitelist regexp(), lower(), upper(), like(), but not > icu_load_collation(). > > > Is there any reason these are still Chromium-only? Even though we're > having problems getting different vendors to agree on SQL dialect issues > with the spec, I think we should make an effort to keep WebKit unified. > > Yes, it would be great if all WebKit based browsers supported these same sqlite features. -Darin > I'm also going to forward this message on to some of our security > colleagues at Apple, and we might have more feedback shortly. > > ~Brady > > > any objection? > > thanks, > dumi > > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
