I recently made sure that Glom is not vulnerable to common SQL injections, which can risk destroying your data or providing unintended access to data. I’m mentioning it here so people can tell me if it’s not good enough. Be kind.

For the regular Glom desktop UI, it’s probably not a big issue, because only a small number of users have access anyway. But I believe in doing things properly and this certainly is an issue for Online Glom (more about that soon).

It turned out that things were mostly safe already, thanks to our use of GdaSqlBuilder instead of raw string concatenation. We still build a few special queries manually, to change database structure or permissions, and those would never be used by Online Glom, but I fixed (1, 2, 3, 4) them anyway. As a bonus, this avoids problems with special characters. Vivien Malerba, who is always incredibly helpful and responsive, fixed some related issues (1, 2, 3, 4, 5) in libgda.

I added some SQL injection tests to make sure. I would welcome ideas (or patches) to test extra vulnerabilities. Like all of Glom’s tests that use an actual database, this tests libglom with both PostgreSQL and SQLite, though SQLite isn’t used by the regular Glom build.

Likewise, I made sure (1, 2) that we use g_shell_quote() when building shell commands, for instance to invoke (spawn) postgres or tar. Of course, I would rather not do that anyway. And I made sure that we properly escape values in our database connection strings.