On Tue, 10 May 2022 at 17:00, Rainer Deyke via Boost
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.
Hi Rainer, The library exposes the MySQL client/server protocol primitives as they are. There are two of these protocol primitives: text queries (implemented by connection::query) and prepared statements (implemented by connection::prepare_statement and the prepared_statement class). When using SQL queries with parameters, there are two options: you may compose a SQL query client-side and then execute it with connection::query, or prepare a statement and leave the server do the heavy-lifting. We could offer a SQL query composition function in this library, like: string compose_sql_query(string_view query_template, const ValueCollection& parameters); So you could then pass the result of compose_sql_query to connection::query. However, I think it's more secure (and efficient) to just rely on prepared statements. This section in the docs covers this topic: https://anarthal.github.io/mysql/mysql/prepared_statements.html To sum up, I'd use connection::query for queries known at compile-time (e.g. "START TRANSACTION"), and prepared statements for anything with parameters. Please let me know if there is any use case I may be missing. Regards, Ruben.
-- Rainer Deyke (rainerd@eldwood.com)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost