REPORTE – SQL INJECTION
INTRODUCCIÓN
A continuación se presenta de forma detallada un reporte técnico sobre la Resolución del laboratorio «SQL injection with filter bypass via XML encoding» de la plataforma Portswigger. El mismo se establece con un análisis de riesgo con respecto al impacto que esta puede generar. Esto incluye CWE, Criticidad, CVSS Score, CVSS Vector y sus Componentes afectados. Sumado a ello, se especificarán las mitigaciones pertinentes, detalles técnicos del pentest y los links de referencias.
Para entender mejor este reporte, se recomienda saber cómo funciona esta vulnerabilidad de sql injection y su explotación.
ANÁLISIS DE RIESGO
CWE-89 | Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) |
IMPACTO | CRÍTICO |
CVSS BASE SCORE | 8.6 |
CVSS 3.1 VECTOR | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L |
COMPONENTES AFECTADOS | https://LAB-ID.web-security-academy.net/product?productId=number_product Parámetro: productId |
EXPLICACIÓN | La vulnerabilidad de Inyección SQL representa un fallo en el filtrado de consultas a nivel de validación de entrada cuando se realizan peticiones hacia la base de datos. Por ejemplo, esto ocurre cuando se quiere iniciar sesión y/o buscar un artículo en un sitio web. Por lo tanto, un atacante puede insertar consultas SQL maliciosas con el fin de obtener información sensible (por ejemplo, usuarios y contraseñas). |
RECOMENDACIONES
1) Parametrizar consultas desde el código fuente (en lugar de ser dinámicas): Esto permite que los valores proporcionados por los usuarios sean tratados como datos y no como parte de la estructura de la consulta SQL.
A continuación se muestra un ejemplo de cómo parametrizar consultas en JavaScript utilizando Node.js y la biblioteca mysql para interactuar con una base de datos MySQL. Se puede observar que se utiliza el signo de interrogación ‘?’ para representar los parámetros.
// Ejemplo de consulta parametrizada const userId = 1; // Supongamos que este es el ID del usuario que queremos buscar // Consulta SQL parametrizada const sql = ‘SELECT * FROM usuarios WHERE id = ?’; // Ejecutar la consulta parametrizada connection.query(sql, [userId], (error, results, fields) => { if (error) { console.error(‘Error al ejecutar la consulta: ‘ + error.message); return; } console.log(‘Resultados de la consulta:’, results); }); |
2) Sanitizar los inputs de datos en el fronted y backend: Esto se puede realizar de la siguiente manera:
Tipos de datos: Se debe asegurar que los datos ingresados por el usuario coincidan con los tipos de datos esperados. Por ejemplo, un campo de número de tarjeta de crédito debe contener solo números.
Validar longitud: Es recomendable limitar la longitud de los datos de entrada para evitar desbordamientos y problemas de rendimiento. Define longitudes máximas para campos de texto, contraseñas, etc.
Listas blancas (Whitelists): Utilizar y definir listas blancas de caracteres permitidos para cada campo. Es decir, solo aceptar los caracteres que son necesarios y seguros para el contexto.
Rechazar caracteres especiales: Rechaza cualquier caracter especial que no sea necesario para el campo en cuestión. Por ejemplo, en un nombre, podría ser apropiado permitir letras y espacios, pero no caracteres especiales.
Números de teléfono: Validar números de teléfono según un formato específico. Por ejemplo ^\+\d{1,3}(\s*\(\d{1,4}\))?\s*\d{6,}$.
Correo electrónico: Utilizar expresiones regulares para validar direcciones de correo electrónico según un formato específico. Por ejemplo. Un ejemplo en Javascript sería:
function validarCorreoElectronico(correo) { const expresionRegular = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/; return expresionRegular.test(correo); } |
Validación de Formularios y Comentarios: Marcar los campos obligatorios y asegurarse de que se completen antes de enviar el formulario. Sumado a esto, incluir un ReCaptcha al final del mismo.
3) Usar un ORM (Object Relational Mappig) actualizado como capa adicional de seguridad: Utilizar capas de abstracción de base de datos como ORM o bibliotecas de acceso a los mismos que generen consultas SQL de forma segura. Estas capas suelen manejar la seguridad de las consultas internamente.
4) Capturar Stack traces: Es recomendable llevar a cabo esta acción para no entregar información sobre errores o configuraciones a un posible atacante.
5) Establecer el principio de menor privilegio: Se recomienda asignar los permisos mínimos necesarios a las cuentas de base de datos utilizadas por la aplicación. Es decir, no se recomienda utilizar cuentas de administrador con más privilegios de los necesarios para ejecutar las operaciones requeridas por la aplicación.
6) Implementar reglas de Firewall para la prevención de intrusos:
Se pueden utilizar reglas de iptables para prevenir posibles ataques externos. Por ejemplo, para permitir la conexión a MySQLl de solo una IP específica se puede establecer la siguientes reglas:
iptables –A INPUT –p tcp —dport 3306 –s IP_CLIENTE –j ACCEPT iptables –A INPUT –p tcp —dport 3306 –j DROP |
En el caso de tener información de ciertos patrones o direcciones IP específicas de ataque, se podría llevar a cabo la siguiente configuración:
iptables –A INPUT –s IP_MALICIOSA –j DROP |
7) Llevar a cabo Prácticas de seguridad: Se recomienda llevar adelante una correcta gestión de Hardening y gestión de vulnerabilidades con respecto a los frameworks y/o tecnologías utilizadas.
8) Educar en Materia de Seguridad informática: Se recomienda educar al personal y/o trabajadores en la seguridad de los datos con respecto a la confidencialidad, integridad y disponibilidad de los mismos a través de talleres o cursos pertinentes.
DETALLES TÉCNICOS
El primer paso a auditar en el sitio web consistió en recopilar la mayor información sobre las tecnologías y estructura que componen al mismo. Teniendo esto en cuenta, se pudo comprobar que la codificación de los datos se envían en XML cuando se intenta verificar el stock de un producto vía el botón “chek stock”.
A través de la herramienta BurpSuit, se pudo visualizar el envío de datos de la siguiente manera.
Llegado a este punto, se procedió a inyectar consultas maliciosas SQL para verificar la seguridad en el envío de datos. Para ello, se utilizó la siguiente query:
UNION SELECT null,null |
La misma posee los campos “null” para verificar la cantidad de columnas definidas en la consulta del stock en la base de datos.
Se puede observar en la captura anterior la existencia de un WAF (Web Application Firewall), el cual pudo detectar dicha consulta como un Ataque. Por lo tanto, se procedió a utilizar la extensión “Hackvector”, dentro de BurpSuit, para codificar la salida de dicha consulta en una entidad hexadecimal. Para ello, se deben seguir los siguientes pasos:
Click derecho → Extensions → Hackvector → Encode → hex_entities
Cabe mencionar que el link del repositorio de esta herramienta se encuentra en las referencias al final del reporte.
NOTA
Hackvertor es una herramienta de conversión en BurpSuit basada en etiquetas que admite varios escapes y codificaciones, incluidas entidades HTML5, codificación hexadecimal, octal, unicode, URL, etc..
De esta manera, se pudo filtrar consultas SQL sin ser detectados por el Firewall como se ve en las siguiente captura.
Entonces se puede deducir que la consulta por detrás podría ser:
SELECT stock_Id FROM table_name WHERE product=’query_to_inject’; |
Con la siguiente captura se puede comprobar que hay solo un campo mencionado en la consulta del Stock de la base de datos.
Por lo tanto, se procedió a utilizar la siguiente query para conocer las tablas existentes en la base de datos:
UNION SELECT table_name FROM information_schema.tables |
Como se puede ver, el sistema devolvió todas las tablas existentes en la base de datos. No obstante, una en particular que se pudo observar es la tabla “users”. Por tanto, se procedió a enumerar los campos o columnas de la misma a través de la siguiente query:
UNION SELECT column_name FROM information_schema.columns WHERE table_name=’users’ |
Sabiendo que existen los campos “username” y “password” dentro de la tabla “users”, se procedió a utilizar la siguiente query para enumerar los mismos:
UNION SELECT CONCAT(username,’:’,password FROM users) |
Utilizando el parámetro CONCAT para colocar dos campos en uno, no solo se pudo comprobar que la base de datos por detrás es MySQL, sino más importante aún es que se obtuvo las credenciales de acceso del usuario administrador. Por tanto, se procedió a iniciar sesión en la plataforma para demostrar que las mismas son válidas.
De esta manera se puede verificar la existencia de esta vulnerabilidad. Como así también su impacto y procedimientos para llevar a cabo su explotación.
