> I don't believe that this would move the needle on SQL-injection
safety by enough to be worth doing. An injection attack is normally
trying to break out of a quoted string, not a comment.
Yes, SQL injections frequently involve escaping quoted strings, but if you do a
search for SQL injection examples, you will find that most of them (I would say
90% or more) also use comments to remove the remainder of the SQL statement
from consideration. Here is one example where an attacker specifies "admin'--;"
as the username:
SELECT * FROM members WHERE username = 'admin'--;' AND password = 'password';
The comment in this example removes the password from inclusion in the
statement, allowing the attacker to login as admin without a password.
If 90% of injection attacks make use of comments (together with quoted string
escapes), it seems to me that a connection configuration option to disable
comments would "move the needle" substantially.
With comments disabled, attackers would have to craft their attacks to account
for the SQL following the escaped string. While significantly more difficult,
it's not impossible, but would likely involve adding a semi-colon to terminate
the statement with the attack and follow it with additional SQL to render the
remainder of the original statement into a benign second statement. And this is
why I've also suggested being able to configure a connection to disallow
multiple statements.
Together, being able to disable comments and restrict executions to single
statements would make it significantly more difficult for attackers to conduct
injection attacks on APIs that use a connection configured this way.
-Glen
________________________________
From: Tom Lane <t...@sss.pgh.pa.us>
Sent: Wednesday, June 4, 2025 4:05:56 p.m.
To: Glen K <glenk1...@hotmail.com>
Cc: pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
Subject: Re: Feature request: Settings to disable comments and multiple
statements in a connection
Glen K <glenk1...@hotmail.com> writes:
> My feature requests are thus:
> Provide a client connection option (and/or implement the backend support) to
> disallow comments in SQL statements
I don't believe that this would move the needle on SQL-injection
safety by enough to be worth doing. An injection attack is normally
trying to break out of a quoted string, not a comment.
> Provide a client connection option (and/or implement the backend support) to
> allow only one statement in an execute request
This exists already; you just have to use the extended query protocol.
> Provide an option in the client execute functions (and/or implement
> the backend support) to specify the expected number of statements.
I don't see the need for this given #2.
regards, tom lane
