HackN3t YouTube

Hacking web

Hackear una web paso a paso: fuzzing de directorios y SQL injection

El repaso completo de un hackeo web básico en un lab: reconocimiento, fuzzing de directorios con ffuf, un panel de administración oculto y bypass de login con SQL injection. Con los comandos exactos y cómo blindar tu propia web.

Lectura · 6 min

Qué vas a ver

El repaso paso a paso de un hackeo web básico sobre una web vulnerable a propósito: una réplica montada para practicar, del estilo de los labs de HackTheBox. Reconoces la web, encuentras directorios ocultos, das con un panel de administración y entras con una inyección SQL. Todo en un entorno controlado y siempre ético.

  • Reconocimiento
  • Fuzzing
  • SQL injection

Qué necesitas

Kali Linux

La distro de pentesting con todo preinstalado. ffuf y las wordlists ya vienen dentro.

ffuf

Fuzzer de directorios escrito en Go. Si no lo tienes: sudo apt install ffuf.

Un lab tuyo

Una web vulnerable a propósito. La de este reel es una réplica de prácticas. Nunca una web ajena.

01

Reconocimiento: mira la web como un usuario normal

Antes de lanzar nada, recorre la web a mano. Menú, secciones, formulario de contacto. La mayoría es texto y formularios que no llevan a ningún lado. Lo que buscas es por dónde entrar.

whatweb http://objetivo.local
  • whatweb te dice tecnología, servidor y CMS de la web. Viene en Kali.
02

Fuzzing de directorios con ffuf

La web tiene directorios que no están enlazados en el menú. ffuf prueba miles de nombres de una wordlist contra la URL y te dice cuáles existen de verdad. FUZZ marca el sitio donde inserta cada palabra.

ffuf -u http://objetivo.local/FUZZ -w /usr/share/wordlists/dirb/common.txt
  • -u la URL objetivo. FUZZ es el hueco donde prueba cada palabra.
  • -w el diccionario. Este viene por defecto en Kali.
  • -mc opcional: -mc 200,301,302 filtra por códigos de respuesta y te quedas solo con lo que existe.
03

Dar con el directorio /intranet

Entre los resultados sale uno que no debería estar a la vista: /intranet. Lo abres en el navegador y aparece un portal de gestión con login. No tienes credenciales, así que toca probar.

http://objetivo.local/intranet
04

Probar si el login es vulnerable a SQL injection

El primer test, el más viejo: meter una comilla simple en el campo de usuario. Si la web está mal hecha, esa comilla descuadra la consulta y suelta un error SQL. Ese error te confirma dos cosas: que es inyectable y, encima, te enseña parte de la consulta.

usuario: '
  • ' una comilla suelta rompe la query. Si ves un SQL error, es vulnerable.
05

Bypass del login con ' or 1=1 --

Ya sabes que es vulnerable, ahora entras. En el campo de usuario pones admin, cierras la comilla y añades or 1=1 para que la condición siempre se cumpla. El doble guion comenta el resto de la consulta, incluida la comprobación de la contraseña. La base de datos devuelve el usuario admin y te loguea.

usuario: admin' or 1=1 --

La consulta queda así:

SELECT * FROM users WHERE user = 'admin' or 1=1 -- ' AND pass = '...'
  • admin' cierra la comilla del nombre de usuario.
  • or 1=1 una condición que siempre es verdadera.
  • -- comenta lo que va después (el AND pass). Ojo al espacio final.
06

Dentro: dashboard y flag

Estás dentro como administrador. Ves el dashboard completo: pedidos, datos personales, todo. En un lab, aquí está la flag, el resultado que confirma que lo lograste. Todo falso, claro, son personajes de la serie. Lo importante es lo fácil que ha sido cuando la web está mal parametrizada.

Solo fines educativos. Prueba esto en webs propias o en labs y CTF autorizados, nunca contra una web ajena.

Defensas

Cómo se evita que le hagan esto a tu web

El ataque es fácil porque la web está mal hecha. Estas cuatro cosas lo cierran.

  1. 1

    Consultas parametrizadas (prepared statements)

    Nunca concatenes el texto del usuario dentro del SQL. Con consultas parametrizadas, admin' or 1=1 -- se trata como un nombre de usuario literal, no como código. Esto solo cierra casi todo el agujero.

  2. 2

    No enseñes los errores SQL al usuario

    En producción, error genérico tipo "credenciales incorrectas". El stack trace y la consulta van a tus logs, no a la pantalla del atacante. Si ve el error, le estás dando el mapa.

  3. 3

    Mínimos privilegios en la base de datos

    El usuario que usa la app no necesita ser root de MySQL. Dale solo lo justo. Si algo se cuela, que no se lleve la base entera.

  4. 4

    No fíes la seguridad a esconder directorios

    Tener /intranet "oculto" no es seguridad, ffuf lo encuentra igual. Pon autenticación de verdad y, si puedes, un WAF delante.

Más a fondo: ffuf · OWASP SQL Injection.

Preguntas frecuentes

¿Hacer esto es legal?
Solo en webs tuyas o en labs y CTF autorizados (HackTheBox, TryHackMe o réplicas de prácticas como la del vídeo). Lanzar ffuf o un payload SQL contra una web ajena sin permiso es delito en España. Aquí todo es en entorno controlado y siempre ético.
¿Qué es ffuf y de dónde saco la wordlist?
ffuf es un fuzzer rápido escrito en Go. Viene en Kali (sudo apt install ffuf si no lo tienes). Las wordlists están en /usr/share/wordlists/: dirb, dirbuster y seclists. La del vídeo es la que trae Kali por defecto.
¿Por qué funciona ' or 1=1 -- ?
Porque la web mete tu texto directo en la consulta SQL sin filtrarlo. or 1=1 hace que la condición del login siempre sea cierta y -- borra la comprobación de la contraseña. La base de datos devuelve el primer usuario (admin) y te deja pasar.
¿Cómo evito que le hagan esto a mi web?
Consultas parametrizadas. Es la única defensa real contra SQL injection. Cualquier framework moderno (Laravel, Django, Spring) ya las trae. El problema casi siempre es concatenar el input a mano.

Otros recursos

¿Más así?

En el canal hay mucho más

OSINT y casos reales con todo el contexto que no cabe en un Reel.