Am 11.05.2022 um 07:52 schrieb Rainer Deyke via Boost:
On 10.05.22 16:59, Rainer Deyke 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
On 10.05.22 09:14, Richard Hodges via Boost wrote: 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