Preventing SQL injection without prepared statements/SQLite/C++

Question

I'd appreciate some feedback on how secure this scheme is against SQL injection attacks.

At the front end, the user enters personal information: name, address, phone numbers, email, and some freeform text.

The back-end is coded from scratch in C++, with no framework support, and integrates SQLite.

The C++ code does not use SQLite prepared statements (for historical reasons, and it's too late to do anything about it). Instead, all SQL statements are constructed as printf-style format strings, along these lines:

#define STATEMENT_N "UPDATE members SET FirstName='%s', Surname='%s', DOB='%s', etc"

The actual statements are created with a hand-coded sprintf (sqlPrintf) statement which handles only %s, %c, and %d conversions. The final statement is then created something like:

sqlPrintf(query_buffer, STATEMENT_N, user_str_1, user_str_2, etc)

So, in other words (if you're not familiar with C/sprintf), the user input is 'printed' into the %s, %c, and %d. The only non-obvious processing in sqlPrintf is that user-supplied single-quote characters are escaped (they're doubled up).

Is this sufficient to prevent SQL injection attacks? And is a 'prepared statement' actually anything more than the above scheme?

Answer 1

Basically, the only thing you need to worry about here is the single quotes. Anything contained within single quotes in your query will be fine, but a lone single quote can end the string, allowing the rest of the data entry to run as code. If sqlPrintf doubles up single quotes, you should be fine. And reading the comments on your question, it sounds like this system works against the "';--" attack. :)

Answer 2

Doubling single quotes is sufficient to prevent injection problems with strings. There are no other special characters recognized inside strings.
(Please note that SQLite already has helper functions for this.)

If you ever need to handle blobs, you'd have to use parameters anyway. But that is a different question …