Cómo prevenir ataques de inyección SQL
1. Ejemplo sencillo de ataque de inyección SQL.
statement:= "SELECT * FROM Users WHERE Value= " a_variable "
La declaración anterior es una declaración SQL muy común. Su función principal es permitir al usuario ingresar un El número de empleado se usa para consultar la información del empleado. Sin embargo, si un atacante sin escrúpulos modifica esta declaración, puede convertirse en una mano negra para destruir datos. Por ejemplo, cuando un atacante ingresa una variable, ingrese el siguiente contenido SA001'; drop table c_order--. Luego, cuando se ejecuta la instrucción SQL anterior, se convierte en SELECT * FROM Users WHERE Value= 'SA001'; drop table c_order--. ' El punto y coma indica el final de una consulta y el comienzo de otra declaración. El guión doble después de c_order indica que el resto de la línea actual es solo un comentario y debe ignorarse. Si el código modificado es sintácticamente correcto, el servidor se ejecutará. el código Al procesar esta declaración, la declaración de consulta se ejecutará primero para encontrar la información del usuario con el número de usuario SA001. Luego, los datos se eliminarán de la tabla C_ORDER (si no hay otras claves principales y otras restricciones relacionadas, se eliminarán). La operación será exitosa siempre que se inyecte). Si el código SQL es sintácticamente correcto, la manipulación no se puede detectar mediante programación. Por lo tanto, se deben verificar todas las entradas del usuario y se debe verificar el código que ejecuta los comandos SQL construidos en el servidor que está utilizando. debe comprobarse cuidadosamente.
2. Principio de los ataques de inyección SQL
Se puede ver que los ataques de inyección SQL son muy dañinos antes de explicar cómo prevenirlos. Los administradores deben comprender los principios de los ataques. Esto ayudará a los administradores a tomar medidas específicas de prevención y control.
La inyección SQL es un método de ataque común contra las bases de datos. en la cadena y luego utilice varios medios para pasar la cadena a la instancia de la base de datos SQLServer para su análisis y ejecución. Siempre que el código malicioso cumpla con las reglas de la declaración SQL, el sistema no lo descubrirá cuando el código. se compila y ejecuta
Hay dos formas principales de ataques de inyección SQL. Una es insertar código directamente en las variables de entrada del usuario que están concatenadas con comandos SQL y hacer que se ejecuten. utiliza este método de agrupación de declaraciones SQL, por lo que también se denomina método de ataque de inyección directa. El segundo es un método de ataque indirecto, que inyecta código malicioso en la cadena que se almacenará en la tabla o como datos originales. Comando SQL dinámico para ejecutar código SQL malicioso.
El proceso de inyección funciona terminando la cadena de texto antes de tiempo y luego agregando un nuevo comando. Tomemos como ejemplo los ataques de inyección directa. Es decir, cuando el usuario ingresa una variable, primero finaliza la declaración actual con un punto y coma. Luego inserte una declaración SQL maliciosa. Dado que el comando insertado puede agregar otras cadenas antes de su ejecución, los atacantes suelen terminar la cadena inyectada con una marca de comentario "-". Al ejecutar, el sistema considerará las siguientes declaraciones como comentarios, por lo que el texto posterior se ignorará y no se compilará ni ejecutará.
3. Prevención y tratamiento de ataques de inyección SQL.
Dado que los ataques de inyección SQL son tan dañinos, ¿cómo prevenirlos? Las siguientes sugerencias pueden ser útiles para los administradores de bases de datos a la hora de prevenir los ataques de inyección SQL.
1. Los permisos de los usuarios normales y de los usuarios administradores del sistema deben distinguirse estrictamente.
Si un usuario normal incorpora otra declaración Drop Table en una declaración de consulta, ¿se permite su ejecución? Dado que la declaración Drop está relacionada con los objetos básicos de la base de datos, el usuario debe tener los permisos pertinentes para operar. esta declaración. En el diseño de permisos, para los usuarios finales, es decir, los usuarios de software de aplicación, no es necesario otorgarles permisos para crear y eliminar objetos de base de datos. Entonces, incluso si hay código malicioso incrustado en las declaraciones SQL que utilizan, estos códigos no se ejecutarán debido a restricciones en sus permisos de usuario. Por lo tanto, al diseñar una aplicación, es mejor distinguir a los usuarios administradores del sistema de los usuarios normales. Esto puede minimizar el daño causado por ataques de inyección a la base de datos.
2. Forzar el uso de sentencias parametrizadas.
Si al escribir una declaración SQL, las variables ingresadas por el usuario no están directamente incrustadas en la declaración SQL. Si pasa esta variable a través de parámetros, puede prevenir eficazmente ataques de inyección SQL. En otras palabras, la entrada del usuario no debe incorporarse directamente en declaraciones SQL. Por el contrario, la entrada del usuario debe filtrarse o deben usarse declaraciones parametrizadas para pasar variables de entrada del usuario. Las declaraciones parametrizadas utilizan parámetros en lugar de incorporar variables de entrada del usuario en la declaración SQL. Con esta medida, se pueden eliminar la mayoría de los ataques de inyección SQL. Desafortunadamente, no hay muchos motores de bases de datos que admitan declaraciones parametrizadas. Sin embargo, los ingenieros de bases de datos deberían intentar utilizar declaraciones parametrizadas al desarrollar productos.
3. Fortalecer la verificación de las aportaciones de los usuarios.
En general, se pueden utilizar dos métodos para prevenir ataques de inyección SQL. Uno es fortalecer la inspección y verificación del contenido de entrada del usuario; el otro es forzar el uso de declaraciones parametrizadas para pasar el contenido de entrada del usuario. En la base de datos SQLServer, existen muchas herramientas de verificación del contenido ingresado por el usuario que pueden ayudar a los administradores a lidiar con los ataques de inyección SQL. Pruebe el contenido de una variable de cadena y acepte solo el valor requerido. Rechace entradas que contengan datos binarios, secuencias de escape y caracteres de comentarios. Esto ayuda a prevenir la inyección de scripts y previene ciertos ataques de desbordamiento del búfer. Pruebe la entrada del usuario para determinar el tamaño y el tipo de datos, aplicando límites y conversiones adecuados. Esto ayuda a prevenir desbordamientos intencionales del búfer y tiene un efecto significativo en la prevención de ataques de inyección.
Por ejemplo, puede utilizar procedimientos almacenados para verificar la entrada del usuario. Puede utilizar procedimientos almacenados para filtrar las variables de entrada del usuario, como rechazar algunos símbolos especiales. Por ejemplo, en el código malicioso anterior, siempre que el procedimiento almacenado filtre el punto y coma, el código malicioso será inútil. Antes de ejecutar la declaración SQL, puede utilizar el procedimiento almacenado de la base de datos para rechazar algunos símbolos especiales. Sin afectar la aplicación de la base de datos, se debe permitir que la base de datos rechace entradas que contengan los siguientes caracteres. Como por ejemplo el delimitador de punto y coma, que es el principal cómplice de los ataques de inyección SQL. Como separador de comentarios. Las anotaciones sólo se utilizan durante el diseño de datos. Generalmente, no hay contenido de comentario necesario en la declaración de consulta del usuario, por lo que puede ser rechazado directamente. En circunstancias normales, esto no causará pérdidas inesperadas. Si se rechazan estos símbolos especiales, incluso si hay código malicioso incrustado en la declaración SQL, no harán nada.
Por lo tanto, siempre verifique la entrada del usuario y filtre la entrada del usuario probando el tipo, la longitud, el formato y el rango. Esta es una medida común y eficaz para prevenir ataques de inyección SQL.
4. Hacer más uso de los parámetros de seguridad que vienen con la base de datos SQL Server.
Para reducir los efectos adversos de los ataques de inyección en la base de datos de SQL Server, se diseñan especialmente parámetros SQL relativamente seguros en la base de datos de SQL Server. Durante el proceso de diseño de la base de datos, los ingenieros deben intentar utilizar estos parámetros para evitar ataques maliciosos de inyección SQL.
Por ejemplo, la colección Parameters se proporciona en la base de datos de SQL Server. Esta colección proporciona capacidades de verificación de tipos y validación de longitud.
Si el administrador utiliza la colección de parámetros, la entrada del usuario se tratará como valores de caracteres en lugar de código ejecutable. Incluso si el contenido ingresado por el usuario contiene código ejecutable, la base de datos lo filtrará. Porque en este momento la base de datos solo lo trata como un carácter normal. Otra ventaja de utilizar la colección de parámetros es que se pueden aplicar comprobaciones de tipo y longitud, y los valores fuera del rango desencadenarán una excepción. Si el valor ingresado por el usuario no cumple con las restricciones de tipo y longitud especificadas, se producirá una excepción y se informará al administrador. Por ejemplo, en el caso anterior, si el tipo de datos definido por el número de empleado es tipo cadena, la longitud es de 10 caracteres. Aunque el contenido ingresado por el usuario también son datos de tipo carácter, su longitud alcanza los 20 caracteres. Se generará una excepción en este momento porque la longitud de la entrada del usuario excede el límite de longitud del campo de la base de datos.
5. ¿Cómo prevenir ataques de inyección SQL en entornos de múltiples niveles?
En entornos de aplicaciones de múltiples niveles, todos los datos ingresados por los usuarios deben verificarse antes de que se les permita ingresar al sitio de confianza. área de la red. Los datos que no pasan el proceso de validación deben ser rechazados por la base de datos y un mensaje de error devuelto al siguiente nivel. Implementar verificación multicapa. Las precauciones tomadas contra usuarios malintencionados sin propósito pueden no ser efectivas contra atacantes determinados. Un mejor enfoque es validar la entrada en la interfaz de usuario y en todos los puntos posteriores a través de los límites de confianza. Por ejemplo, validar datos en la aplicación cliente puede evitar la inyección de scripts simples. Sin embargo, si la siguiente capa cree que su entrada ha sido validada, cualquier usuario malintencionado que pueda eludir al cliente puede tener acceso ilimitado al sistema. Por lo tanto, para entornos de aplicaciones de múltiples capas, al prevenir ataques de inyección, todas las capas deben trabajar juntas y se deben tomar las medidas correspondientes en el lado del cliente y de la base de datos para evitar ataques de inyección de declaraciones SQL.
6. Si es necesario, utilice herramientas profesionales de escaneo de vulnerabilidades para encontrar posibles puntos de ataque.
El uso de herramientas profesionales de escaneo de vulnerabilidades puede ayudar a los administradores a encontrar posibles puntos de ataques de inyección SQL. Sin embargo, las herramientas de escaneo de vulnerabilidades solo pueden descubrir puntos de ataque y no pueden defenderse activamente contra los ataques de inyección SQL. Por supuesto, los atacantes suelen utilizar esta herramienta. Por ejemplo, los atacantes pueden utilizar esta herramienta para buscar automáticamente objetivos de ataque y llevar a cabo ataques. Por este motivo, si es necesario, las empresas deberían invertir en algunas herramientas profesionales de escaneo de vulnerabilidades. Un escáner de vulnerabilidades completo se diferencia de un escáner de red en que busca específicamente vulnerabilidades de inyección SQL en la base de datos. Los últimos escáneres de vulnerabilidades buscan las últimas vulnerabilidades descubiertas. Por lo tanto, las herramientas profesionales pueden ayudar a los administradores a descubrir vulnerabilidades de inyección SQL y recordarles que tomen medidas activas para prevenir ataques de inyección SQL. Si el administrador de la base de datos descubre las vulnerabilidades de inyección SQL que el atacante puede encontrar y toma medidas activas para bloquear las vulnerabilidades, entonces el atacante no tendrá forma de comenzar.