Inyecciones SQL (2/4). Login Bypass; Explicación y PoC
En esta serie de 4 partes, estaré explicando los diferentes tipos de Inyecciones SQL que hay de una forma muy básica a nivel principiante, en la cual iremos aumentando la dificultad capitulo a capitulo.
Y hoy explicaremos a nivel principiante como hacjer el Bypass de un Login con inyecciones SQL
Pero, antes que nada. ¿Qué es una inyección SQL?
Una inyección SQL consiste en la inserción de código SQL por medio de los datos de entrada desde la parte del cliente hacia la aplicación. Es decir, por medio de la inserción de este código el atacante puede modificar las consultar originales que debe realizar la aplicación y ejecutar otras totalmente distintas con la intención de acceder a la herramienta, obtener información de alguna de las tablas o borrar los datos almacenados, entre otras muchas cosas.
Como consecuencias de estos ataques y dependiendo de los privilegios que tenga el usuario de la base de datos bajo el que se ejecutan las consultas, se podría acceder no sólo a las tablas relacionadas con la aplicación, sino también a otras tablas pertenecientes a otras bases de datos alojadas en ese mismo servidor.
Lo comentado anteriormente es posible gracias a que el uso de ciertos caracteres en los campos de entrada de información por parte del usuario, ya sea mediante el uso de los campos de los formularios que son enviados al servidor mediante POST o bien por medio de los datos enviados mediante GET en las urls de las páginas web, posibilitan coordinar varias consultas SQL o ignorar el resto de la consulta, permitiendo ejecutar la consulta que elija, de ahí que sea necesario realizar un filtrado de esos datos enviados para evitar problemas.
Así lo explique en un articulo anterior sobre Inyecciones SQL, con mayor detalle teórico.
Aunque muchas aplicaciones requieren autenticación para acceder a información confidencial o para realizar ciertas acciones, no todos los métodos de autenticación ofrecen un nivel de seguridad adecuado. En algunos casos, la falta de atención, el desconocimiento o la subestimación de las amenazas pueden dar lugar a sistemas de autenticación que son fácilmente vulnerables. Por ejemplo, un atacante podría eludir el proceso de inicio de sesión y acceder directamente a páginas internas que deberían estar protegidas y ser accesibles solo después de una autenticación correcta.
Además, es frecuente que las medidas de autenticación puedan ser eludidas manipulando las solicitudes y engañando a la aplicación para que crea que el usuario ya ha iniciado sesión. Esto se puede hacer de varias maneras: cambiando los parámetros en la URL, modificando el contenido del formulario de inicio de sesión, o falsificando las cookies de sesión que la aplicación utiliza para identificar al usuario.
En resumen, un atacante puede explotar estas debilidades para obtener acceso a la aplicación como si fuera un usuario legítimo, sin necesidad de conocer las credenciales reales del usuario. La seguridad de la autenticación debe ser robusta para prevenir estos ataques, y es fundamental implementar medidas de seguridad adecuadas para proteger las aplicaciones de tales vulnerabilidades.
A veces, el servidor nos proporciona información útil en el mensaje de error. Lo cual nos otroga una gran pista, otras ves nos da el nombre de usuario en el mensaje de error, y podemos averiguar si el usuario existe o no, contraseñas. bases, etc… .
SELECT user FROM users WHERE username='admin'--' AND password='admin'
Al hacer esto, estamos tratando de manipular la consulta SQL del servidor para obtener información adicional sobre cómo se manejan las entradas. Si la aplicación es vulnerable a la inyección SQL, deberíamos poder obtener algún tipo de error.
Como vemos tenemos nos muetraun error, lo cual nos detalla que es vulnerable..
Sabemos que las comillas en la consulta SQL, en el backend del sitio web, están desequilibradas de alguna manera, es decir busca obtener el nombre de usuario de la base de datos en la tabla users donde el nombre de usuario es 'admin' y la contraseña es 'admin'. Si tal registro existe, la consulta devolverá el nombre de usuario; si no, no devolverá ningún resultado. Tal que asi:
SELECT user FROM users WHERE username='admin' AND password='admin'
Para eludirdirlo, usarmos una declaración de comentario de una sola línea con un a comilla simple y una declaración de comentario al final del nombre de usuario, la parte de la consulta que verificaba la contraseña (AND password='admin') es ignorada debido al comentario --, lo que permite que la consulta devuelva el nombre de usuario 'admin' si existe en la base de datos, sin importar cuál sea la contraseñaSELECT user FROM users WHERE username=’admin’–‘ AND password=’admin’
En otras palabras, SQL ignorará el resto de las cosas después de la declaración de comentario y la consulta final sería una consulta equilibrada como esta
SELECT user FROM users WHERE username='admin'--
Le esta pidiendo al servidor que seleccione a todos aquellos registros cuyo nombre sea admin y si hay algun registro con ese nombre, nuestra consulta se vuelve verdadera.
if (query(user_inputs) == True) { // mostrar el registro}
