Seguridad 101: inyección SQL


Un ataque cuidadosamente diseñado puede convencer a una base de datos para que revele todos sus secretos. Comprender los conceptos básicos de cómo se ve el ataque y cómo protegerse contra él puede contribuir en gran medida a limitar la amenaza.

Muchas aplicaciones empresariales orientadas a la internet tienen bases de datos detrás de ellas. Para muchos de ellos, la aplicación en sí misma es poco más que una interfaz de usuario elegante ubicada en la parte exceptional de una base de datos. Y en 2020, es casi seguro que la base de datos habla lenguaje de consulta estructurado o SQL. Esa es una gran noticia para los desarrolladores que necesitan la máxima flexibilidad en la creación de aplicaciones. También es bastante bueno para los delincuentes que quieren convencer a la base de datos de que entregue mucha más información de la que cualquier usuario debería ver.

La inyección SQL es una técnica de pirateo que existe desde al menos 1998. Aprovecha dos factores para el éxito: en primer lugar, las aplicaciones internet a menudo solicitan datos a los usuarios y segundo, esas aplicaciones tienden a tomar los datos proporcionados por el usuario y pasarlos a la base de datos como parte de una instrucción. Combínelos sin barandas de protección basadas en códigos, y existe la posibilidad de que un felony ejecute la aplicación lejos de la maleza.

Estructura de una consulta.

En un fragmento de aplicación común, se le puede pedir a un usuario su nombre de usuario para ver la información que la empresa tiene en su cuenta. Cuando escriben su nombre de usuario en la aplicación y presionan «Enter», el código resultante podría verse así:

instrucción = «SELECCIONAR * DESDE usuarios DONDE nombre = &#39» + nombre de usuario + «&#39»

Esto le dice a la foundation de datos que seleccione todo («*») en una foundation de datos llamada «usuarios» en la que hay un registro con un nombre de usuario que coincide con lo que el usuario acaba de escribir. Hasta ahora, todo bien.

Pero si el usuario escribe un nombre de usuario que se ve así:

&#39OR&#39 1 &#39=&#39 1

Luego, el código que se genera le indicará a la base de datos que devuelva toda la información para cada registro en la foundation de datos, porque «1 = 1» es verdadero sin importar qué registro se esté examinando.

El ataque puede ser aún más complejo porque la mayoría de las bases de datos aceptan los llamados comandos SQL «en lote», en los que se pueden ingresar múltiples comandos a la vez y separarlos con un punto y coma. En tal caso, un atacante puede ordenar a la base de datos de la víctima que haga un gran trabajo para seleccionar y organizar los datos de tal manera que sea más útil para el pirata informático (y tal vez un poco menos notable para el equipo de seguridad de la víctima).

Todo esto es posible porque la programación de aplicaciones world wide web más básica toma información del usuario y simplemente la coloca dentro de una cadena de consulta de foundation de datos preconstruida antes de pasarla a la base de datos. Entonces, ¿qué debe hacer una empresa si prefiere no dar toda su foundation de datos a cualquiera que pregunte?

Estructura de una defensa

La defensa contra la inyección SQL puede ocurrir en dos puntos separados en el desarrollo de la aplicación y el proceso de ejecución: el primero es durante el desarrollo del código, el segundo en el momento de la ejecución.

Defender contra la inyección de SQL durante el desarrollo significa escribir código que no permita que los comandos pasen a la foundation de datos como parte de las consultas de la aplicación. Parte de esto podría ser la validación de entrada: si está pidiendo un nombre, no permita números o caracteres especiales, por ejemplo.

Parte de la protección basada en el desarrollo podría ser el reconocimiento de código, en el que cualquier cosa que sea código SQL (o un fragmento de código SQL) se reconoce y elimina de la consulta antes de pasarla a la base de datos. En un caso perfect, ambas técnicas se utilizarán para garantizar que no se pueda crear una consulta que no proporcione los resultados previstos por el diseñador de la aplicación.

La protección en la ejecución generalmente significa implementar un firewall de aplicación net (WAF) o un producto related que escanea la entrada en busca de consultas y comandos ilícitos, y luego escanea la salida en busca de resultados que van más allá del contenido previsto. Al igual que con los sistemas de filtrado de correo electrónico, el personalized de seguridad deberá configurar el WAF de una manera que no interfiera con los usos legítimos, pero la entrada legítima rechazada ocasional puede ser un precio que los administradores están dispuestos a pagar por una mayor seguridad.

Al igual que las secuencias de comandos entre sitios, la inyección SQL ha existido por más tiempo que la mayoría de los profesionales que intentan defenderse de ella. Sigue siendo un peligro porque es muy rápido crear código de aplicación website que no bloquee el ataque, y es muy económico simplemente no comprar un firewall que proteja contra la técnica. Sin embargo, los beneficios de costo de no actuar se pueden eliminar en un solo incidente de ataque exitoso. La verdadera pregunta es cuántos datos está dispuesta a arriesgar una empresa.

Contenido relacionado:

Aprenda de los expertos de la industria en un entorno propicio para la interacción y la conversación sobre cómo prepararse para eso «realmente mal día «en ciberseguridad. Haga clic para más información y para registrarse.

Curtis Franklin Jr. es editor sénior en Darkish Reading. En este puesto, se centra en la cobertura de productos y tecnología para la publicación. Además, trabaja en programación de audio y movie para Dark Examining y contribuye a actividades en Interop ITX, Black Hat, INsecurity y … Ver biografía completa

Lectura recomendada:

Más ideas





Enlace a la noticia initial