¿Por qué no se utilizan los activadores para proteger las bases de datos de las aplicaciones web?
Comience con un ejemplo muy artificial:
Si el código de la página tuviera algo como
query = "SELECT * FROM some_table WHERE this_column='" + user_supplied_value + "';"
Y un atacante introdujo este valor:
user_supplied_value = "';DROP TABLE some_table;'SELECT DATE()"
La consulta enviada a la base de datos es
query = "SELECT * FROM some_table WHERE this_column=''; DROP TABLE some_table; 'SELECT DATE()';"
Una función de activación tendría que analizar y rechazar de forma segura esta cadena:
"';DROP TABLE some_table;'SELECT DATE()"
Pero. Por lo general, un activador está vinculado a una operación de inserción, actualización o eliminación. El SQL anterior que contiene la cadena de ataque tiene tres consultas, ninguna de las cuales realiza una inserción, actualización o eliminación. Por lo tanto, el disparador nunca se activará, la validación nunca se producirá y "some_table" desaparecerá.
Pero digamos que hubo un INSERT con un disparador que se dispara antes de que se confirme el INSERT. Ahora depende de usted hacer la validación que los desarrolladores de motores ya hicieron para el código del controlador. Hay mucho espacio para el error, muy poco beneficio, y realmente no tiene sentido, ya que las consultas parametrizadas hacen todo esto de forma automática y mucho más segura.
El uso de consultas parametrizadas garantiza que el SQL se vea algo así antes de enviarlo al motor de la base de datos:
query = "SELECT * FROM some_table WHERE this_column='\'\; DROP TABLE some_table\;\'SELECT DATE()';"
Utiliza desencadenantes para autorización, auditoría, control de versiones, cumplimiento de restricciones comerciales, pero no para validación de entrada.
¿Qué significa que los desencadenantes no funcionan en las consultas
Eso depende de lo que quiere decir con "trabajo", pero generalmente es porque lo que describí anteriormente:
- Un disparador no actúa sobre la consulta en sí. Se dispara una vez que el
el analizador determina qué operación está intentando realizar la consulta.
Así que no importa lo que haga el activador, la consulta maliciosa está en el
sistema y potencialmente podría ser ejecutado.
- En el ejemplo anterior,
ningún gatillo dispararía jamás. Así que un disparador no "funciona" si estás
tratar con consultas "SELECT".
¿no sería eso mucho más fácil hacer una comprobación de activación de la inyección?
¿En lugar de "parametrizar" cada línea de código en la aplicación web?
No, es mucho, mucho más difícil.
Hacer la validación después de enviar la consulta significa que el código malicioso se convertirá en su motor de base de datos. Sus funciones de validación tienen que ser perfectas. Cada función en su base de datos tiene que usar esas funciones de validación antes de ejecutar una consulta. Tienes dos niveles de perfección para cumplir. Si no, ese código malicioso podría ser ejecutado.
Los programadores de aplicaciones web también tendrían que realizar un seguimiento de todas las operaciones de concatenación de cadenas que se utilizan para desarrollar las consultas, y para cadenas más largas podría causar problemas.
Las consultas parametrizadas, por otro lado, aseguran que la entrada se desinfecte antes de que llegue a su motor de base de datos. Por lo tanto, sus funciones personalizadas y cualquier función incorporada estarán a salvo de la explotación.
Quiero decir, nunca hay un momento en el que uno no deba usar cfquery param
etiquetas, ¿verdad?
Uno podría salirse con la suya si la consulta que se está ejecutando no toma ninguna entrada. Sin embargo, en general, si está trabajando con entradas en cualquier parte de la aplicación, para mantener la coherencia, todas las llamadas a su base de datos deberían utilizar el mecanismo más seguro disponible, que es la función de parametrización proporcionada por la biblioteca de controladores o el marco de la aplicación.