SQL Injection: Prevención desde el Frontend
Aprende qué es SQL Injection, cómo funcionan los ataques de inyección SQL y cómo prevenirlos validando y sanitizando datos antes de enviarlos al servidor.
TL;DR - Resumen rápido
- SQLi ocurre cuando el servidor concatena inputs en queries sin prepared statements
- Desde el frontend: valida con whitelist (define qué caracteres son válidos)
- Usa expresiones regulares específicas para cada tipo de dato (username, email, número)
- Sanitiza eliminando caracteres SQL peligrosos (',", ;, --, OR, AND, UNION)
- Envía con JSON en POST y el servidor DEBE usar prepared statements (obligatorio)
Introducción a SQL Injection
SQL Injection (SQLi) es una vulnerabilidad crítica que permite a atacantes manipular consultas SQL mediante la inyección de código malicioso en inputs de la aplicación. Aunque SQLi es una vulnerabilidad del servidor, el frontend juega un papel crucial en su prevención mediante la validación y sanitización de datos antes de enviarlos al backend.
Cuando una aplicación construye consultas SQL concatenando directamente inputs del usuario sin validar, un atacante puede inyectar código SQL que altere el comportamiento de la consulta. Esto puede resultar en robo de datos, modificación no autorizada de la base de datos, o incluso toma de control del servidor.
Responsabilidad Compartida
Aunque la prevención definitiva de SQLi debe implementarse en el servidor usando prepared statements y parameterized queries, el frontend debe validar y sanitizar todos los inputs como primera línea de defensa. Esta validación mejora la seguridad y la experiencia de usuario.
Cómo Funciona SQL Injection
SQL Injection funciona cuando una aplicación construye consultas SQL dinámicamente concatenando strings sin validar ni escapar los inputs del usuario. Esto permite que caracteres especiales como comillas, comentarios y operadores SQL alteren la estructura de la consulta.
- <strong>Input malicioso</strong>: El atacante introduce código SQL en un campo de formulario
- <strong>Concatenación insegura</strong>: El servidor construye la consulta concatenando el input
- <strong>Alteración de consulta</strong>: El código inyectado modifica la lógica de la consulta SQL
- <strong>Ejecución no autorizada</strong>: La base de datos ejecuta la consulta modificada
- <strong>Acceso no autorizado</strong>: El atacante obtiene acceso a datos o funcionalidades
Tipos de Ataques SQL Injection
Existen varios tipos de ataques SQLi, cada uno con objetivos y técnicas diferentes. Entender estos tipos es fundamental para implementar las defensas adecuadas.
Los tres tipos principales son: bypass de autenticación (admin' OR '1'='1' -- hace que la consulta siempre retorne true), union-based (usa UNION SELECT para extraer datos de otras tablas), y blind injection (extrae datos byte por byte observando diferentes respuestas del servidor). Desde el frontend, tu rol es validar inputs usando whitelist antes de enviar al servidor.
Impacto de SQLi
SQL Injection es una de las vulnerabilidades más críticas según OWASP. Puede resultar en robo de datos sensibles, modificación o eliminación de datos, elevación de privilegios, y en casos extremos, toma de control completo del servidor de base de datos.
Prevención desde el Frontend
La prevención de SQLi desde el frontend se basa en tres pilares fundamentales: validación estricta de inputs, sanitización de datos, y uso de APIs seguras para enviar información al servidor. Aunque estas medidas no reemplazan la validación del servidor, son una primera línea de defensa crítica.
- <strong>Validación de inputs</strong>: Verifica que los datos cumplan con el formato esperado
- <strong>Sanitización</strong>: Elimina o escapa caracteres peligrosos antes de enviar
- <strong>Whitelist</strong>: Define exactamente qué caracteres son permitidos
- <strong>Validación de tipo</strong>: Asegura que los datos sean del tipo correcto
- <strong>Validación de longitud</strong>: Limita el tamaño de los inputs
Validación de Inputs
La validación de inputs es la primera línea de defensa. Debes verificar que todos los datos entrantes cumplan con el formato esperado antes de enviarlos al servidor.
La validación whitelist define exactamente qué es válido usando expresiones regulares. Por ejemplo,/^[a-zA-Z0-9_-]{3,20}$/ solo permite letras, números, guiones y guiones bajos de 3 a 20 caracteres. Si un username contiene ' o OR, la validación falla inmediatamente. Rechazar es más seguro que intentar "limpiar" el input.
Validación de Lista Blanca
Usa validación de lista blanca (whitelist) en lugar de lista negra. Define exactamente qué caracteres son permitidos y rechaza todo lo demás. Es más seguro y fácil de mantener que intentar bloquear patrones maliciosos específicos.
Sanitización de Datos
La sanitización elimina o escapa caracteres peligrosos que podrían ser usados en ataques SQLi. Aunque la sanitización no reemplaza la validación, es una capa adicional de defensa.
La función elimina caracteres como ', ", ; y-- que se usan en ataques SQL. Para username, usa replace(/[^a-zA-Z0-9_-]/g, '')que solo mantiene caracteres seguros. La sanitización es una capa adicional pero NO reemplaza la validación: siempre valida primero, sanitiza después, y el servidor debe usar prepared statements.
Sanitización Contextual
La sanitización debe ser contextual según el tipo de dato. Por ejemplo, los campos de email requieren validación diferente a los campos de números o fechas. Usa expresiones regulares específicas para cada tipo de dato.
Uso de APIs Seguras
El uso de APIs seguras para enviar datos al servidor es fundamental para prevenir SQLi. Esto incluye el uso de métodos HTTP apropiados, headers de seguridad, y formatos de datos estructurados.
Usar JSON.stringify(datos) en el body de POST es más seguro que parámetros URL porque los datos no quedan expuestos en logs del servidor o historial del navegador. Incluye el headerX-Requested-With: XMLHttpRequest para ayudar al servidor a identificar peticiones legítimas. Siempre valida y sanitiza antes de enviar, y usa POST para operaciones sensibles.
Métodos HTTP Seguros
Usa métodos HTTP apropiados según la acción: GET para consultas, POST para crear datos, PUT/PATCH para actualizar, y DELETE para eliminar. Nunca uses GET para operaciones que modifican estado, ya que los parámetros URL pueden ser manipulados más fácilmente.
Errores Comunes
Estos son los errores más frecuentes que cometen los desarrolladores al intentar prevenir SQLi desde el frontend, y cómo evitarlos.
Los errores más graves son: usar blacklist (los atacantes escriben O R en lugar deOR para evadir), intentar "limpiar" removiendo caracteres (ineficaz porque los atacantes encuentran nuevas formas), no validar longitud (permite ataques de desbordamiento), y confiar solo en validación del cliente. La solución es whitelist estricta + prepared statements en el servidor.
Validación en Servidor es Obligatoria
Nunca confíes solo en la validación del frontend. Los atacantes pueden saltar la validación del cliente usando herramientas como Postman, curl, o manipulando el DOM. La validación del servidor con prepared statements es obligatoria para prevenir SQLi.
Resumen: Prevención de SQL Injection
Conceptos principales:
- •SQLi manipula consultas concatenando inputs sin validar: admin' OR '1'='1' --
- •Bypass de autenticación hace queries siempre true, union-based extrae datos de otras tablas
- •Blind injection extrae datos byte por byte observando diferentes respuestas
- •El frontend valida ANTES de enviar, el servidor usa prepared statements (obligatorio)
- •Whitelist define qué es válido, blacklist intenta bloquear caracteres peligrosos (ineficaz)
Mejores prácticas:
- •Usa regex whitelist: /^[a-zA-Z0-9_-]{3,20}$/ para username
- •Sanitiza con replace(/[^a-zA-Z0-9_-]/g, '') para eliminar caracteres peligrosos
- •Valida tipo, longitud y formato: typeof === 'string' && input.length <= maxLen
- •Envía con JSON en POST, no parámetros URL (quedan en logs)
- •El servidor DEBE usar prepared statements, no concatenación de strings