This question could be renamed "Would forbidding SQL comments inside transactions prevent some SQL injections?", but I'd like to know if some DBMS allow this first.
The goal is to reduce the attack surface of legacy applications. I understand that all user input should be sanitized before being used in an SQL statement. The thing is, sometimes you can't.
Here is how I would like to run (No)SQL queries:
BEGIN TRANSACTION WITH OPTIONS allow_comments=false;
[non sanitized sql statement]
Now say the sql contains
'; DROP DATABASE; --.
-- part would raise an SQL exception because the option
allow_comments is set to
Because this statement was wrapped in a transaction, it would never commit and the
DROP DATABASE; part would never be executed.
We could also setup a trigger to alert us of the injection attempt. It should work with Hibernate ORM which does not send SQL comments by default.
Maybe the trigger could also transform the initial statement with something that the application can handle (SELECT with no result, etc.), so the application could act as if the input had been sanitized.
I realize it's not bulletproof as some SQL injections don't use comments. That's something we can mitigate once we receive the alert from the database (ban user, IP...).
I'm afraid it's not something database developers would implement, because it would bring a false sense of security. I think if it helps to prevent even a small fraction of injections, that's something everybody could use.
What do you think?
DBMS: Oracle, MySQL, MS SQL, PostgreSQL... As database injections are also possible on NoSQL databases, I'm curious about these too.
Use cases: legacy systems whose source code is untouchable or lost.