4 ms·
Are custom FTS3 tokenizers disabled by default on current SQLite versions? The documentation does not mention it (and also doesn't warn of the security concern
by indigo945 6y ago
Are custom FTS3 tokenizers disabled by default on current SQLite versions? The documentation does not mention it (and also doesn't warn of the security concern around enabling them). Otherwise, I do not see how the attack vector discussed in the video could be "fixed". The security guideline recommends disabling triggers and views, which is also a logical remedy, but seems brittle, nevermind also impractical for a wide range of applications.
The documentation on the fts3_tokenizer function merely states that
Prior to SQLite version 3.11.0 (2016-02-15), the
arguments to fts3_tokenzer() could be
literal strings or BLOBs. They did not have to be bound
parameters. But that could lead to security
problems in the event of an SQL injection. Hence, the
legacy behavior is now disabled by default.
However, it does not discuss any mitigations for the case where SQL injections are not needed, because the attacker controls the database file.
- SQLite 6y agoSee https://www.sqlite.org/fts3.html#custom_application_defined_tokenizers https://www.sqlite.org/fts3.html#custom_application_defined_... Since 2016, arguments to the fts3_tokenizer() function must be variables (ex: ? or :var or @var or $var) to which values are supplied by the application at run-time using sqlite3_bind_pointer(). There is no way to do this from pure SQL script. Nor is there any way to do this from within a view or trigger. There is no way to invoke fts3_tokenizer() from a maliciously corrupted schema or database.