Inicio/Blog/🛡️ Cómo detuve un ataque de SQL injection en 5 minutos (y tú también puedes hacerlo)

🛡️ Cómo detuve un ataque de SQL injection en 5 minutos (y tú también puedes hacerlo)

RS
Por Roylan Suárez

Consultor Digital

6 de octubre de 2025

12 min

Era medianoche cuando mi teléfono explotó con cientos de notificaciones de error. Alguien estaba atacando el sitio web de mi cliente.

El momento del pánico

Imagina esto: son las 11 PM, estás a punto de dormir, y de repente tu bandeja de entrada se llena con mensajes de error del servidor. Cientos de ellos. Todos del mismo sitio web.

Mi primer pensamiento: "Esto no es normal."

Cuando abrí los logs, vi algo que me heló la sangre:

invalid literal for int() with base 10: '2-1)) OR 96=(SELECT 96 FROM PG_SLEEP(15))--'

Estábamos bajo ataque de SQL injection.

Reconociendo al enemigo

El atacante era sofisticado. Estaba intentando inyectar código SQL a través del parámetro paxs (número de personas) en el sistema de reservas. El objetivo era claro: hacer que nuestra base de datos PostgreSQL "durmiera" 15 segundos con cada petición, paralizando completamente el sitio.

La anatomía del ataque era simple pero efectiva:

  • IP origen: 180.178.33.22 (Hong Kong)
  • Vector de ataque: Parámetros GET en la URL de reservas
  • Técnica: Time-based SQL injection usando PG_SLEEP(15)
  • User-Agent falso: Haciéndose pasar por Internet Explorer 7 (¿en 2025? Obviamente sospechoso)

Además, encontré intentos similares inyectados en las cookies de sesión:

session.currency_code = "USDjrWNLu6C') OR 426=(SELECT 426 FROM PG_SLEEP(15))--"

La solución: Claude al rescate

Aquí es donde la historia se pone interesante. En lugar de pasar horas investigando, pegué los logs de error en Claude y le pedí sugerencias.

En menos de 2 minutos, Claude identificó el ataque y me dio un plan de acción paso a paso para implementar en Cloudflare.

Las tres reglas que salvaron el sitio

Como el sitio ya estaba detrás de Cloudflare, implementé tres reglas WAF (Web Application Firewall) personalizadas que Claude me sugirió. Aquí están en el orden exacto en que las configuré:

Regla 1: Block SQL Injection Attacks

Esta es la regla más crítica. Detecta patrones típicos de inyección SQL en las cookies y parámetros de la URL.

  • cookie contiene SELECT
  • cookie contiene UNION
  • cookie contiene SLEEP
  • cookie contiene PG_SLEEP
  • cookie contiene OR 1=1
  • cookie contiene "--"
  • query string contiene SELECT
  • query string contiene UNION
  • query string contiene SLEEP
  • query string contiene PG_SLEEP

Acción: Bloquear
Estado: Activo ✅

Esta regla fue la que detuvo el ataque principal. Busca palabras clave de SQL tanto en las cookies como en los parámetros GET de la URL.

Regla 2: Create IP-based rule

Bloqueo específico de la IP atacante identificada en los logs.

  • Dirección IP del origen es igual a 180.178.33.22

Acción: Bloquear
Estado: Activo ✅

Esta regla asegura que incluso si el atacante intenta variar su técnica, no puede acceder al sitio desde esa IP específica.

Regla 3: Geography-based rule

Challenge para países desde donde típicamente se originan ataques automatizados.

  • País es igual a CN
  • País es igual a HK
  • País es igual a RU

Acción: Desafío administrado
Estado: Activo ✅

Esta regla no bloquea directamente, sino que presenta un desafío (CAPTCHA) a los visitantes de estos países. Los usuarios legítimos pueden pasar, pero los bots automatizados no.

Cloudflare WAF Rules

El resultado: silencio instantáneo

Después de activar estas reglas en Cloudflare, algo mágico sucedió: los correos dejaron de llegar inmediatamente.

Revisé el dashboard de Cloudflare y ahí estaba la evidencia: cientos de peticiones bloqueadas, todas con el mismo patrón de ataque. El sitio estaba protegido.

De recibir cientos de errores por minuto, pasamos a cero en cuestión de segundos.

Cloudflare SQL

Lecciones aprendidas

  1. Los ataques no esperan horarios de oficina: Suceden cuando menos los esperas, especialmente de madrugada.

  2. Un WAF es tu primera línea de defensa: Si tu sitio maneja datos sensibles o transacciones, necesitas uno. Cloudflare es una opción accesible incluso en su plan gratuito.

  3. La parametrización de consultas es crucial: En nuestro caso, Django estaba intentando convertir el input directamente a entero sin validación previa. Aunque esto no permitía la inyección real, generaba errores que inundaban nuestros logs.

  4. La IA puede ser tu consultor de seguridad 24/7: Claude identificó el ataque y sugirió contramedidas específicas en minutos, algo que me hubiera tomado horas investigar.

  5. Monitorea siempre: Si no hubiéramos tenido alertas de error configuradas, el ataque podría haber pasado desapercibido o haber evolucionado a algo peor.

Código extra: validación en Django

Además de las reglas de Cloudflare, reforcé la validación en el código de Django:

def book_view(request):
    try:
        paxs = request.GET.get('paxs', '1')
        # Validación estricta antes de conversión
        if not paxs.isdigit() or int(paxs) < 1 or int(paxs) > 50:
            return HttpResponseBadRequest("Invalid number of passengers")
        paxs = int(paxs)
    except (ValueError, TypeError):
        return HttpResponseBadRequest("Invalid request")
    # Resto del código...

🎯 Recomendación final: no esperes a ser atacado

La mayoría de los desarrolladores piensan: "Mi sitio es pequeño, nadie me va a atacar." Error.

Los bots automatizados escanean millones de sitios diariamente buscando vulnerabilidades. No importa si tienes 10 o 10,000 usuarios. Si tienes un formulario, una base de datos o cualquier input de usuario, eres un objetivo potencial.

Mi recomendación: implementa estas protecciones antes de necesitarlas:

Activa Cloudflare o un WAF similar (el plan gratuito es suficiente para empezar)
Configura reglas básicas contra SQL injection y XSS
Valida y sanitiza TODOS los inputs del usuario en tu código
Usa consultas parametrizadas SIEMPRE (nunca concatenes SQL)
Monitorea los logs de error y configura alertas
Mantén frameworks y dependencias actualizados
Considera usar herramientas de IA como Claude para análisis rápido de amenazas

La seguridad no es un gasto, es una inversión. Y créeme, es mucho más barato prevenir un ataque que lidiar con las consecuencias de uno exitoso: datos comprometidos, reputación dañada, clientes perdidos y posibles consecuencias legales.

¿Has experimentado algo similar? ¿Qué medidas de seguridad tienes implementadas en tus proyectos? Me encantaría leer tus experiencias en los comentarios.


🔒 Mantente seguro ahí afuera. El internet es un lugar salvaje.

Compartir artículo:

¿Te ha gustado este artículo?

Recibe contenido exclusivo sobre desarrollo web, IA y tendencias tecnológicas directamente en tu email.

Contactar para proyecto
🛡️ Cómo detuve un ataque de SQL injection en 5 minutos (y tú también puedes hacerlo) | roylans.dev