ADVERTENCIA:
La información proporcionada es solo para fines educativos y no para uso malicioso.
Antes de profundizar en lo que realmente es SQL Injection, déjame explicarte qué es SQL en sí mismo.
¿Qué es SQL?
El lenguaje de consulta estructurado (SQL) es un lenguaje de programación especializado para enviar consultas a bases de datos. Se puede acceder a la mayoría de las aplicaciones de bases de datos pequeñas y de potencia industrial mediante sentencias SQL. SQL es un estándar ANSI e ISO. Sin embargo, muchos productos de bases de datos que admiten SQL lo hacen con extensiones propietarias del lenguaje estándar. Las aplicaciones web pueden usar entradas proporcionadas por el usuario para crear declaraciones SQL personalizadas para solicitudes de páginas web dinámicas.
¿Qué es la inyección SQL?
La inyección SQL es una técnica que explota una vulnerabilidad de seguridad que ocurre en la capa de base de datos de una aplicación web. La vulnerabilidad está presente cuando la entrada del usuario se filtra incorrectamente para caracteres de escape literales de cadena incrustados en declaraciones SQL o la entrada del usuario no está fuertemente tipada y, por lo tanto, se ejecuta inesperadamente. De hecho, es una instancia de una clase más general de vulnerabilidades que pueden ocurrir cada vez que un lenguaje de programación o secuencias de comandos está integrado dentro de otro.
«Inyección SQL» es un subconjunto de la vulnerabilidad de entrada de usuario no verificada/no desinfectada («desbordamientos de búfer» son un subconjunto diferente), y la idea es convencer a la aplicación para que ejecute código SQL que no estaba previsto. Si la aplicación crea ingenuamente cadenas SQL sobre la marcha y luego las ejecuta, es sencillo crear algunas sorpresas reales.
Los servidores web de muchas organizaciones se han visto comprometidos solo por las inyecciones de SQL, incluidos los grandes nombres que no me gustaría mencionar aquí, puede buscarlos fácilmente en Internet.
¿Qué es la inyección ciega de SQL?
Este tipo particular de ataque se denomina ataque de inyección SQL ciega, porque el atacante no puede aprovechar los mensajes de error detallados del servidor u otras fuentes de información sobre la aplicación. Obtener la sintaxis de SQL correcta suele ser la parte más complicada del proceso de inyección de SQL a ciegas y puede requerir mucho ensayo y error. Pero, al agregar más condiciones a la instrucción SQL y evaluar la salida de la aplicación web, un atacante eventualmente determinará si la aplicación es vulnerable a la inyección SQL.
La inyección ciega de SQL es un caso especial que juega con la sensación de seguridad de los desarrolladores web o propietarios de sitios web. Si bien pueden pensar que todo en el servidor está estrictamente protegido, un ataque de inyección ciega de SQL jugará silenciosamente con la verdad o las consecuencias con el servidor web. Este tipo de ataque, aunque consume mucho tiempo, es uno de los que proporciona el agujero de seguridad más potencialmente dañino. Esto se debe a que un atacante no solo obtiene acceso, sino que recibe una enorme cantidad de conocimiento sobre la base de datos y puede potencialmente obtener acceso al sistema de archivos de un servidor. Este tipo de ataque es uno que está automatizado y requiere una buena cantidad de configuración para tener éxito. Pero una vez hecho, no requiere mucho esfuerzo para repetir.
¿Qué es el mensaje de error de inyección SQL?
Las aplicaciones web suelen utilizar consultas SQL con entrada proporcionada por el cliente en la cláusula WHERE para recuperar datos de una base de datos. Cuando una aplicación web ejecuta dichas consultas sin validar o escanear los datos proporcionados por el usuario para asegurarse de que no sean dañinos, puede ocurrir un ataque de inyección SQL. Al enviar datos inesperados, un atacante puede generar y enviar consultas SQL a una base de datos de aplicaciones web. Se realiza una prueba de vulnerabilidades de inyección SQL mediante el envío de datos de la aplicación que genera una consulta SQL no válida. Si el servidor devuelve un mensaje de error, esa información se puede utilizar para intentar obtener acceso no controlado a la base de datos. Esta es la base de uno de los ataques de inyección SQL más populares.
Ocultar mensajes de error no detiene el ataque de inyección SQL. Lo que suele suceder es que el atacante utilizará el conocimiento obtenido del fracaso de este ataque para cambiar de táctica. A lo que recurren es a la inyección ciega de SQL.
¿Por qué inyección SQL?
Cuando una aplicación web no desinfecta adecuadamente la entrada proporcionada por el usuario, es posible que un atacante altere la construcción de las declaraciones SQL de back-end. Cuando un atacante puede modificar una declaración SQL, el proceso se ejecutará con los mismos permisos que el componente que ejecutó el comando. (Por ejemplo, servidor de base de datos, servidor de aplicaciones web, servidor web, etc.). El impacto de este ataque puede permitir a los atacantes obtener el control total de la base de datos o incluso ejecutar comandos en el sistema.
Cuando una máquina solo tiene abierto el puerto 80, su escáner de vulnerabilidades más confiable no puede devolver nada útil, y sabe que el administrador siempre parchea su servidor, este es el punto en el que un pirata informático malicioso recurriría a la piratería web. La inyección de SQL es uno de los tipos de piratería web que solo requiere el puerto 80 y podría funcionar incluso si el administrador está feliz con el parche. Ataca a la aplicación web (como ASP, JSP, PHP, CGI, etc.) en sí misma en lugar del servidor web o los servicios que se ejecutan en el sistema operativo.
Tipos de inyecciones de SQL:
Hay cuatro categorías principales de ataques de inyección SQL contra la capa de bases de datos en la aplicación web
1. Manipulación de SQL: la manipulación es el proceso de modificar las declaraciones de SQL mediante el uso de varias operaciones como UNION. Otra forma de implementar la inyección de SQL utilizando el método de manipulación de SQL es cambiando la cláusula where de la declaración de SQL para obtener resultados diferentes.
2. Inyección de código: la inyección de código es el proceso de insertar nuevas sentencias SQL o comandos de base de datos en la sentencia SQL vulnerable. Uno de los ataques de inyección de código es agregar un comando EXECUTE de SQL Server a la declaración SQL vulnerable. Este tipo de ataque solo es posible cuando se admiten varias declaraciones SQL por solicitud de base de datos.
3. Inyección de llamadas a funciones: La inyección de llamadas a funciones es un proceso de inserción de varias llamadas a funciones de bases de datos en una declaración SQL vulnerable. Estas llamadas a funciones podrían estar realizando llamadas al sistema operativo o manipulando datos en la base de datos.
4. Desbordamientos de búfer: el desbordamiento de búfer es causado por el uso de la inyección de llamada de función. Para la mayoría de las bases de datos comerciales y de código abierto, hay parches disponibles. Este tipo de ataque es posible cuando el servidor no está parcheado.
Técnicas de prevención de inyección SQL:
La mitigación de la vulnerabilidad de inyección SQL sería tomar uno de los dos caminos, es decir, usar procedimientos almacenados junto con declaraciones invocables o usar declaraciones preparadas con comandos SQL dinámicos. Cualquiera que sea la forma que se adopte, la validación de datos es obligatoria.
una. Validación de entrada
La desinfección de datos es clave. La mejor manera de desinfectar los datos es usar la expresión regular de denegación predeterminada. Escribe filtros específicos. En la medida de lo posible utilice cifras, números y letras. Si es necesario incluir signos de puntuación de cualquier tipo, conviértalos codificándolos en HTML. SO que » se convierta en «»» o > se convierta en «>». Por ejemplo, si el usuario está enviando la dirección de correo electrónico, solo permita @, -, . Y _ además de los números y letras que se utilizarán y solo después de que se hayan convertido a sus sustitutos HTML
b. Uso de la declaración preparada
Las declaraciones preparadas deben usarse cuando los procedimientos almacenados no pueden usarse por cualquier motivo y deben usarse comandos SQL dinámicos.
Use una declaración preparada para enviar declaraciones SQL precompiladas con uno o más parámetros. Los marcadores de posición de parámetros en una declaración preparada están representados por el? Y se llaman variables de enlace. Las declaraciones preparadas generalmente son inmunes a los ataques de inyección SQL, ya que la base de datos usará el valor de la variable de enlace exclusivamente y no interpretará el contenido de la variable de ninguna manera. PL/SQL y JDBC permiten declaraciones preparadas. Las declaraciones preparadas deben usarse ampliamente por razones de seguridad y rendimiento.
C. Usar privilegios mínimos
Asegúrese de que el usuario de la aplicación tenga derechos mínimos específicos en el servidor de la base de datos. Si el usuario de la aplicación en la base de datos usa ROOT/SA/dbadmin/dbo en la base de datos, entonces; seguramente debe reconsiderarse si el usuario de la aplicación realmente necesita una cantidad tan alta de privilegios o si se pueden reducir. No le dé permiso al usuario de la aplicación para acceder a los procedimientos almacenados del sistema, permita el acceso a los creados por el usuario.
d. Procedimientos almacenados
Para proteger una aplicación contra la inyección SQL, los desarrolladores nunca deben permitir que los datos proporcionados por el cliente modifiquen la sintaxis de las declaraciones SQL. De hecho, la mejor protección es aislar la aplicación web de SQL por completo. Todas las declaraciones SQL requeridas por la aplicación deben estar en procedimientos almacenados y mantenerse en el servidor de la base de datos. La aplicación debe ejecutar los procedimientos almacenados mediante una interfaz segura, como declaraciones Callable de JDBC o CommandObject de ADO.
Y muchos más ….
web
Viajes Universitarios by Viajes Fin de Curso
Transformación digital by Inteligencia de Negocios
#Fortalecimiento #aplicación #web #contra #inyecciones #SQL
Comentarios recientes