Feature request: Settings to disable comments and multiple statements in a connection

[Glen K]

Given that most SQL 
injections
 involve use of comments and/or insertion of semi-colons to start a new 
statement, it seems to me that injection attacks could be substantially reduced 
if client connections could be configured to disallow comments in SQL and to 
only allow one statement to be executed per request. In my experience 
developing backends for APIs, I have never come across a case where comments 
were needed or desired within SQL statements generated for API requests, and 
I'm not aware of any use cases where it was essential to send two statements in 
the same execute request (but perhaps there are).

My feature requests are thus:

  *
Provide a client connection option (and/or implement the backend support) to 
disallow comments in SQL statements
  *
Provide a client connection option (and/or implement the backend support) to 
allow only one statement in an execute request
  *
Provide an option in the client execute functions (and/or implement the backend 
support) to specify the expected number of statements. This would override the 
client connection option and would inhibit attackers from injecting additional 
statements

Such features would not be an alternative to using parameterized queries, 
sanitized user input or any other injection mitigation measures, but would 
provide another layer of security on top of those measures.

-Glen

Re: Feature request: Settings to disable comments and multiple statements in a connection

[Glen K]

> 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 
Sent: Wednesday, June 4, 2025 4:05:56 p.m.
To: Glen K 
Cc: pgsql-general@lists.postgresql.org 
Subject: Re: Feature request: Settings to disable comments and multiple 
statements in a connection

Glen K  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