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] COMMIT;

Now say the sql contains '; DROP DATABASE; --. The -- part would raise an SQL exception because the option allow_comments is set to false. 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.

  • See also this thread on the PostgreSQL mailing list. At some point they talk about SQL comments. postgresql.org/message-id/481B2047.9090505@fastmail.net – pyb Jun 10 '14 at 16:24
  • 1
    No. If it is already possible to modify the intended SQL command, it’s already SQL injection. Whether comments are removed or not doesn’t matter and change that fact. You can always inject portions that fix up the previous and following statement. Using comments is just a easy way of fixing up the syntax by just ignoring any following code. – Gumbo Jun 11 '14 at 7:55
  • I agree. Implementing such system would only alert of attacks, but not prevent them much. Thanks! – pyb Jun 11 '14 at 17:50
  • Do you want me to make an answer out of that? – Gumbo Jun 12 '14 at 18:28
  • 2
    SQL injection is not a concern of DBMS vendors but of the developers who are building and executing the statements. And vendors of database connection/abstraction layer already handle this topic by providing an interface to either database’s prepared statements or by implementing their own statement parameterization (sometimes also called emulated prepared statements). So why would DBMS vendors bother to implement a feature that doesn’t help preventing SQL injections at all but only slightly mitigate the exploitation? – Gumbo Jun 12 '14 at 19:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.