Re: Boost MySQL Review Starts Today

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 
documentation.
   - 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 
connection::query.

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])