INYECCIÓN SQL:
Hecho por: Nicolás Rafael Chelaru Tanase
Índice:
1. Introducción
2. Definición
3. Historia
4. Tipos:
4.1. Inyección clásica
4.2. Inyección a ciegas.
4.3 Inyección basada en errores:
4.4 Inyección basada en Unión.
4.5 Inyección basada en tiempo.
4.6 Inyección SQL vía Cookies.
5. Formas de evitar ataques.
6. Casos de la vida real.
7 Bibliografía.
1.Introducción:
Desde la creación de la idea del modelo relacional de gestión de bases de datos en
1970 en el laboratorio de IBM y su después creación del lenguaje de programación
SQL (Structured Query Language) el mundo a ido evolucionando en un mundo
donde las bases datos son un parte de nuestras vidas (o más bien nuestras vidas
están en las bases de datos). Como todas las cosas en la vida cuando sea crea algo
nuevo y no es posible encontrar los fallos que puede ocasionar y evitarlo. Al igual
que nosotros los ingenieros de IBM intentando crear un lenguaje sencillo fácil de
entender y de usar , dieron lugar a causar uno de los errores que desgraciadamente
sigue ocurriendo muy típicamente en cualquier auditoría en este caso la inyección
SQL.
La inyección SQL es una de las vulnerabilidades más comunes y peligrosas en
aplicaciones web, explotada frecuentemente por atacantes para comprometer la
seguridad de los sistemas. Este tipo de ataque ocurre cuando un atacante introduce
código SQL malicioso en los campos de entrada de un formulario web, el cual es
procesado de forma incorrecta por la aplicación y enviado a la base de datos como
si fuera parte de una consulta legítima. Esto permite al atacante manipular las
consultas SQL originales para obtener acceso no autorizado a los datos, modificar
información, ejecutar comandos arbitrarios o incluso tomar el control total del
sistema de bases de datos.
Las consecuencias de una inyección SQL pueden dar a lugar a importantes
consecuencias para la base de datos. Entre los riesgos más serios se incluyen el
robo de datos confidenciales, como credenciales de usuario, información financiera
o propiedad intelectual; la alteración o eliminación de datos críticos; y, en casos
extremos, el colapso completo de la infraestructura de datos. Para prevenir la
inyección SQL, es crucial implementar medidas de seguridad como la
parametrización de consultas, que asegura que las entradas sean tratadas como
datos y no como comandos ejecutables. Además, es muy importante hacer una
validación estricta de las entradas, empleando restricciones para aceptar solo los
datos esperados. Existen herramientas de desarrollo web suelen incluir
mecanismos con el fin poder solucionarlo y poder evitar problemas que den lugar a
dicha técnica . Complementar estas medidas con auditorías regulares de seguridad
y el uso de herramientas de detección de vulnerabilidades puede hacer que los
sitios web sean a priori más seguros frente a estos ataques.
2.Definición:
Se entiende como inyección SQL como aquella vulnerabilidad que permite a un
atacante interferir con las consultas que un sitio web realiza su base de datos. Como
consecuencia puede conllevar a la habilitación del acceso no autorizado a datos, lo
cual amenaza directamente a al filosofía ACID (Atomicidad, Consistencias,
Aislamiento y Durabilidad) de la bases de datos y los SGBD (Sistemas de Gestión
de bases de datos). Pese al nombre de esta vulnerabilidad las intrusiones de este
no solo ocurre con bases de datos escritas en SQL sino que se puede dar en
cualquier lenguaje de programación.
3.Historia:
La primera persona que se conoce y se pronunció acerca de esta vulnerabilidad fue Rain
Forest Puppy cuyo nombre real es Jeff Forristal. El es un investigador de seguridad cuyo
objetivo es encontrar vulnerabilidades en dispositivos móviles.
Encontró durante un auditoría NT, un servicio web que interactuaba con una base de datos
MySQL Server 6.5 y revisando la posibilidad del motor SQL y fué entonces cuando se
percató de que era posible ejecutar sentencias. Entonces comenzó a encadenar sentencias
SQL para provocar la ejecución de consultas para que una vez que la aplicación
concatenarse dicha consulta pudiera conseguir información la cuál no debería de poseer.
Esto lo hizo público con todo lujo de detalles en el número 54 de la revista PHRACK el 25
de Diciembre de 1998
Como recomendación dejo que se asumiera que los valores introducidos por el usuario son
siempre adecuados en sentencias SQL. Esta recomendación actualmente sigue causando
problemas por tenerla en cuenta.
4. Tipos:
4.1: Inyección SQL Clásica:
Se proporciona retroalimentación directa por parte de la base de datos, lo que ayuda a los
atacantes a explotar la vulnerabilidad más rápido.
4.2: Inyección SQL a Ciegas:
Este tipo de ataque de inyección SQL se basa en preguntas a la base de datos a través del
panel de inserción de usuario y contraseña preguntas ciertas o falsas y determina la
respuesta basada en las aplicaciones respuesta. Se evidencia cuando en una página web,
por un fallo de seguridad, no se muestran mensajes de error al no producirse resultados
correctos ante una consulta a la base de datos, mostrándose siempre el mismo contenido.
Ejemplos de sentencias que provocan este tipo de inyección SQL son “Or 1=1” o “having
1=1” las cuales ofrecen respuestas siempre correctas esto da a lugar que esta técnica se
utiliza en combinación con diccionarios o fuerza bruta para la búsqueda haciendo que el
código utilizado consiga un resultado positivo acumulable como puede ser una contraseña
un nombre o un número de teléfono.
4.3 Inyección basada en errores:
Un atacante fuerza a la base de datos a generar un error que revela detalles sobre el
esquema de la base de datos. Aprovechan los mensajes de error de la base de datos para
revelar información sensible. Los atacantes que están detrás de estos ataques envían
intencionalmente consultas SQL malformadas, haciendo que la base de datos genere
mensajes de error que contienen información valiosa. Estos mensajes son analizados por el
atacante y puede llegar a conocer el funcionamiento interno de la base de datos.
4.4 Inyección basada en Unión:
Las consultas de unión permiten a los atacantes combinar los resultados de dos consultas
diferentes. Se utiliza el operador SQL Union para combinar los resultados de la consulta
original con los resultados de consultas maliciosas inyectadas. Esto permite al atacante
recuperar información de otras tablas de la base de datos.
4.5 Inyección basada en tiempo.
El atacante puede explotar retrasos de tiempo para inferir el éxito de sus consultas. Es decir
que basándose en el tiempo se puede determinar una vulnerabilidad en un aplicación web.
El atacante utiliza una función predefinida basada en el tiempo del sistema de gestión de
bases de datos que utiliza la aplicación.
Si una consulta de este tipo produc e un retraso , el atacante sabría que es vulnerable. Este
enfoque es similar al anterior ya que no obtienes una respuesta real de la base de datos.
SIn embargo, puedes obtener información de ella si el ataque tiene éxito.
4.6 Inyección SQL vía cookies.
Los atacantes también pueden explotar mecanismos de almacenamiento de datos
inseguros como cookies y almacenamiento local , estos mecanismos a menudo son
utilizados por aplicaciones web para almacenar información relacionada con la sesión o
preferencias de usuario, pero si los datos almacenados se utilizan de manera insegura en
consultas SQL, puede llevar a vulnerabilidades de inyección.
Ejemplo:
Suponiendo que se tiene una aplicación web que almacena el ID de usuario en una cookie y
se usa el ID para recuperar datos. Este puede ser un ejemplo en el lenguaje de
programación FLASK.
El atacante podría manipular la cookie user_id para inyectar una consulta SQL.
5. Forma de evitar los ataques .
Según el INCIBE (Instituto Nacional de Ciberseguridad) existen varios mecanismos para
poder paliar estos tipos de ataques.
- Escapar los comandos: Es decir evitar que en el formulario se pueda añadir y
procesar ciertos caracteres o códigos específicos de la sintaxis del lenguaje SQl o el
lenguaje que se este utilizando.
- Verificar los datos : Comprobar que los datos que solicitan los usuarios concuerdan
con lo esperado. Es decir si un usuario a través de una consulta solicita una
dirección de correo, la verificación debe comprobar que el tipo de dato que se le va a
proporcionar es el esperado por una dirrección de correo y no otro tipo de dato.
- Evitar la exposición: En ocasiones el problema causante es dejar accesible las
bases de datos de carácter interno esto hace que los ciberdelincuentes puedan
acceder a información crítica. Se deja como recomendación dejar las bases de datos
aisladas de la red interna.
- Uso de herramientas de análisis: Existen herramientas que permiten comprobar la
seguridad de los formularios que tenemos en la página web, de tal modo que
facilitan encontrar posibles fallos de seguridad para poder subsanarlos.
6. Casos en la vida real:
En 2012 un informático egipcion dio a conocer algunas vulnerabilidades críticas que
detectó en Yahoo. Según declaró dicha persona tuvo acceso total a los archivos de copia
de respaldo de uno de los servidores de dominio de Yahoo, esto lo consiguió a traves de la
explotación de una vulnerabilidad de inyección SQL en uno de los dominios de la compa
ñía. Este caso se sumó a otro caso en la misma empresa pero en esta ocasión el servicio
era Yahoo Voices donde pudieron acceder a 45000 credenciales y algunos datos del
servidor comprometido.
Otro ataque más actual es el caso de el ataque a través de inyección SQL del periódico El
Confidencial en Abril de 2024 el cual admitió que habían sufrido ataques de una magnitud
sin precedentes en los 23 años de vida. Los atacantes trataron de acceder ilegalmente al
gestor de contenidos del medio, que es la herramienta que usan los periodistas para escribir
y publicar sus noticias y distribuirlas en la portada del diario.
Bibliografía:
[Link]
oria
[Link]
ritica-segun-owasp
[Link]
[Link]
[Link]
[Link]
ql
[Link]
[Link]
Ataques a [Link]., SQL Injection José María Alonso Cebrián,Antonio Guzmán
Sacristán,Pedro Laguna Durán y Allejandro Martín Bailón
[Link]
