Esta pregunta podría cambiarse de nombre "¿Prohibiría los comentarios de SQL dentro de las transacciones evitaría algunas inyecciones de SQL?", pero me gustaría saber si algunos DBMS permiten esto primero.
El objetivo es reducir la superficie de ataque de las aplicaciones heredadas. Entiendo que todas las entradas de los usuarios deben ser desinfectadas antes de ser utilizadas en una declaración SQL. La cosa es que a veces no puedes.
Aquí es cómo me gustaría ejecutar (No) consultas SQL:
BEGIN TRANSACTION WITH OPTIONS allow_comments=false;
[non sanitized sql statement]
COMMIT;
Ahora digamos que el sql contiene '; DROP DATABASE; -- .
La parte -- generaría una excepción de SQL porque la opción allow_comments se establece en false .
Debido a que esta declaración se envolvió en una transacción, nunca se confirmaría y la parte DROP DATABASE; nunca se ejecutaría.
También podríamos configurar un disparador para alertarnos sobre el intento de inyección. Debería funcionar con Hibernate ORM que no envía comentarios SQL de forma predeterminada.
Quizás el activador también podría transformar la declaración inicial con algo que la aplicación pueda manejar (SELECCIONAR sin resultado, etc.), de modo que la aplicación podría actuar como si la entrada hubiera sido saneada.
Me doy cuenta de que no es a prueba de balas ya que algunas inyecciones de SQL no usan comentarios. Eso es algo que podemos mitigar una vez que recibamos la alerta de la base de datos (ban usuario, IP ...).
Me temo que no es algo que los desarrolladores de bases de datos implementen, porque daría una falsa sensación de seguridad. Creo que si ayuda a prevenir incluso una pequeña fracción de las inyecciones, eso es algo que todos podrían usar.
¿Qué piensas?
DBMS: Oracle, MySQL, MS SQL, PostgreSQL ... Como las inyecciones de bases de datos también son posibles en las bases de datos NoSQL, también tengo curiosidad por estas.
Casos de uso: sistemas heredados cuyo código fuente es intocable o perdido.