Boost logo

Boost :

From: Rainer Deyke (rdeyke_at_[hidden])
Date: 2022-05-11 05:52:01

On 10.05.22 16:59, Rainer Deyke via Boost wrote:
> On 10.05.22 09:14, Richard Hodges via Boost wrote:
>> The Boost formal review of the MySQL library starts Today, taking place
>> from May 10th, 2022 to May 19th, 2022 (inclusive) - We are starting
>> one day
>> after the announced date and extending the period by one day to
>> compensate.
> I took a quick look, and my first impression is that the library doesn't
> do enough to prevent SQL injection attacks.  Yes, text queries are
> convenient when the full query is known at compile-time.  Yes, security
> is ultimately the responsibility of those who use the API.  Yes, this is
> C++, where far worse security flaws are a constant threat.  Even so,
> connection::query gives me shivers.

So, I've been thinking about what the library can do to prevent SQL
injection attacks. Ideas:
   - connection::query can be renamed to connection::unsafe_query.
   - A big red warning about SQL injection attacks can be added to the
   - Syntax sugar for a one-off parametrized query wouldn't hurt either.
   - As a nuclear option, the query string can be changed into a
template argument to prevent its use with strings that aren't known at
compile-time. Unfortunately this would also prevent some valid uses of

If I were to design an API, I might use a combination of the above:

   // Allowed:
   con.query("SELECT * FROM employee WHERE company_id = ?", "HGS");
   con.query<"SELECT * FROM employee WHERE company_id = 'HGS'">();
   con.unsafe_query("SELECT * FROM employee WHERE company_id = 'HGS'");

   // Error: literals in runtime-supplied query string not allowed.
   con.query("SELECT * FROM employee WHERE company_id = 'HGS'");

But I'm just throwing out ideas random here.

Rainer Deyke (rainerd_at_[hidden])

Boost list run by bdawes at, gregod at, cpdaniel at, john at