The proposal to use sqlite database files instead of zip files falls under the precondition that an attacker can submit a maliciously crafted database file. So the security concerns apply.

SQLitte is mostly used in situations where neither the database nor the SQL statements can be provided by the attacker. If SQLite is used to exchange data both of these attack vectors are available.

> If you look at the actual list of CVEs, all but one start with ‘Malicious SQL statement’. The single one that doesn't is suffixed with ‘The bug never appeared in any official SQLite release’.

The list on the page is partial, and the language on that page is disturbingly dismissive. Reading leaves me more concerned that they're too arrogant to take security researchers seriously.

I'm sure they aren't perfect, but their test suite and extensive fuzz testing is far better than any XML or JSON parser I've ever seen

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

I do not agree about JSON. As a format it is so trivial one can cover it with few test cases. SQL dialect that SQLite uses is vastly more complex.

You'd think so, but in practice no two JSON parsers have the same bugs, so it's more complex than you might think:

http://seriot.ch/json/parsing.html#all_results

Think about it if even JSON which is kinda simple has that many problems with parsers how likely is it that something multiple degrees of complexity higher which wasn't developed with untrusted database fiels in mind is secure?

Besides that the large majority of thinks tested in your link are irrelevant for the security in this use-case. They do matter if you need fully stable de- and re-serialization or e.g. have a fully trusted validator. E.g. for certain security token use-cases it matters. Many of the thinks which are marked as failure could even be considered as a "more robust" or "more secure" (through not fully standard conform) parser. E.g. parsing tailing commas (disallowed by JSON), rejecting certain unescaped control/special characters (which JSON allows), rejecting to long field values (which JSON allows) or similar. What matters is that a) it has a protection about to deep recursion and as such no stack overflow can happen, b) it makes sure the text it outputs is correctly encoded (independent of weather or not it was well-formed in the JSON blob) and c) it doesn't crash in a way which leads to security problems (which the test suite you linked doesn't differentiate from "acceptable" crashes).

As long as one uses a single parser to read a particular input it matters little if it produces a result that is different from what some other parser generates as long as the parser has no security bugs. And JSON is simple enough to cover a particular interpretation of its spec with test suits to make a security vulnerability extremely unlikely.

Surely if one uses one parser to verify the payload and another to use it, a disaster comes as was with IPhone verification bug.

I seem to remember really great interaction with lcamtuf (of AFL fame): https://lcamtuf.blogspot.com/2015/04/finding-bugs-in-sqlite-...

I feel like there should be a way to make a maliciously crafted database file execute arbitrary SQL... SQLite doesn't do stored procedures, but there's gotta be something in that surface area.

> SQLite doesn't do stored procedures

Link: https://www.sqlite.org/gencol.html

Example:

CREATE TABLE t1(

   a INTEGER PRIMARY KEY,

   b INT,

   c TEXT,

   d INT GENERATED ALWAYS AS (a*abs(b)) VIRTUAL,

   e TEXT GENERATED ALWAYS AS (substr(c,b,b+1)) STORED

);

Note how you can call functions in the columns. Thats one feature which a hardened sqlite for less trusted documents would need to not have.

I expect the majority of the vulnerabilities were in the command parser. Which attack vector is gone from the database file.

AFAIK, SQLite stores database schema as text, so certain subset of parser still has to be invoked on untrusted DDL.

if select is all you need then a view would suffice