6 ms·
AFAIK, one database per application would not protect other databases from a SQL injection exploit. The "ATTACH DATABASE" command (http://www.sqlite.org/lang_a
by mkching 13y ago
AFAIK, one database per application would not protect other databases from a SQL injection exploit.
The "ATTACH DATABASE" command (http://www.sqlite.org/lang_attach.html http://www.sqlite.org/lang_attach.html) can open any other database that the current user has permissions to.
You could, as you mentioned, set up a new user for each database. At a certain point, the permissions systems in a traditional RDBMS may be easier to manage.
- nraynaud 13y agoThe stuff that would get rid of the SQL injection, is the database API, removing the general purpose query(string) function. And forcing some structure on the parameters. First a little breaking to get the easy injections out, and progressively forcing the whole host language mapping of the query, including the result schema. People will scream about the debugging, but they will gain a little bit of stuff in exchange (like projection in a variable, where clause re-use etc).