Comment by justinclift

The exploit mentioned above relies on third party functions being loaded into the database. eg application specific functions

Those functions have to be explicitly loaded by the application after loading the database. eg: They're not stored in the database and loaded with it.

You'd validate the database (past the standard integrity checking), by loading it and not adding any third party functions. Then check it's not doing anything dodgy with views, or outright disable views. Then load the third-party extensions (if needed).

If you wanted to go even further, you could also add an authorizer callback function:

https://www.sqlite.org/c3ref/set_authorizer.html

That's called (multiple times) any time a SQL statement is prepared/executed, and catches things like functions being run, tables being accessed, etc. You can use that to only allow a whitelisted set of functions to run, which would help in some scenarios. eg:

https://github.com/sqlitebrowser/dbhub.io/blob/e1c5042f857e9...

The "Defense Against Dark Arts" page on the SQLite website has further good info about this:

https://www.sqlite.org/security.html

As a data point, I implemented the above "Defense against Dark Arts" stuff recently for an online SQLite data publishing platform to let people run free form queries on databases (dbhub.io). It wasn't all that hard to implement. Much less so that I'd been expecting. :)