De Desarrollador Web a Hacker Ético: Mi Primer Laboratorio de Seguridad

Por Qué Empecé

Como desarrollador web trabajando principalmente con TypeScript, Next.js y Node.js, siempre me enfoqué en construir funcionalidades. Pero últimamente vengo pensando: ¿Cómo atacan realmente las aplicaciones los hackers?

Entender seguridad ofensiva no se trata solo de hackear—se trata de convertirse en un mejor desarrollador. Si sabés cómo se comprometen los sistemas, podés construir aplicaciones más seguras desde el principio.

El Setup

Decidí armar un laboratorio local de pentesting usando Docker. Este enfoque es:

• Aislado: Todo corre en containers, no puede dañar mi sistema host

• Reproducible: Un docker-compose up y estoy listo

• Económico: Gratis, corre en mi laptop

Stack del Lab

• Kali Linux: La máquina atacante con todas las herramientas de pentesting

• DVWA: Damn Vulnerable Web Application

• bWAPP: Otra aplicación web intencionalmente vulnerable

• Mutillidae: Plataforma de entrenamiento OWASP

Todo conectado via redes Docker, completamente aislado de internet.

Primer Exploit Real: Exposición de Archivos de Config

Mi primer "hack" fue sorprendentemente simple pero revelador. Descubrí que bWAPP tenía directory listing habilitado en /config/, exponiendo archivos de backup.

curl http://target/config/config.inc.php.bak

Este único comando reveló:

• Credenciales de base de datos en texto plano

• Detalles de configuración del servidor

• Configuraciones de nivel de seguridad

¿El impacto? Con estas credenciales, pude:

1. Conectarme directamente a MySQL

2. Extraer todos los passwords de usuarios

3. Acceder a toda la base de datos

Qué Me Enseñó Esto

Como desarrollador, me di cuenta de cuántos errores similares podría haber cometido:

❌ Errores Comunes de Desarrolladores

// Dejar archivos .env.backup en producción
// No deshabilitar directory listing
// Commitear secrets al historial de git
// Exponer stack traces en errores

✅ Mejores Prácticas

// Usar .dockerignore apropiadamente
// Eliminar archivos de backup antes del deploy
// Implementar controles de acceso apropiados
// Usar variables de entorno correctamente

Conexión con Mi Trabajo

Esta experiencia mejoró directamente mis proyectos profesionales:

Antes: Deployaba apps de Next.js sin pensar en headers de seguridad.

Después: Ahora configuro headers apropiados en cada proyecto:

// next.config.js
const securityHeaders = [
  {
    key: 'X-Frame-Options',
    value: 'DENY',
  },
  {
    key: 'X-Content-Type-Options',
    value: 'nosniff',
  },
  // ... más headers de seguridad
];

Próximos Pasos

Estoy siguiendo un roadmap estructurado de 15 semanas para aprender:

• Fundamentos de Linux

• Vulnerabilidades OWASP Top 10

• Reconocimiento de redes

• Pentesting de aplicaciones web

• Prácticas de desarrollo seguro

El objetivo no es convertirme en pentester full-time—es ser un desarrollador que piensa como un atacante.

Recursos

Si te interesa empezar tu propio journey en seguridad:

• OWASP WebGoat

• PortSwigger Web Security Academy (¡Gratis!)

• HackTheBox

Conclusión

Aprender seguridad ofensiva me convirtió en un desarrollador más paranoico (de la buena manera). Cada feature que construyo ahora pasa por un modelo mental de amenazas:

"¿Cómo podría un atacante abusar de esto?"

Si sos desarrollador web, te recomiendo pasar aunque sean unas pocas horas con apps intencionalmente vulnerables. Es la forma más rápida de entender qué NO hacer.

---

Actualización: Estoy documentando este viaje públicamente. Seguime si te interesa la intersección entre desarrollo web y seguridad.