Thanks Christoph!
Just to be clear, this patch doesn't prevent security issues if you
don't update your SQLite3 library, it just implements a new option
available in newer SQLite versions which will prevent arbitrary changes
to the internals of a SQLite database only if you SQLite3 library is
3.26+. Changing the internals of a SQLite database is something that
should be quite rare in the real world I think.
This addresses potential security issues for PHP applications allowing
end-users to run arbitrary SQL queries.
But please note that if your application does allow end-users to run
arbitrary SQL queries, I advise that you limit them to read-only by
either:
- opening the database as readonly (available in PDO since PHP 7.3: use
open attribute: PDO::SQLITE_ATTR_OPEN_FLAGS => PDO::SQLITE_READONLY)
- using the SQLite3Stmt::readOnly method (will tell you if a prepared
statement will write to the database)
- or using the equivalent for PDO:
$st = $pdo->prepare('SELECT * FROM table;');
var_dump($st->getAttribute(PDO::SQLITE_ATTR_READONLY_STATEMENT));
This last one should be available in PHP 7.4 I hope? See
https://github.com/php/php-src/pull/2760
Both PDO features are currently undocumented but it's on my TODO list as
well.
If your users are performing custom SELECT queries, this is the best
thing to do.
I am now working on bringing support for a userland custom callback to
the SQLite3 authorizer API, this will allow PHP code to restrict access
to specific tables, columns and operations, that should also improve
security in the future.
As a side note, although my time is quite limited, I have worked for the
last two years to improve features support and security of the SQLite3
extension and try to match features of the SQLite3 extension in PDO as
well.
I have to give a warm thank you to Christoph and everyone else who
helped me in this :)
And if anyone is interested in helping me improve SQLite support in PHP
you are more than welcome :)
Cheers.