Boost logo

Boost :

From: Daniela Engert (dani_at_[hidden])
Date: 2022-05-11 06:26:25


Am 11.05.2022 um 07:52 schrieb Rainer Deyke via Boost:
> 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:
>   - 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.

Instead of going *that* nuclear, there are better options now with
compile-time string inspections. Instead of accepting a 'string_view'
(or heavens forbid, 'string') as query string, do the same as the
standard library (or {fmt}) does (please see P2216r3, C++23 and DR to
C++20, and the {fmt} API documentation):

 Â  * accept e.g. a boost::query_string object with a consteval-only
constructor from a 'string_view' to enable compile-time inspection,
similar to (not-yet-)std::/fmt::basic_format_string
 Â  * and optionally, as a second overload, accept e.g. a
boost::runtime_query_string which wraps a 'string_view' for queries
which are not known at compile time, similar to fmt::runtime

With that in place, you can do magic as I know from my own explorations
of that design space.

Ciao
 Â  Dani


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk