¿Por qué los activadores no se usan a menudo para asegurar una base de datos?

2

Hice un pasante para una empresa que cumplía con las normas de PCI y en lugar de usar desencadenantes para evitar la inyección de SQL, pasé por 1000 (si no más) líneas de código de aplicación web y llamé funciones cada vez que se usaba una entrada de usuario en un SQL consulta. En ese momento escuché hablar sobre el uso de desencadenantes, pero realmente no sabía qué eran.

Hoy en día, en una clase se enseñaron activadores y si cada vez que se llama una declaración SQL sucede algo, ¿no sería mucho más fácil hacer una verificación de activación de activador en lugar de "parametrizar" cada línea de código en la aplicación web? Le pregunté al profesor y él dijo que se necesitaría un sistema de dos cansados para que funcione porque los desencadenantes no funcionan en los querries.

¿Qué quiere decir con que los activadores no funcionan en las consultas y por qué no se utilizan los activadores para proteger las bases de datos de las aplicaciones web?

Las aplicaciones web se escribieron en Cold Fusion y no tenían el cfquery param tags agregados. Tengo curiosidad, ¿por qué el motor Cold Fusion no puede agregarlos automáticamente en el tiempo de ejecución? Quiero decir, nunca hay un momento en el que no se deben usar las etiquetas param de cfquery, ¿no?

    
pregunta Celeritas 08.11.2012 - 03:05
fuente

3 respuestas

4
  

¿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:

  1. 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.
  2. 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.

    
respondido por el trs80 12.11.2012 - 21:39
fuente
7

Creo que se habla de "Procedimientos almacenados". Los disparadores se activan internamente en la base de datos cuando se realizan acciones, pero los procedimientos almacenados son funciones parametrizadas directamente.

  

¿Por qué los activadores (procedimientos almacenados) no se usan a menudo para proteger una base de datos?

A veces la pereza, a veces es demasiado restrictivo. También es el caso que el uso de consultas de SQL parametrizadas en su código también evita los ataques de inyección de SQL. Jeff Atwood escribió un artículo decente sobre intercambios con procedimientos almacenados atrás en 2004.

Dicho esto, incluso con consultas SQL parametrizadas, los procedimientos almacenados aún tienen un lugar en mi mente, especialmente con las contraseñas. No hay una buena razón para que la aplicación consulte el hash de contraseña desde el sistema de base de datos, solo para pedirle al sistema de base de datos que compare un valor de entrada (como un hash generado para mantener la carga fuera del servidor DB) con el hash. Para ese escenario, un procedimiento almacenado definitivamente agrega seguridad y Realmente me pregunto por qué nadie lo usa.

  

¿No sería mucho más fácil realizar una comprobación de activación de inyección

Bueno, consideremos esto: si su activador puede verificar la inyección de SQL, supongo que su código también podría. Entonces usted tiene una lista blanca de valores, o una lista negra para la detección. Blacklists son oportunidades . Incluso entonces, si está haciendo listas blancas, el factor de enumeración podría ser inmenso si no confía en ninguna de las entradas de la consulta, incluida la estructura. Luego volvemos a escribir un procedimiento almacenado para cada operación posible o usar consultas parametrizadas ... y, en general, el segundo método es más sensato.

    
respondido por el Jeff Ferland 08.11.2012 - 03:48
fuente
1

Incluso en los casos en que un desencadenante es apropiado, no hay notificación cuando se desactiva o se desactiva. Por lo tanto, podría pensar que un activador está forzando una clave externa, creando un registro de auditoría o validando la entrada del usuario para frustrar la inyección de SQL ... pero ni siquiera está activo. Este es un gran agujero de seguridad que otros objetos (por ejemplo, procesos almacenados) no tienen.

    
respondido por el Tom 06.12.2012 - 23:31
fuente

Lea otras preguntas en las etiquetas