La Aventura de Aprender > Ciberseguridad > Análisis Forense

Print Friendly, PDF & Email

Categoría: Análisis Forense

  • OWASP Top 10

    OWASP Top 10

    La seguridad en aplicaciones web se ha convertido en uno de los pilares fundamentales de la tecnología moderna. Desde los primeros años de Internet hasta las complejas arquitecturas distribuidas actuales, la superficie de ataque no ha dejado de crecer. Las organizaciones, instituciones educativas, empresas y desarrolladores individuales dependen a diario de servicios expuestos en la web: sistemas de comercio electrónico, portales de administración pública, aplicaciones financieras, APIs móviles, servicios en la nube y plataformas de datos.
    En este ecosistema hiperconectado, la seguridad ya no es opcional, y comprender cómo se diseñan, evalúan y protegen las aplicaciones es una competencia esencial.

    En este contexto nace OWASP, siglas de Open Web Application Security Project, un proyecto abierto creado en 2001 con un objetivo claro: mejorar la seguridad del software de manera global, accesible y colaborativa. OWASP no pertenece a ninguna empresa ni responde a intereses comerciales; es una comunidad independiente formada por miles de profesionales, investigadores, empresas, voluntarios y académicos que comparten herramientas, documentación, buenas prácticas y estándares destinados a reducir el riesgo en aplicaciones web.

    A lo largo de más de dos décadas, OWASP ha evolucionado de un pequeño repositorio comunitario a convertirse en la referencia internacional en materia de seguridad de aplicaciones. Sus proyectos son utilizados por desarrolladores, auditores, equipos de ciberseguridad, gobiernos y universidades. La calidad y madurez de sus aportaciones ha hecho que muchas de sus metodologías formen hoy parte de marcos oficiales, certificaciones internacionales e incluso procesos internos de desarrollo en grandes corporaciones.

    OWASP Top Ten 2021:

    El OWASP Top Ten: un estándar, no una lista

    Entre todos los proyectos que mantiene OWASP, el más conocido es el OWASP Top Ten, una clasificación periódica que identifica las diez categorías de riesgos más críticos en aplicaciones web.
    Es importante subrayar que no se trata de un listado arbitrario, sino de un estándar de seguridad utilizado para:

    • Establecer requisitos mínimos en auditorías.
    • Formar a desarrolladores y equipos técnicos.
    • Definir políticas de desarrollo seguro.
    • Cumplir normativas o marcos de compliance.
    • Priorizar esfuerzos de corrección en aplicaciones reales.

    El Top Ten se elabora a partir de datos aportados por empresas de seguridad, análisis de millones de aplicaciones, estadísticas de ataques y consensos de la comunidad. De esta forma se consigue una visión realista y basada en datos sobre qué riesgos son realmente explotados por atacantes y qué errores aparecen con mayor frecuencia en el software moderno.

    La edición vigente a día de hoy, OWASP Top 10 – 2021, supuso un cambio importante respecto a sus predecesores. No solo reorganizó las categorías tradicionales, sino que introdujo nuevos conceptos como Insecure Design y amplió la visión hacia la causa raíz de los fallos, no solo sus síntomas. Al mismo tiempo, OWASP continúa evolucionando y, en 2025, ya existe un Top Ten 2025 Release Candidate, en fase de revisión, que refuerza áreas como la cadena de suministro (software supply chain), la gestión de configuraciones y el manejo de errores críticos. Aunque aún no sustituye oficialmente a la versión de 2021, nos ofrece una visión clara de hacia dónde se dirige la seguridad web en los próximos años.

    La relevancia de OWASP en el panorama actual

    La importancia de OWASP no reside únicamente en su famoso Top Ten. Su comunidad mantiene numerosos proyectos fundamentales en ciberseguridad, entre ellos:

    • OWASP Testing Guide, para pruebas de seguridad sistemáticas.
    • OWASP ASVS, un estándar completo para verificar aplicaciones.
    • OWASP MASVS, equivalente para seguridad móvil.
    • OWASP Cheat Sheets, una colección esencial de guías rápidas prácticas.
    • OWASP ZAP, una herramienta gratuita utilizada mundialmente para pentesting web.

    Estos recursos permiten comprender, evaluar y corregir la seguridad desde múltiples perspectivas: desarrollo seguro, auditoría, análisis forense, arquitectura de software o gestión de riesgos.

    El valor de OWASP es especialmente relevante hoy porque:

    1. La mayoría de ataques exitosos explotan fallos básicos que OWASP describe y enseña a prevenir.
    2. El software moderno es más complejo que nunca: microservicios, contenedores, APIs, nubes híbridas, y automatización continua.
    3. Las brechas de seguridad tienen impactos empresariales enormes: pérdidas económicas, daños reputacionales, sanciones legales y robo masivo de datos.
    4. La industria necesita profesionales formados y actualizados, capaces de analizar código, revisar configuraciones, identificar vulnerabilidades y aplicar mitigaciones reales.

    Por ello, estudiar OWASP no significa memorizar diez riesgos, sino aprender a pensar como un desarrollador seguro, un auditor y un atacante ético simultáneamente. Es un enfoque integral que forma parte de la cultura DevSecOps moderna.

    Comprender OWASP es comprender cómo funciona realmente la seguridad en el desarrollo web en 2025. Y, sobre todo, significa adquirir la capacidad de construir aplicaciones más robustas, detectar fallos antes de que lo hagan los atacantes, y aplicar una mentalidad de seguridad continua que acompañe al software durante todo su ciclo de vida.

    Historia resumida de OWASP

    2001 – Fundación de OWASP

    Creada por Mark Curphey para compartir buenas prácticas de seguridad en aplicaciones web.

    2003 – Primer OWASP Top Ten

    Primera clasificación pública de los riesgos más graves de seguridad web.

    2007–2013 – Consolidación

    OWASP se convierte en referencia internacional. Se publican guías clave:

    • OWASP Testing Guide
    • OWASP Code Review Guide
    • ESAPI

    2017 – Edición crítica

    Se añaden nuevas categorías como XXE y Deserialización insegura.

    2021 – OWASP Top 10 moderno

    Reorganiza las vulnerabilidades por causa raíz, añade Insecure Design y Supply Chain.

    2025 – Release Candidate (no final todavía)

    Refina los riesgos modernos:

    • Aquí tienes las 10 categorías del OWASP Top Ten 2025 para aplicaciones web:
    • A01:2025 – Broken Access Control
      Fallos en el control de acceso que permiten a atacantes eludir restricciones y acceder a datos o funcionalidades no autorizadas. [owasp.org], [cybersecur…tynews.com]
    • A02:2025 – Security Misconfiguration
      Configuraciones inseguras por defecto, servicios expuestos o controles inconsistentes que amplían la superficie de ataque. [owasp.org], [cybersecur…tynews.com]
    • A03:2025 – Software Supply Chain Failures
      Vulnerabilidades en dependencias, sistemas de construcción, CD/CI y la infraestructura de distribución. [owasp.org], [cybersecur…tynews.com]
    • A04:2025 – Cryptographic Failures
      Fallos en encriptación por uso de algoritmos débiles, claves cortas o implementación incorrecta, exponiendo datos sensibles. [owasp.org], [cybersecur…tynews.com]
    • A05:2025 – Injection
      Inyección de código (SQL, OS, LDAP, etc.) por no sanitizar entradas del usuario, lo que permite ejecutar comandos maliciosos. [owasp.org], [cybersecur…tynews.com]
    • A06:2025 – Insecure Design
      Falta de diseño seguro desde etapas tempranas, abordando seguridad solo como parche, no de forma integral. [owasp.org], [cybersecur…tynews.com]
    • A07:2025 – Authentication Failures
      Deficiencias en mecanismos de autenticación como inicio de sesión o recuperación de cuentas, que facilitan suplantación. [owasp.org], [cybersecur…tynews.com]
    • A08:2025 – Software or Data Integrity Failures
      Fallos que permiten modificar el software o datos sin detección, comprometiendo su integridad. [owasp.org], [cybersecur…tynews.com]
    • A09:2025 – Security Logging & Alerting Failures
      Registro y alertas de seguridad insuficientes, que dificultan detectar ataques y responder adecuadamente. [owasp.org], [cybersecur…tynews.com]
    • A10:2025 – Mishandling of Exceptional Conditions
      Manejo deficiente de errores y condiciones excepcionales, que puede exponer datos sensibles o permitir DoS. [cybersecur…tynews.com], [cyberpress.org]

    Estas diez categorías representan los riesgos más críticos para la seguridad de las aplicaciones web según la edición 2025 del OWASP Top Ten, publicada oficialmente el 6 de noviembre de 2025.
    (Sigue vigente oficialmente 2021, pero 2025 ya marca la tendencia del futuro.)

    Tabla comparativa OWASP Top 10 (2021 vs 2025)

    Puesto 2021Categoría 2021Puesto 2025Categoría 2025Cambio principal
    1Broken Access Control1Broken Access ControlSe mantiene #1; SSRF (A10:2021) se consolida dentro de esta categoría. [owasp.org]
    2Cryptographic Failures4Cryptographic FailuresBaja de #2 a #4. [owasp.org]
    3Injection5InjectionBaja de #3 a #5. [owasp.org]
    4Insecure Design6Insecure DesignBaja de #4 a #6. [owasp.org]
    5Security Misconfiguration2Security MisconfigurationSube de #5 a #2 por mayor prevalencia de configuraciones complejas. [owasp.org]
    6Vulnerable and Outdated Components3Software Supply Chain FailuresExpandida al enfoque de cadena de suministro (dependencias, build, distribución). [owasp.org]
    7Identification and Authentication Failures7Authentication FailuresRenombrada para mayor precisión; posición similar. [owasp.org]
    8Software and Data Integrity Failures8Software or Data Integrity FailuresLigerísimo ajuste de nombre; categoría equivalente. [owasp.org]
    9Security Logging and Monitoring Failures9Security Logging & Alerting FailuresRenombrada enfatizando alertas accionables además del logging. [owasp.org]
    10Server-Side Request Forgery (SSRF)——Eliminada como categoría independiente; integrada en A01: Broken Access Control. [owasp.org]
    ——10Mishandling of Exceptional ConditionsNueva en 2025: manejo inadecuado de errores/condiciones excepcionales (fallar “open”, fugas, DoS). [owasp.org], [cyberpress.org]

    Observaciones rápidas

    • Grandes movimientos: Security Misconfiguration sube con fuerza (#5 → #2); Cryptographic, Injection e Insecure Design descienden dos puestos. [owasp.org]
    • Evolución de componentes: Vulnerable and Outdated Components se amplía a Software Supply Chain Failures, reflejando el peso de ataques a la cadena de suministro (dependencias, CI/CD, repos, distribución). [owasp.org], [cybersecur…tynews.com]
    • Nuevas prioridades: Entra Mishandling of Exceptional Conditions (#10), centrada en errores y estados anómalos mal gestionados (excepciones, “fail-open”, fugas de información). [owasp.org], [cyberpress.org]
    • Consolidación: SSRF deja de ser categoría y se integra en Broken Access Control. [owasp.org]
  • 1.1 – A01:2021 Broken Access Control (Pérdida de control de acceso)

    1.1 – A01:2021 Broken Access Control (Pérdida de control de acceso)

    La frase suena como el título de un episodio donde los guardianes de las puertas se echan la siesta y cualquier polizón digital puede colarse hasta la sala de máquinas. Broken Access Control —o “cuando lo que no debería pasar… pasa”— es justo eso: el desorden silencioso que aparece cuando un sistema no comprueba bien quién puede hacer qué.

    Si lo miras con ojos de ingeniería, el acceso es un filtro. Dejas pasar a quien debe pasar, bloqueas lo que debe bloquearse. Cuando ese filtro está roto, las cosas se vuelven raras: usuarios normales que pueden ver datos de admins, URLs ocultas accesibles por curiosidad, APIs que se creen cualquier identidad que les envías, o sesiones que no se invalidan cuando deberían.

    En la jerga de seguridad, hablamos de:

    • IDOR (Insecure Direct Object Reference): accedes a /factura/1234 y cambias el número por 1235… y te muestra otra factura que no es tuya. Como si giraras la manivela de una taquilla y todas se abrieran igual.
    • Saltos de rol (Privilege Escalation): el usuario «profesor» se hace pasar por «director» porque la aplicación solo comprueba el rol en el cliente o confía en un parámetro no verificado.
    • Rutas ocultas accesibles por URL: páginas “solo para admins” que no comprueban si lo eres de verdad, solo si intentas llegar.
    • Faltas en el control de sesión: tokens que deberían expirar y no lo hacen, o sesiones que no se invalidan tras un logout.

    OWASP en 2025 sigue catalogándola como una vulnerabilidad extremadamente común y de gran impacto. Tiene una cualidad casi poética: no requiere magia negra. A menudo no necesitas explotar buffers ni inventarte payloads complejos. Solo necesitas probar cosas que un usuario jamás debería poder hacer y ver si el sistema se molesta en decir que no.

    La defensa siempre gira alrededor del mismo mantra sobrio:

    • La validación de permisos se hace en el servidor, nunca confiando en el cliente.
    • Se decide “¿puede este usuario acceder a este recurso?” en cada petición, no solo al inicio.
    • Se evitan identificadores predecibles.
    • Y se audita la lógica como si intentaras entrar en un museo fingiendo que solo buscas el baño.

    En esencia, un sistema vulnerable permite que un usuario realice acciones o acceda a recursos que no le corresponden. Es como si un becario pudiera abrir la caja fuerte porque nadie se ha molestado en comprobar la llave.

    1. Qué es realmente Broken Access Control

    El sistema debería preguntar:
    “¿Quién eres?” (autenticación)
    “¿Qué puedes hacer?” (autorización)

    Broken Access Control ocurre cuando se responde correctamente a la primera pregunta, pero se olvida la segunda. Es una pérdida de disciplina, un despiste en la mecánica de comprobar permisos en cada petición.

    A efectos prácticos, se traduce así:
    Un usuario X puede alcanzar recursos destinados a usuarios Y, o incluso a administradores.

    Los atacantes adoran esto porque no requiere técnicas oscuras. Solo curiosidad, persistencia y un poco de mala idea.

    2. Tipos más frecuentes de fallos

    Aquí está el zoológico de problemas que suelen aparecer:

    • IDOR (Insecure Direct Object Reference)
      Petición: /api/user/42
      El atacante prueba: /api/user/43
      La aplicación entrega datos ajenos. No hay magia, solo falta de control interno.
    • Escalada de privilegios
      Un usuario sin privilegios consigue actuar como otro más poderoso. A veces basta con modificar un parámetro como role=admin en una petición mal diseñada.
    • Acceso a rutas “ocultas”
      Hay páginas que se confían en el “nadie sabrá que existe esta URL”. Pero si la aplicación no verifica permisos, cualquiera que la visite entra como si nada.
    • Métodos HTTP insuficientemente protegidos
      Se bloquea GET, pero no DELETE. El atacante descubre que puede borrar recursos jugando con el verbo adecuado.
    • Controles en el cliente en vez del servidor
      JavaScript que “esconde” botones de administración, esperando que el usuario no los active manualmente. La ilusión del “seguridad por CSS”.
    • Sesiones mal invalidadas o tokens sin expiración
      El atacante reutiliza sesiones antiguas que todavía funcionan.

    3. Por qué es tan común

    Porque es un problema invisible. Los desarrolladores suelen centrarse en las funcionalidades visibles: botones, bases de datos, lógica de negocio. La autorización es más sutil. Si la aplicación funciona bien para los usuarios legítimos, se da por buena… y se olvida comprobar qué pasa si un usuario prueba lo que “no debería”.

    Además, en sistemas con microservicios, APIs REST, contenedores y autenticación distribuida, mantener un control consistente en todos los puntos del sistema se convierte en un rompecabezas.

    4. Impacto

    El impacto es directo y contundente:

    • Filtración de datos privados
    • Modificación o borrado de información sensible
    • Toma de control parcial o total de cuentas
    • Acceso a funciones administrativas
    • Compromiso completo del sistema

    No es una molestia menor: es una brecha.

    5. Cómo detectar Broken Access Control

    Las técnicas habituales recuerdan al trabajo detectivesco, probando caminos prohibidos:

    • Manipular parámetros: IDs, nombres, UUIDs.
    • Probar diferentes métodos HTTP.
    • Fuerza bruta sobre rutas en el servidor.
    • En APIs, repetir peticiones cambiando el “subject” del recurso.
    • Comprobar respuestas diferentes según roles.
    • Revisar la lógica interna buscando decisiones basadas en el cliente.

    Aquí tus alumnos juegan casi a ser arqueólogos digitales, buscando grietas en la lógica.

    6. Cómo prevenirlo

    Los principios de defensa son sobrios pero muy efectivos:

    Control de acceso en el servidor, siempre.
    El cliente nunca es una fuente de verdad. Puedes ocultar botones, pero la validación real debe hacerse en el backend.

    Comprobación de permisos en cada petición.
    Cada vez que un usuario pide un recurso: “¿Puede este usuario acceder a este recurso concreto?”.

    IDs no predecibles.
    Si no pueden adivinar el identificador, es más difícil explotar IDOR. Aunque no es una defensa completa, ayuda.

    Tokens con expiración y revocación real.
    Una sesión debe morir cuando se cierra sesión.

    Segregación de funciones.
    Accesos administrativos separados y auditados. No mezclar roles como si fuesen cromos repetidos.

    Registros y auditorías.
    Si algo falla, debe quedar rastro. Los sistemas sin logs son como cajas negras sin grabadora.

    Pruebas de control de acceso automatizadas.
    Integrarlas en el pipeline evita que años después aparezca el clásico “¿cómo que cualquier usuario puede borrar pedidos?”.

    7. Ejemplo narrado

    Imagina que gestionas una tienda online. Un usuario autenticado visita:

    GET /pedidos/1287

    La aplicación entrega su pedido correctamente. Pero el atacante cambia el número:

    GET /pedidos/1288

    Si aparece otro pedido, hay un IDOR. La aplicación ha dado por hecho que si conoces el número, eres su dueño.

    Ahora imagina otra escena. En el panel interno, un usuario intenta acceder a:

    /admin/usuarios/listado

    La página carga sin comprobar su rol. Ese es el acceso directo a funciones críticas: falta de verificación de roles.

    En el tercer acto, un token de sesión sigue funcionando horas después del logout. Resultado: sesión no invalidada, un regalo para cualquiera que haya interceptado ese token.

    9. Relación con APIs modernas

    En sistemas basados en tokens (JWT, OAuth2), microservicios y Kubernetes, el control de acceso ya no es un único portero, sino un equipo entero. Cada servicio debe validar el token, verificar permisos y, sobre todo, no confiar en nada que venga del exterior.

    Los fallos en estos entornos suelen ser:

    • Servicios internos que no verifican el scope del token.
    • Roles definidos en el cliente, no en el backend.
    • Comunicaciones entre microservicios sin autenticación mutua.

    Las APIs son un campo fértil para este tipo de errores.

  • 1.2 – [Herramientas] – Postman

    1.2 – [Herramientas] – Postman

    En el mundo real —y en el mundo OWASP— el fallo más común no suele ser una inyección digna de Hollywood, sino algo mucho más mundano: el control de acceso mal aplicado. El punto 1 del OWASP Top 10, conocido como A01: Broken Access Control, lleva años liderando el ranking porque rompe la promesa básica de cualquier sistema: cada usuario solo puede hacer lo que le toca.

    Aquí es donde entra Postman, una herramienta que, usada con mentalidad de auditor, se convierte en una lupa perfecta para detectar accesos indebidos, IDORs y permisos mal definidos… sin necesidad de levantar un laboratorio complejo.

    Para en Windows, Mac y Linux. Puedes descargarlo aquí:

    https://www.postman.com/downloads

    Para OWASP A01 en una frase clara

    Broken Access Control ocurre cuando una aplicación no verifica correctamente quién eres y qué puedes hacer, permitiendo acciones como:

    • Acceder a recursos de otros usuarios.
    • Ejecutar funciones administrativas sin ser admin.
    • Modificar datos que deberían ser de solo lectura.
    • Saltarse flujos lógicos del backend.

    No es magia negra. Es lógica mal aplicada.

    Por qué Postman es ideal para auditar A01

    Postman no es solo “un cliente para hacer peticiones”. Es una consola de pruebas controladas donde puedes:

    • Repetir peticiones exactas.
    • Cambiar headers, tokens y parámetros a voluntad.
    • Simular distintos usuarios sin cambiar de sesión real.
    • Comparar respuestas del backend sin pasar por el frontend.

    En seguridad, quitar el frontend es quitar el maquillaje. Lo que queda es la verdad del backend.

    Caso práctico mental: el backend desnudo

    Imagina una API típica:

    GET /api/pedidos/123
Authorization: Bearer TOKEN_USUARIO

    Con Postman puedes:

    • Cambiar el 123 por otro ID.
    • Reutilizar el mismo token.
    • Ver si el servidor comprueba la propiedad del recurso o solo confía en el ID.

    Si responde con datos que no son tuyos, no hay debate: A01 confirmado.

    Qué pruebas de Broken Access Control se hacen con Postman

    1. IDOR (Insecure Direct Object Reference)

    Cambias identificadores (id, user_id, order_id) y observas:

    • ¿Devuelve datos?
    • ¿Devuelve error 403?
    • ¿Devuelve “no encontrado” solo cuando conviene?

    Un backend sano no distingue entre “no existe” y “no es tuyo”.

    2. Escalada horizontal

    Mismo rol, distinto usuario.

    Ejemplo:

    • Usuario A accede a /api/profile/45
    • Usuario B prueba /api/profile/45

    Si ambos ven lo mismo, el sistema cree que “autenticado” es suficiente. Spoiler: no lo es.

    3. Escalada vertical

    Pruebas endpoints de administrador con un token normal:

    POST /api/admin/users

    Si la respuesta no es un 403 inmediato, hay un problema estructural, no un bug puntual.

    4. Métodos HTTP olvidados

    Con Postman puedes cambiar el verbo en segundos:

    • GET → PUT
    • PUT → DELETE

    Muchos sistemas protegen la vista, pero no la acción. El backend acepta lo que el frontend jamás envía.

    5. Falta de control en acciones lógicas

    No todo es CRUD. Prueba acciones como:

    • “cerrar pedido”
    • “aprobar solicitud”
    • “finalizar reserva”

    Si el backend no valida el estado previo y el rol, Postman lo descubre rápido.

    Postman como herramienta docente (y no solo ofensiva)

    Aquí viene la parte elegante: Postman no solo sirve para atacar, sino para enseñar a pensar bien.

    En clase o laboratorio, permite que el alumnado:

    • Vea la diferencia entre autenticación y autorización.
    • Entienda por qué el control debe estar en el backend.
    • Aprenda a documentar evidencias claras (request + response).
    • Desarrolle mentalidad de auditor: observar, probar, registrar.

    La seguridad no va de romper cosas, va de demostrar por qué se rompen.

    Buenas prácticas que Postman ayuda a verificar

    Un backend bien diseñado debería:

    • Validar permisos en cada endpoint, no en el frontend.
    • No confiar en IDs enviados por el cliente.
    • Aplicar roles y ownership en lógica de servidor.
    • Responder con errores coherentes (403 > 401 > 404).

    Postman no arregla estos problemas, pero los deja al descubierto con brutal honestidad.

    Conclusión: el bisturí del A01

    Postman es a Broken Access Control lo que un bisturí es a la anatomía:
    no grita, no hace ruido, pero corta justo donde duele.

    Usado con ética y método, es una de las mejores herramientas para entender por qué A01 sigue siendo el rey del OWASP Top 10 y por qué el control de acceso no es una opción, sino la base de todo sistema seguro.

    Proyecto guiado: “Postman vs. OWASP A01 – Auditoría de Control de Acceso en un CRUD con sesión”

    Usar Postman para auditar un CRUD con autenticación (sesión) y detectar fallos típicos de Broken Access Control:

    • IDOR: acceder/modificar recursos de otros.
    • Escalada horizontal: mismo rol, otro usuario.
    • Escalada vertical: endpoints “admin” accesibles sin serlo.
    • Métodos HTTP y acciones no previstas por el frontend.
    • Validación de ownership (propiedad del recurso) en el backend.

    Resultados

    1. Colección de Postman con:
    • requests organizadas por carpetas,
    • variables de entorno,
    • tests automáticos básicos.
    1. Informe de auditoría (capturas + evidencias):
    • Request y response (código, body relevante),
    • Resultado esperado vs. real,
    • Conclusión: “OK” o “Vulnerable” + impacto.

    Requisitos

    • Una con un CRUD funcionando en Apache.
    • Dos usuarios reales en la app:
      • userA (normal)
      • userB (normal)
      • Opcional: admin (si existe rol)
    • Cada usuario debe tener al menos 2 registros creados en el CRUD (por ejemplo “posts”, “productos”, “reservas”, etc.).

    Reglas de seguridad (muy importante)

    • Solo probar contra el entorno del aula/lab, no producción.
    • No borrar datos de otros equipos/grupos.
    • Si se detecta un fallo, se documenta: no se explota.

    1) Instalar y preparar Postman

    1. Instala Postman (desktop).
    2. Crea un Workspace: OWASP-A01-Auditoria-CRUD.
    3. Crea un Environment: LAB-CRUD.
    4. Añade estas variables:
    • baseUrl = http://IP_O_DOMINIO_DEL_SERVIDOR
    • usernameA = userA
    • passwordA = ...
    • usernameB = userB
    • passwordB = ...
    • cookieA = (vacío)
    • cookieB = (vacío)
    • idA_1 = (vacío)
    • idB_1 = (vacío)

    Nota: vamos a guardar cookies de sesión para simular usuarios distintos.

    2) Descubrir endpoints reales (sin adivinar)

    Aquí no inventamos rutas: las sacamos del propio sistema.

    2.1 Identificar la request de login

    1. En el navegador, abre DevTools → Network.
    2. Inicia sesión como userA.
    3. Busca la request de login y apunta:
      • Método (POST/GET)
      • URL exacta
      • Tipo de datos (form-data, x-www-form-urlencoded, JSON)
      • Respuesta (¿redirige? ¿devuelve JSON? ¿set-cookie?)

    Ejemplo típico (orientativo):

    • POST /login.php
    • body: username=...&password=...
    • response: Set-Cookie: PHPSESSID=...

    2.2 Identificar endpoints del CRUD

    Repite en Network mientras haces:

    • listar
    • ver detalle
    • crear
    • editar
    • borrar

    Apunta URLs y parámetros.

    Vamos a hacer dos flujos de login (usuario A y usuario B) y guardar sus cookies.

    3.1 Carpeta “Auth”

    Crea una colección: A01 - CRUD Audit.
    Dentro crea carpeta 01_AUTH.

    Request: Login - UserA

    • Método/URL: el del sistema (ej: POST {{baseUrl}}/login.php)
    • Body: los campos reales

    En Tests, añade:

    // Guarda cookie de sesión (si el backend usa cookies)
const cookie = pm.response.headers.get('Set-Cookie');
if (cookie) {
  pm.environment.set('cookieA', cookie.split(';')[0]); // PHPSESSID=...
}
pm.test("Login UserA devuelve 200/302", function () {
  pm.expect([200,302]).to.include(pm.response.code);
});

    Request: Login - UserB

    Igual, pero guardando cookieB:

    const cookie = pm.response.headers.get('Set-Cookie');
if (cookie) {
  pm.environment.set('cookieB', cookie.split(';')[0]);
}
pm.test("Login UserB devuelve 200/302", function () {
  pm.expect([200,302]).to.include(pm.response.code);
});

    Si tu app no devuelve Set-Cookie en login porque ya lo setea antes, Postman igual puede mantener cookies con su “Cookie Jar”. Pero para enseñar A01, guardar cookie en variable hace que el alumno entienda qué está pasando.

    4) Preparar “headers por usuario” (simular identidad)

    En cada request del CRUD, pon el header:

    • Para simular UserA:
      • Cookie: {{cookieA}}
    • Para simular UserB:
      • Cookie: {{cookieB}}

    Crea dos carpetas:

    • 02_CRUD_UserA
    • 03_CRUD_UserB

    Y duplica requests para cada usuario (sí, duplicar aquí ayuda a aprender).

    5) Paso clave: obtener IDs reales de cada usuario

    Necesitamos un ID de un recurso de A y otro de B para probar IDOR.

    5.1 Listar recursos como UserA

    Request: List - UserA

    • GET {{baseUrl}}/ruta_listado (la real)

    En Tests, intenta extraer un id del JSON/HTML.

    • Si la API devuelve JSON (ideal):
    const data = pm.response.json();
pm.environment.set("idA_1", data[0].id);
pm.test("Tengo idA_1", () => pm.expect(pm.environment.get("idA_1")).to.not.be.undefined);
    • Si devuelve HTML, el alumno puede copiar el ID manualmente del listado o detalle y ponerlo en idA_1.

    5.2 Repetir con UserB

    Request: List - UserB y guardar/copiar idB_1.

    6) Pruebas OWASP A01 con Postman (con ejemplos)

    Ahora viene el núcleo. Cada prueba tiene:

    • Qué se prueba
    • Cómo hacerlo en Postman
    • Qué sería correcto
    • Qué sería vulnerable

    6.1 IDOR de lectura (Broken Access Control)

    Prueba

    UserA intenta ver el recurso de UserB.

    Request (como UserA):

    GET {{baseUrl}}/recurso/{{idB_1}}
    Header:

    • Cookie: {{cookieA}}

    Resultado correcto

    • 403 Forbidden o un error equivalente (o 404 “no existe”).
    • Nunca debería devolver el contenido del recurso de B.

    Vulnerable

    • Devuelve 200 y muestra el recurso de B.

    📌 Evidencia en informe:

    • URL + cookieA + response.

    6.2 IDOR de modificación (PUT/POST/EDIT)

    Prueba

    UserA intenta editar el recurso de B.

    Ejemplo (orientativo):

    • POST {{baseUrl}}/recurso/edit.php?id={{idB_1}}
      o
    • PUT {{baseUrl}}/api/recurso/{{idB_1}}

    Body: cambia un campo (ej. title=HACKED_BY_A).

    Resultado correcto

    • 403 / error.
    • El recurso no cambia.

    Vulnerable

    • 200 / “ok” y el recurso de B aparece modificado.

    📌 Extra didáctico:

    • Tras editar, hacer GET del recurso y comprobar si cambió.

    6.3 IDOR de borrado (DELETE)

    Prueba

    UserA intenta borrar el recurso de B.

    Ejemplo:

    • DELETE {{baseUrl}}/api/recurso/{{idB_1}}
      o
    • POST {{baseUrl}}/recurso/delete.php?id={{idB_1}}

    Resultado correcto

    • 403 / no permitido.

    Vulnerable

    • Recurso eliminado.

    ⚠️ En clase:

    • Hazlo en un “registro señuelo” para no romper trabajos.

    6.4 Escalada vertical (usuario normal llama a admin)

    Si existe panel admin:

    • GET {{baseUrl}}/admin/users
    • POST {{baseUrl}}/admin/create-user

    Como UserA (cookieA).

    Correcto: 403.
    Vulnerable: 200.

    Si no existe admin en su app, crea un endpoint “solo admin” ficticio en el enunciado como extensión (pero aquí trabajamos con lo real).

    6.5 Fallo por confiar en parámetros (user_id)

    Muchos CRUD hacen esto:

    • POST /recurso/create con user_id=...

    Prueba

    UserA crea un recurso pero forzando user_id={{idDeB}} o similar.

    Correcto:

    • El backend ignora ese user_id y asigna el de la sesión.
      Vulnerable:
    • Se puede crear contenido “a nombre de otro”.

    7) Tests automáticos en Postman (mini “cinturón de seguridad”)

    En cada request de prueba A01 añade tests como:

    pm.test("No debería permitir acceso indebido", function () {
  pm.expect([401,403,404]).to.include(pm.response.code);
});

    Y en las que sean “normales” (acceso legítimo):

    pm.test("Acceso legítimo OK", function () {
  pm.expect(pm.response.code).to.eql(200);
});

    Esto enseña a pensar como QA + seguridad: expectativas claras.

    8) Estructura de la colección (lista final)

    Colección A01 - CRUD Audit:

    • 01_AUTH
      • Login UserA
      • Login UserB
    • 02_CRUD_UserA
      • List A
      • View A (idA_1)
      • View B (idB_1) IDOR read test
      • Edit B (idB_1) IDOR write test
      • Delete B (idB_1) IDOR delete test
    • 03_CRUD_UserB
      • (equivalentes)
    • 04_A01_REPORT_EVIDENCES
      • Requests “limpios” que sirvan de referencia para el informe

    9) Guion de un informe

    Cada hallazgo debe tener:

    • Título: “IDOR lectura en /recurso/{id}”
    • Usuario atacante: UserA
    • Recurso víctima: idB_1
    • Pasos (Postman): request exacta + headers
    • Resultado esperado: 403/404
    • Resultado real: 200 con datos
    • Impacto: acceso a datos de terceros / modificación / borrado
    • Recomendación:
      • Verificar ownership en backend
      • Reglas RBAC/ABAC
      • No confiar en IDs del cliente
      • Tests de autorización por endpoint
  • 1.3 – [Herramientas] – Qué es curl

    1.3 – [Herramientas] – Qué es curl

    curl es un cliente de línea de comandos para hacer peticiones a URLs (HTTP/HTTPS y más). En ciberseguridad sirve para:

    • Reproducir una request exacta (sin navegador, sin JS, sin “magia”).
    • Cambiar headers, cookies, método (GET/POST/PUT/DELETE…), body, redirects, TLS, etc.
    • Guardar evidencias: headers, cuerpo, tiempos, códigos, trazas.
    • Automatizar pruebas: loops, wordlists, comparación de respuestas.

    En OWASP A01, curl es ideal para comprobar:

    “¿Puedo acceder a algo que no debería si cambio un ID, un rol, un método, una ruta o un header?”

    1) Base rápida: anatomía de una request con curl

    1.1 GET simple

    curl https://ejemplo.com/

    1.2 Ver solo headers (respuesta)

    curl -I https://ejemplo.com/

    1.3 Ver request + response (debug)

    • -v muestra el intercambio HTTP (ideal para auditoría).
    curl -v https://ejemplo.com/

    1.4 Seguir redirecciones

    Muchas apps redirigen a /login.

    curl -L https://ejemplo.com/zona-privada

    2) Opciones clave (las que usarás todo el rato)

    Salida y verbosidad

    • -i incluye headers de respuesta en la salida
    • -I hace HEAD (solo headers)
    • -v verbose (request/response)
    • -s silent (menos ruido)
    • -S muestra errores aunque uses -s
    • -D <file> guarda headers de respuesta en un fichero
    • -o <file> guarda el cuerpo en fichero
    • -w "<fmt>" imprime métricas (código, tiempos, etc.)

    Ejemplo “limpio pero con datos útiles”:

    curl -sS -D headers.txt -o body.html -w "STATUS=%{http_code}\nTIME=%{time_total}\n" https://ejemplo.com/

    Método HTTP

    • -X GET|POST|PUT|DELETE|PATCH|OPTIONS|HEAD

    Ojo nerd: curl elige método según uses -d (si usas -d, por defecto es POST). A veces conviene ser explícito con -X.

    Headers y autenticación

    • -H "Header: valor" añade header(s)
    • -u user:pass Basic Auth
    • -b "cookie=valor" envía cookies
    • -c cookies.txt guarda cookies en “cookie jar”
    • -b cookies.txt reutiliza cookies guardadas

    Datos (body)

    • -d "a=1&b=2" envía body tipo form-url-encoded
    • --data-urlencode codifica bien caracteres especiales
    • -H "Content-Type: application/json" -d '{"x":1}' JSON
    • -F "f=@archivo" multipart/form-data (subidas)

    TLS y certificados (útil en auditoría)

    • --tlsv1.2 fuerza versión TLS
    • --ciphers ... fuerza cifrados (avanzado)
    • --cert, --key (mTLS)
    • -k ignora validación del certificado (solo pruebas controladas, jamás en producción como “solución”)

    3) Plantilla de trabajo “A01-ready” (para evidencias)

    Esto te deja una salida reproducible, guardando pruebas:

    curl -sS -i -L \
  -w "\n\n---\nSTATUS=%{http_code}\nSIZE=%{size_download}\nTIME=%{time_total}\nIP=%{remote_ip}\nURL=%{url_effective}\n" \
  https://objetivo.tld/ruta

    Para separar headers y body en ficheros:

    curl -sS -D evidencias_headers.txt -o evidencias_body.txt \
  -w "STATUS=%{http_code}\nTIME=%{time_total}\n" \
  https://objetivo.tld/ruta

    4) OWASP A01: qué probar con curl (y cómo)

    4.1 IDOR (Insecure Direct Object Reference) — cambiar el ID

    Caso típico: /api/users/123 te devuelve tu usuario. ¿Qué pasa con /api/users/124?

    curl -sS -i https://victima.tld/api/users/123
curl -sS -i https://victima.tld/api/users/124

    Qué buscar:

    • Si cambia el contenido y sigue devolviendo 200 OK, mala pinta.
    • Si debería ser 403 Forbidden (autorización) o 404 (no revelar existencia), depende del diseño, pero 200 para todo suele ser alarma.

    4.2 Bypass por método HTTP (GET vs PUT/DELETE)

    Muchas apps protegen el “ver” pero se olvidan del “modificar”.

    # ver
curl -sS -i https://victima.tld/api/orders/55

# intentar modificar
curl -sS -i -X PUT -H "Content-Type: application/json" \
  -d '{"status":"CANCELLED"}' \
  https://victima.tld/api/orders/55

# intentar borrar
curl -sS -i -X DELETE https://victima.tld/api/orders/55

    Señal A01: endpoints sensibles aceptan métodos peligrosos sin chequear rol/propiedad.

    4.3 Acceso a rutas “admin” sin ser admin

    curl -sS -i https://victima.tld/admin
curl -sS -i https://victima.tld/api/admin/users

    4.4 Cambiar rol en el cliente (cabeceras “de pega”)

    Si una app confía en algo como X-Role: admin (error grave), lo detectas así:

    curl -sS -i -H "X-Role: admin" https://victima.tld/api/me

    Nota: Esto no debería funcionar jamás si el backend está bien (el rol debe venir de sesión/token firmado).

    Primero sin login:

    curl -sS -i https://victima.tld/api/profile
~~`

Luego con cookie de sesión (simulando usuario normal):

1) Logueas una vez y guardas cookies:
~~~bash
curl -sS -c cookies.txt -d "user=alumno&pass=1234" https://victima.tld/login
    1. Accedes con cookie:
    curl -sS -b cookies.txt -i https://victima.tld/api/profile
    1. Intentas un endpoint que debería ser solo admin:
    curl -sS -b cookies.txt -i https://victima.tld/api/admin/dashboard

    A01 clásico: usuario normal consigue 200 donde debería ser 403.

    4.6 Tokens Bearer (JWT / API tokens)

    curl -sS -i \
  -H "Authorization: Bearer TU_TOKEN" \
  https://victima.tld/api/orders

    Pruebas A01 típicas:

    • Usar token de usuario A para pedir recursos de usuario B (IDOR).
    • Ver si el backend solo valida “token válido” pero no valida “dueño del recurso”.

    4.7 Enumeración y filtrado: parámetros peligrosos

    Algunos endpoints aceptan filtros como ?userId=...:

    curl -sS -i "https://victima.tld/api/invoices?userId=10"
curl -sS -i "https://victima.tld/api/invoices?userId=11"

    4.8 CORS mal configurado (pista de exposición)

    CORS no es “A01 puro”, pero a veces se mezcla con acceso indebido desde otros orígenes.

    curl -sS -i \
  -H "Origin: https://malicioso.tld" \
  https://victima.tld/api/profile
~~`

Busca en respuesta:
- `Access-Control-Allow-Origin: *` o refleja el Origin sin control
- `Access-Control-Allow-Credentials: true` combinado con cosas raras

### 4.9 OPTIONS y descubrimiento de métodos permitidos
~~~bash
curl -sS -i -X OPTIONS https://victima.tld/api/orders/55

    Mira Allow: o los headers CORS.

    5) Autenticación práctica con curl (cookies, sesiones, CSRF)

    5.1 Mantener sesión con cookies

    # login
curl -sS -c cookies.txt -d "username=alumno&password=1234" https://victima.tld/login

# usar sesión
curl -sS -b cookies.txt -i https://victima.tld/mi-cuenta

    5.2 CSRF token (patrón general)

    Muchas apps: primero GET a formulario para obtener token, luego POST con token + cookie.
    Ejemplo conceptual (depende del sitio):

    # 1) cargar formulario y guardar cookies
curl -sS -c cookies.txt https://victima.tld/form > form.html

# 2) extraer token (si está en HTML; esto es un ejemplo típico)
grep -oP 'name="csrf"\s+value="\K[^"]+' form.html > token.txt

# 3) enviar POST con token + cookie
curl -sS -b cookies.txt -d "csrf=$(cat token.txt)&campo=valor" https://victima.tld/submit

    En A01, CSRF no es el centro, pero aparece en flujos reales al automatizar.

    6) Subidas de archivo y pruebas de acceso (muy común en A01)

    6.1 Subir con multipart

    curl -sS -i \
  -b cookies.txt \
  -F "file=@prueba.txt" \
  https://victima.tld/upload

    6.2 Acceder al archivo de otro usuario

    Si el sistema guarda en /uploads/ID/archivo, prueba el ID (solo en entorno controlado):

    curl -sS -i https://victima.tld/uploads/10/prueba.txt
curl -sS -i https://victima.tld/uploads/11/prueba.txt

    7) Reporting: sacar “pruebas bonitas” para un informe

    7.1 Guardar todo + métricas

    curl -sS -i -L \
  -o respuesta.txt \
  -w "\nSTATUS=%{http_code}\nTIME=%{time_total}\nSIZE=%{size_download}\n" \
  https://victima.tld/api/orders/55

    7.2 Solo el código HTTP (útil para scripts)

    curl -s -o /dev/null -w "%{http_code}\n" https://victima.tld/admin

    7.3 Comparar respuestas rápidamente (cambia ID y mira tamaño)

    curl -s -o /dev/null -w "ID=55 CODE=%{http_code} SIZE=%{size_download}\n" https://victima.tld/api/orders/55
curl -s -o /dev/null -w "ID=56 CODE=%{http_code} SIZE=%{size_download}\n" https://victima.tld/api/orders/56

    Si los tamaños cambian de forma consistente… probablemente estás viendo datos distintos.

    8) Performance y timing (cuando el comportamiento cambia)

    • --max-time 10 corta si tarda más de 10s
    • --connect-timeout 3 timeout de conexión
    • --retry 3 --retry-all-errors reintentos (ojo en auditorías para no “machacar”)
    curl -sS --connect-timeout 3 --max-time 10 https://victima.tld/

    9) “Modo alumno”: 10 comandos que deberían saberse sí o sí

    curl -v https://host/ruta

    curl -I https://host/

    curl -L https://host/ruta

    curl -i https://host/api/recurso

    curl -H "Authorization: Bearer TOKEN" https://host/api

    curl -c cookies.txt -d "u=a&p=b" https://host/login

    curl -b cookies.txt https://host/privado

    curl -X PUT -H "Content-Type: application/json" -d '{"x":1}' https://host/api/x/1

    curl -X DELETE https://host/api/x/1

    curl -s -o /dev/null -w "%{http_code}\n" https://host/admin

    10) Errores típicos (y cómo no volverte loco)

    • 403 vs 401
      • 401 Unauthorized: no autenticado (falta login/token).
      • 403 Forbidden: autenticado pero sin permiso.
      • A01 suele ser “debería ser 403 y me dan 200”.
    • curl “no hace lo mismo que el navegador”
      • El navegador añade cookies, headers, y sigue redirects.
      • Usa -L, y si necesitas replicar, usa -v y añade -H y -b.
    • El endpoint requiere JSON
      • Añade -H "Content-Type: application/json".
    • El servidor redirige a login
      • Mira Location: con -i o sigue con -L.

    11) Tratamiento de sesiones.

    Si una web usa sesión, curl solo verá la respuesta correcta si:

    • primero creas la sesión (login)
    • luego reenvías la cookie de sesión en las peticiones siguientes

    El navegador lo hace solo. curl, no.

    Qué es realmente una sesión (visión backend)

    Cuando haces login:

    1. El servidor valida usuario/contraseña
    2. Crea una sesión en servidor
    3. Envía una cookie al cliente, por ejemplo:
    Set-Cookie: PHPSESSID=abc123; Path=/; HttpOnly

    A partir de ahí:

    • la cookie es tu identidad
    • sin cookie → eres un desconocido

    Paso 1️⃣ – Login y guardar la sesión

    Usamos -c para guardar cookies.

    curl -i \
  -c cookies.txt \
  -d "username=usuario1&password=1234" \
  http://servidor/login.php

    Comprueba el fichero:

    cat cookies.txt

    Verás algo tipo:

    PHPSESSID    abc123

    Eso es tu sesión.

    Paso 2️⃣ – Reutilizar la sesión para ver la respuesta real

    Usamos -b para enviar la cookie.

    curl -i \
  -b cookies.txt \
  http://servidor/api/profile.php

    Ahora verás:

    • la respuesta real
    • no el redirect al login
    • no el “no autorizado”

    📌 Sin -b cookies.txt, curl siempre será anónimo.

    Flujo completo (plantilla mental)

    Siempre que una web use sesión:

    1. curl -c cookies.txt → crear sesión
    2. curl -b cookies.txt → usar sesión
    3. Repetir paso 2 para cada endpoint protegido

    Ver exactamente qué devuelve el servidor

    Para auditoría, conviene ver headers + body:

    curl -i -b cookies.txt http://servidor/api/orders.php

    Si quieres guardar evidencias:

    curl -b cookies.txt \
  -D headers.txt \
  -o body.txt \
  -w "STATUS=%{http_code}\n" \
  http://servidor/api/orders.php

    Caso real típico: “me redirige al login”

    Si haces esto:

    curl http://servidor/api/profile.php

    y ves:

    HTTP/1.1 302 Found
Location: /login.php

    No es que curl “no funcione”:
    es que no llevas la sesión.

    Solución:

    curl -L -b cookies.txt http://servidor/api/profile.php

    ¿Y si el login es JSON (API REST)?

    Muy común en APIs modernas.

    Login:

    curl -c cookies.txt \
  -H "Content-Type: application/json" \
  -d '{"user":"usuario1","pass":"1234"}' \
  http://servidor/api/login

    Acceso protegido:

    curl -b cookies.txt \
  http://servidor/api/orders

    Alternativa: tokens (Bearer)

    Si en vez de sesión usa token:

    curl -H "Authorization: Bearer TOKEN_AQUI" \
  http://servidor/api/orders

    Aquí no hay cookie, el token es la identidad.

    curl no tiene memoria
    si no le pasas la sesión, no eres nadie

    CASO PRACTICO

    Vamos un caso clásico:

    login en PHP con session_start() + usuario y contraseña.
    Sin suposiciones raras, sin frameworks, sin magia.

    Voy a explicarlo como piensa el servidor PHP, que es la clave para que curl tenga sentido.

    Qué hace PHP cuando haces login (lo importante)

    En un login típico en PHP ocurre esto:

    1. session_start();
    2. PHP crea (o reanuda) una sesión
    3. Si el usuario es correcto: $_SESSION['user_id'] = 3; $_SESSION['role'] = 'user';
    4. PHP envía al navegador: Set-Cookie: PHPSESSID=abc123

    📌 Ese PHPSESSID es la identidad real del usuario
    No el usuario, no la contraseña: la cookie.

    Cómo reproducir eso con curl (paso a paso real)

    Hacer login con curl y guardar la sesión

    Supongamos:

    • Login: /login.php
    • Campos POST: username y password

    Comando correcto

    curl -i \
  -c cookies.txt \
  -d "username=usuario1&password=1234" \
  http://servidor/login.php

    Qué hace cada cosa

    • -d → envía el POST (login)
    • -c cookies.txt → guarda la cookie PHPSESSID
    • -i → ves headers (para comprobar que hay Set-Cookie)

    Si todo va bien, verás algo como:

    Set-Cookie: PHPSESSID=abc123; path=/; HttpOnly

    📌 Eso significa: sesión creada correctamente

    cat cookies.txt

    Contenido típico:

    # Netscape HTTP Cookie File
servidor   FALSE   /   FALSE   0   PHPSESSID   abc123

    Esto es la sesión PHP.

    Acceder a una página protegida usando la sesión

    Ahora reenvías la cookie:

    curl -i \
  -b cookies.txt \
  http://servidor/privado.php

    Si el login fue correcto:

    • verás el contenido real
    • no redirige a /login.php
    • no dice “no autorizado”

    Cada vez que vean PHP + sesión:

    1. curl -c cookies.txt → crear sesión
    2. curl -b cookies.txt → usar sesión
    3. Repetir paso 2 tantas veces como haga falta

    CASO REAL: “me redirige al login”

    Si haces:

    curl http://servidor/privado.php

    y ves:

    HTTP/1.1 302 Found
Location: login.php

    👉 No es un error
    👉 Es que no llevas la sesión

    Solución:

    curl -L -b cookies.txt http://servidor/privado.php

    SIMULAR DOS USUARIOS DISTINTOS (muy A01)

    Usuario normal

    curl -c cookies_user.txt \
  -d "username=user&password=1234" \
  http://servidor/login.php

    Admin

    curl -c cookies_admin.txt \
  -d "username=admin&password=admin123" \
  http://servidor/login.php

    Comparar accesos

    curl -b cookies_user.txt  http://servidor/admin.php
curl -b cookies_admin.txt http://servidor/admin.php

    📌 Si ambos ven lo mismo → Broken Access Control

    PROBAR IDOR CON SESIÓN REAL

    curl -b cookies_user.txt \
  "http://servidor/order.php?id=1"

curl -b cookies_user.txt \
  "http://servidor/order.php?id=2"

    Si cambia el contenido → IDOR confirmado

    GUARDAR EVIDENCIA (modo auditor)

    curl -b cookies_user.txt \
  -D headers.txt \
  -o body.txt \
  -w "STATUS=%{http_code}\n" \
  http://servidor/order.php?id=2

    Eso es evidencia técnica válida.

  • 1.3.1 [Reto] – curl como herramienta de auditoría

    1.3.1 [Reto] – curl como herramienta de auditoría

    Tu equipo ha sido contratado para auditar el control de acceso de una aplicación web interna.
    La aplicación funciona correctamente “a simple vista”, pero la empresa sospecha que usuarios autenticados podrían acceder a recursos que no les pertenecen.

    Tu misión no es romper nada, sino demostrar con evidencias técnicas si los controles de acceso están bien implementados… o no.

    Objetivos del proyecto

    Al finalizar la práctica, el alumno será capaz de:

    • Comprender OWASP Top 10 – A01: Broken Access Control
    • Usar curl como herramienta de auditoría (no como navegador)
    • Simular usuarios, sesiones y roles
    • Detectar fallos de:
      • IDOR
      • Falta de autorización
      • Bypass por método HTTP
      • Acceso a rutas protegidas
    • Generar evidencias reproducibles para un informe técnico

    Escenario

    Infraestructura

    • Servidor: Apache + PHP (o similar)
    • Base de datos: MySQL / MariaDB
    • Aplicación web con:
      • Login y sesión
      • CRUD de “Pedidos” o “Reservas”
      • Dos roles:
        • usuario
        • admin

    Endpoints de ejemplo

    (ajústalos a tu app con otros nombres)

    FunciónEndpoint
    Login/login.php
    Perfil usuario/api/profile.php
    Listar pedidos/api/orders.php
    Ver pedido/api/order.php?id=ID
    Modificar pedido/api/order.php?id=ID (PUT)
    Borrar pedido/api/order.php?id=ID (DELETE)
    Panel admin/admin/dashboard.php

    Preparación del entorno

    Comprobar curl

    curl --version

    Crear carpeta de trabajo

    mkdir auditoria_a01
cd auditoria_a01

    Reconocimiento pasivo (sin login)

    Acceso a recursos protegidos sin autenticar

    curl -i http://servidor/api/orders.php

    Anota:

    • Código HTTP
    • ¿Redirige a login?
    • ¿Devuelve datos?

    📌 Si devuelve datos → indicio crítico de A01.

    Intento directo a panel admin

    curl -i http://servidor/admin/dashboard.php

    Resultado esperado:

    • 401 o redirección a login
      Resultado peligroso:
    • 200 OK

    Autenticación y gestión de sesión

    Login como usuario normal

    curl -c cookies_user.txt \
     -d "username=usuario1&password=1234" \
     http://servidor/login.php

    Comprueba que se crea cookies_user.txt.

    Acceso autenticado

    curl -b cookies_user.txt -i http://servidor/api/profile.php

    OWASP A01 en acción (Broken Access Control)

    IDOR – Acceso a pedidos de otros usuarios

    Pedido propio

    curl -b cookies_user.txt -i \
"http://servidor/api/order.php?id=1"

    Pedido ajeno

    curl -b cookies_user.txt -i \
"http://servidor/api/order.php?id=2"

    Vulnerabilidad A01 si:

    • Ambos devuelven 200 OK
    • Se muestran datos de otro usuario

    Enumeración automática de IDs

    for i in 1 2 3 4 5; do
  curl -s -o /dev/null \
  -w "ID=$i STATUS=%{http_code} SIZE=%{size_download}\n" \
  -b cookies_user.txt \
  "http://servidor/api/order.php?id=$i"
done

    Patrón típico A01:

    • Todos los IDs responden con 200
    • Tamaños distintos → datos distintos

    Bypass por método HTTP (PUT / DELETE)

    Intento de modificación

    curl -X PUT \
  -H "Content-Type: application/json" \
  -d '{"status":"CANCELLED"}' \
  -b cookies_user.txt \
  -i \
  "http://servidor/api/order.php?id=2"

    Intento de borrado

    curl -X DELETE \
  -b cookies_user.txt \
  -i \
  "http://servidor/api/order.php?id=2"

    📌 A01 crítico si:

    • Usuario normal puede modificar/borrar pedidos ajenos

    Acceso a funciones admin con usuario normal

    curl -b cookies_user.txt -i \
http://servidor/admin/dashboard.php

    Resultado correcto:

    • 403 Forbidden
      Resultado vulnerable:
    • 200 OK

    Headers manipulables (prueba de confianza indebida)

    curl -b cookies_user.txt \
  -H "X-Role: admin" \
  -i \
  http://servidor/api/profile.php

    📌 Si el rol cambia → fallo grave de diseño.

    Evidencias para informe

    Guardar headers y cuerpo

    curl -b cookies_user.txt \
  -D evidencia_headers.txt \
  -o evidencia_body.txt \
  -w "STATUS=%{http_code}\nTIME=%{time_total}\n" \
  "http://servidor/api/order.php?id=2"

    Evidencia mínima reproducible

    curl -s -o /dev/null \
  -w "STATUS=%{http_code}\n" \
  -b cookies_user.txt \
  "http://servidor/api/order.php?id=2"

    Esto es oro puro para un informe técnico.

  • 1.4 – Ética, legalidad y límites reales en ciberseguridad

    1.4 – Ética, legalidad y límites reales en ciberseguridad

    En ciberseguridad existe una tentación muy común cuando se empieza:

    “Solo voy a probar un poco, no voy a romper nada”.

    Herramientas como curl, Postman, Burp o simples peticiones HTTP hacen que testear una web parezca trivial. Sin embargo, aquí aparece una de las lecciones más importantes de toda la profesión:

    👉 Que algo sea técnicamente posible no significa que sea legal.

    La regla de oro de la ciberseguridad

    Nunca pruebes la seguridad de un sistema que no es tuyo sin autorización explícita.

    No importa:

    • que sea “solo por aprender”
    • que no haya daño
    • que no se roben datos
    • que el fallo sea evidente
    • que la petición sea un simple GET

    📌 La legalidad no depende de la herramienta ni de la intención, depende del permiso.

    No es legal que un estudiante (ni un profesional) pruebe vulnerabilidades en:

    • Páginas web “random” de Internet
    • APIs públicas que no son suyas
    • Paneles /admin, /api/users, /orders?id=2 de terceros
    • Aplicaciones reales sin consentimiento del propietario

    Aunque:

    • solo se cambie un ID
    • solo se mire la respuesta
    • no se modifique nada
    • no se guarde información

    📌 Acceder a recursos que no te corresponden ya es un problema legal, aunque el servidor “te deje”.

    El error mental más común

    “Pero solo hice una petición HTTP…”

    Un error muy habitual es pensar que:

    • GET = legal
    • POST / PUT / DELETE = ilegal

    Esto es falso.

    La ley no distingue métodos HTTP, distingue:

    • quién es el dueño del sistema
    • si tienes autorización
    • si accedes a información o funciones fuera de tu rol

    Un solo GET a un recurso privado puede ser ilegal.
    Un DELETE en un entorno autorizado puede ser perfectamente legal.

    ¿Qué dice la ley?

    En España y la Unión Europea, probar sistemas ajenos sin permiso puede encajar en:

    • Acceso no autorizado a sistemas informáticos
    • Interferencia en sistemas de información
    • Tratamiento ilícito de datos personales (si hay datos reales)

    Esto se aplica aunque no haya daño, porque el delito no es “romper”, es acceder sin derecho.

    Hay escenarios completamente válidos y profesionales:

    ✔️ Sistemas propios

    • Servidores propios
    • Máquinas virtuales
    • Docker
    • Laboratorios locales
    • Infraestructura del centro educativo

    ✔️ Laboratorios diseñados para ser atacados

    Plataformas educativas y entornos vulnerables creados expresamente para practicar.

    Aquí hay algo clave:
    consentimiento explícito.

    ✔️ Bug Bounty (con reglas muy claras)

    Algunas empresas permiten pruebas, pero:

    • solo ciertos dominios
    • solo ciertos tipos de ataques
    • con límites muy estrictos

    No es recomendable como punto de partida para estudiantes.

    ✔️ Autorización escrita

    Un correo, contrato o documento que indique:

    • qué se puede probar
    • hasta dónde
    • en qué condiciones

    Esto es lo que separa a un auditor profesional de un aficionado imprudente.

    La ciberseguridad no va de ser más listo que el sistema, va de ser responsable con el conocimiento.

    Un buen profesional no es quien encuentra más vulnerabilidades,
    sino quien sabe cuándo tiene derecho a buscarlas.

    La ética no es “relleno académico”:
    es una competencia técnica tan importante como saber usar una herramienta.

  • 2.1 – A02: Cryptographic Failures: cuando la criptografía falla, todo falla

    2.1 – A02: Cryptographic Failures: cuando la criptografía falla, todo falla

    En seguridad informática hay una idea peligrosa que aparece una y otra vez: “uso HTTPS, así que mis datos están seguros”. Esta frase, tan común como incorrecta, es la puerta de entrada perfecta al OWASP Top 10 – A02: Cryptographic Failures.

    Este punto no habla de ataques sofisticados ni de hackers con sudaderas negras. Habla de algo mucho más cotidiano —y mucho más grave—: usar mal la criptografía o no usarla cuando es necesaria.

    De “exposición de datos” a “fallos criptográficos”

    En ediciones anteriores del OWASP Top 10, este riesgo se conocía como Sensitive Data Exposure. El cambio de nombre a Cryptographic Failures no es un simple ajuste semántico. Es una declaración de intenciones.

    El problema real no es que los datos se expongan “por accidente”, sino que:

    • Se almacenan sin protección
    • Se cifran con algoritmos obsoletos
    • Se gestionan claves de forma negligente
    • Se confía en mecanismos que no ofrecen seguridad real

    Cuando la criptografía falla, la aplicación puede funcionar perfectamente… mientras los datos quedan totalmente expuestos.

    Qué es realmente un fallo criptográfico

    Un fallo criptográfico no significa que el algoritmo sea débil. En la mayoría de los casos, los algoritmos funcionan exactamente como fueron diseñados. El problema está en cómo los usamos.

    Algunos ejemplos habituales:

    • Guardar contraseñas en texto plano
    • Cifrar contraseñas en lugar de hashearlas
    • Usar MD5 o SHA-1 porque “siempre se ha hecho así”
    • Reutilizar claves en distintos sistemas
    • Incluir secretos directamente en el código fuente
    • Pensar que Base64 es cifrado

    La criptografía no perdona errores conceptuales. Si se aplica mal, la seguridad es una ilusión.

    Cifrado, hashing y codificación: la confusión clásica

    Uno de los orígenes más comunes de A02 es no distinguir correctamente entre tres conceptos fundamentales:

    Cifrado Es un proceso reversible. Sirve para proteger datos que más adelante deben recuperarse, como información personal o datos almacenados.

    Hashing Es un proceso irreversible. Está pensado para verificar, no para recuperar. Por eso es la técnica correcta para almacenar contraseñas.

    Codificación No es un mecanismo de seguridad. Base64, por ejemplo, solo transforma datos para facilitar su transporte. Cualquiera puede revertirlo.

    Cuando una aplicación mezcla estos conceptos, el resultado suele ser desastroso.

    Contraseñas: el punto más frágil del sistema

    Las contraseñas merecen un capítulo propio dentro de A02. No porque sean un mecanismo perfecto, sino porque siguen siendo el más usado.

    Errores críticos que todavía se ven en producción:

    • Contraseñas almacenadas en texto plano
    • Contraseñas cifradas con clave reversible
    • Hashes rápidos sin salt

    La práctica correcta implica:

    • Algoritmos diseñados específicamente para contraseñas
    • Uso de salt único por usuario
    • Coste computacional suficiente para frenar ataques de fuerza bruta

    Aquí no hay atajos. Si las contraseñas se gestionan mal, todo el sistema cae detrás.

    HTTPS no lo soluciona todo

    HTTPS protege los datos en tránsito, pero no garantiza que:

    • Se usen versiones seguras de TLS
    • Las cookies estén correctamente configuradas
    • No haya contenido mixto
    • Los datos se almacenen de forma segura en el servidor

    Es posible tener un candado verde en el navegador y, aun así, estar filtrando información sensible sin darse cuenta.

    HTTPS es una condición necesaria, pero nunca suficiente.

    Tokens, sesiones y APIs modernas

    Las aplicaciones actuales dependen cada vez más de APIs y tokens de autenticación. Y aquí aparecen nuevos fallos criptográficos:

    • Tokens predecibles
    • JWT sin firma o mal configurados
    • Tokens expuestos en URLs
    • Almacenamiento inseguro en el cliente

    Muchos de estos errores no rompen la funcionalidad, pero sí la seguridad. El sistema “funciona”, hasta que alguien decide mirarlo con mentalidad de auditor.

    Datos sensibles: no todo vale lo mismo

    Uno de los errores de diseño más comunes es no clasificar los datos.

    No toda la información requiere el mismo nivel de protección, pero hay datos que nunca deberían almacenarse sin medidas criptográficas adecuadas, como:

    • Credenciales
    • Identificadores personales
    • Tokens de acceso
    • Información financiera

    A esto se suman los grandes olvidados: backups, logs y ficheros temporales, que a menudo contienen más información sensible que la propia base de datos principal.

    Pensar como auditor: detectar A02

    Detectar fallos criptográficos no siempre requiere herramientas avanzadas. Muchas veces basta con observar:

    • Cómo se gestionan las contraseñas
    • Qué información aparece en cookies y cabeceras
    • Qué algoritmos se usan realmente
    • Dónde se almacenan los secretos

    La automatización ayuda, pero el criterio humano es insustituible. Un escáner puede avisar; un profesional entiende el impacto.

    Buenas prácticas: menos magia, más criterio

    La criptografía segura no consiste en usar lo último, sino en usar lo adecuado:

    • Algoritmos actuales y bien mantenidos
    • Gestión centralizada de secretos
    • Separación de responsabilidades
    • Decisiones documentadas

    La seguridad madura no se basa en trucos, sino en disciplina técnica.

    Conclusión

    OWASP A02 no trata de romper sistemas. Trata de recordar algo esencial: los datos tienen valor, y protegerlos es una responsabilidad técnica y ética.

    La mayoría de los fallos criptográficos no ocurren por falta de herramientas, sino por falta de comprensión. Por eso este punto es clave en cualquier formación técnica: obliga a pensar, a cuestionar y a asumir que la seguridad no es un añadido, sino parte del diseño.

    Cuando la criptografía falla, no hay parche que lo arregle después. Solo queda aprender… y hacerlo mejor la próxima vez.

  • 2.1.1 – Cifrado Simétrico con Clave Compartida

    2.1.1 – Cifrado Simétrico con Clave Compartida

    Qué es el Cifrado Simétrico

    El cifrado simétrico utiliza una única clave secreta para dos operaciones:

    • Cifrar (convertir texto legible en ilegible)
    • Descifrar (recuperar el texto original)

    Si dos personas comparten la misma clave, ambas pueden leer el mensaje.
    Si un atacante consigue la clave, el cifrado deja de proteger.

    Conceptos esenciales:

    • Texto plano: información legible.
    • Texto cifrado: datos transformados matemáticamente.
    • Clave: secreto que controla la transformación.
    • Algoritmo: función matemática que aplica el cifrado.

    El cifrado simétrico es muy rápido, por eso se usa en:

    • HTTPS / TLS (Internet)
    • Discos cifrados (BitLocker, LUKS)
    • VPN
    • Bases de datos
    • WiFi WPA2/WPA3

    El problema central no es el algoritmo.
    El problema siempre es: cómo compartes la clave sin que te la roben.

    Resultado esperado

    El alumno puede explicar:

    • Qué es una clave simétrica
    • Qué ocurre si se pierde
    • Por qué el cifrado depende del secreto

    ────────────────────────────────

    Tipos de Cifrado Simétrico

    1. Cifradores de Bloque

    Trabajan sobre bloques fijos de datos (por ejemplo 128 bits).

    Ejemplos:

    • AES (estándar actual)
    • DES (obsoleto)
    • 3DES (en retirada)
    • Blowfish
    • Twofish

    2. Cifradores de Flujo

    Cifran byte a byte como un flujo continuo.

    Ejemplos:

    • RC4 (inseguro, obsoleto)
    • ChaCha20 (moderno, muy rápido)

    3. Modos de Operación (muy importante)

    Un cifrador de bloque necesita un modo:

    • ECB → inseguro (filtra patrones)
    • CBC → clásico, seguro si se usa bien
    • CFB / OFB → variantes de flujo
    • CTR → moderno
    • GCM → autenticado (integridad + cifrado)

    AES + GCM es el estándar moderno (TLS 1.3).

    ────────────────────────────────

    Preparación del Entorno

    Requisitos:

    • Linux / macOS / WSL
    • OpenSSL
    • Terminal

    Acción

    openssl version

    Si aparece una versión → listo.

    ────────────────────────────────

    Crear un Archivo en Texto Plano

    echo"Las credenciales del sistema son supersecretas." > secreto.txtcat secreto.txt

    Explicación

    Este archivo representa:

    • contraseñas
    • tokens
    • datos personales
    • secretos de API

    Ahora mismo es completamente vulnerable.

    ────────────────────────────────

    La Clave Simétrica

    Explicación ampliada

    Una clave débil rompe todo el sistema.
    Ejemplo de malas claves:

    • 123456
    • password
    • admin2026

    Buenas claves:

    • largas
    • aleatorias
    • no reutilizadas

    Generar clave fuerte

    openssl rand -base6432

    Esto genera una clave criptográficamente segura.

    ────────────────────────────────

    Cifrado con AES-256-CBC

    openssl enc -aes-256-cbc-salt-in secreto.txt -out secreto.enc

    El sistema pedirá contraseña.

    Qué significa cada parámetro

    • aes-256 → clave de 256 bits
    • cbc → modo de bloque
    • salt → evita ataques de diccionario
    • in → archivo original
    • out → archivo cifrado

    Resultado

    cat secreto.enc

    Contenido ilegible → cifrado correcto.

    ────────────────────────────────

    Qué ocurre sin la clave correcta

    openssl enc -aes-256-cbc-d-in secreto.enc

    Resultado:

    • error
    • texto corrupto

    Explicación

    El cifrado moderno no puede romperse sin la clave.
    No existe “probar hasta acertar” en tiempo humano si la clave es fuerte.

    ────────────────────────────────

    Descifrado correcto

    openssl enc -aes-256-cbc -d -in secreto.enc -out secreto_descifrado.txt
diff secreto.txt secreto_descifrado.txt

    Sin diferencias → integridad correcta.

    ────────────────────────────────

    AES-GCM (Cifrado Autenticado)

    CBC cifra, pero no protege contra manipulación.
    GCM cifra y detecta modificaciones.

    openssl enc -aes-256-gcm-salt-in secreto.txt -out secreto_gcm.enc

    Si alguien modifica el archivo → el descifrado falla.

    Este es el modo usado en:

    • TLS 1.3
    • HTTPS moderno
    • VPN modernas

    ────────────────────────────────

    TEMA 10 — Comparación de Algoritmos

    AlgoritmoEstadoUso
    DESRotoHistórico
    3DESEn retiradaSistemas legacy
    AESEstándarUniversal
    ChaCha20ModernoTLS móvil, Wireguard
    BlowfishAntiguoPoco usado

    Mensaje clave: AES y ChaCha20 dominan el mundo real.

    ────────────────────────────────

    El Problema del Intercambio de Claves

    Para descifrar necesitas:

    1. Archivo cifrado
    2. Clave secreta

    Si envías ambos por el mismo canal → seguridad = 0

    Por eso el mundo real usa:

    • Criptografía asimétrica
    • Intercambio Diffie-Hellman
    • TLS

    El cifrado simétrico siempre vive acompañado del asimétrico.

    ────────────────────────────────

    OWASP A02: Fallos Criptográficos

    Errores comunes reales:

    • Guardar datos sin cifrar
    • Usar ECB
    • Claves en el código
    • Claves débiles
    • Reutilizar claves
    • No usar cifrado autenticado
    • No cifrar en tránsito

    El cifrado no falla por matemáticas.
    Falla por humanos.

    ────────────────────────────────

    Para probar:

    Ver algoritmos disponibles

    openssl enc -ciphers

    Ver cabecera binaria

    xxd secreto.enc | head

  • 2.1.2 – [Reto] PROTOCOLO DE SEGURIDAD DE LA FEDERACIÓN

    2.1.2 – [Reto] PROTOCOLO DE SEGURIDAD DE LA FEDERACIÓN

    Academia de la Flota Estelar — División de Seguridad Informática
    Nivel: Cadete Técnico
    Sistema: USS Horizon
    Estado de la misión: ACTIVA

    Año estelar 78241.7

    La USS Horizon ha detectado interceptaciones de comunicaciones por parte de una facción hostil. El Comando de Seguridad ordena activar cifrado simétrico de grado Federación para proteger:

    • Credenciales del sistema
    • Comunicaciones internas
    • Datos de navegación
    • Protocolos de defensa

    Tu misión como oficial técnico es implementar cifrado AES-256 y validar la seguridad del sistema.

    OBJETIVOS DE LA MISIÓN

    El cadete será capaz de:

    • Comprender el cifrado simétrico
    • Generar claves seguras
    • Cifrar información sensible
    • Verificar resistencia ante ataques
    • Usar AES correctamente
    • Entender el problema del intercambio de claves
    • Aplicar cifrado autenticado moderno (GCM)

    FASE 1 — COMPRENDER LA AMENAZA

    Informe del Comando

    Las transmisiones sin cifrar pueden ser interceptadas mediante sondas de escucha.
    Cualquier mensaje en texto plano es vulnerable.

    Conceptos clave

    • Texto plano → mensaje legible
    • Texto cifrado → mensaje ilegible
    • Clave → secreto que controla el cifrado
    • Algoritmo → transformación matemática

    El cifrado simétrico usa una única clave compartida.

    Si el enemigo obtiene la clave → seguridad comprometida.

    FASE 2 — PREPARAR EL SISTEMA

    Verificar módulo criptográfico OpenSSL.

    openssl version

    Si responde con versión → módulo activo.

    FASE 3 — CREAR MENSAJE SENSIBLE

    Simular credenciales del sistema de la nave.

    echo "Credenciales núcleo warp: acceso nivel comandante." > mensaje.txt
cat mensaje.txt

    Observación: mensaje totalmente legible → inseguro.

    FASE 4 — GENERAR CLAVE SEGURA

    Las claves débiles destruyen la seguridad.
    La Flota exige entropía alta.

    Generar clave criptográfica:

    openssl rand -base64 32

    Guardar la clave en gestor seguro (NO en el archivo).

    FASE 5 — CIFRADO AES-256-CBC

    Activar cifrado simétrico estándar de la Federación.

    openssl enc -aes-256-cbc -salt -in mensaje.txt -out mensaje.enc

    Introducir clave cuando se solicite.

    Verificar resultado:

    cat mensaje.enc

    Resultado esperado: datos ilegibles → cifrado activo.

    FASE 6 — INTERCEPCIÓN ENEMIGA

    Simular intento de descifrado sin clave correcta.

    openssl enc -aes-256-cbc -d -in mensaje.enc

    Resultado:

    • Error de descifrado
    • Texto corrupto

    Conclusión: sin clave → imposible recuperar datos.

    FASE 7 — DESCIFRADO AUTORIZADO

    Recuperar mensaje con clave correcta.

    openssl enc -aes-256-cbc -d -in mensaje.enc -out mensaje_recuperado.txt
diff mensaje.txt mensaje_recuperado.txt

    Resultado: archivos idénticos → integridad confirmada.

    FASE 8 — CIFRADO MODERNO (AES-GCM)

    El modo CBC cifra pero no detecta manipulación.
    El Comando exige cifrado autenticado.

    openssl enc -aes-256-gcm -salt -in mensaje.txt -out mensaje_gcm.enc

    Si el archivo es alterado → el descifrado fallará.

    Este modo protege:

    • Confidencialidad
    • Integridad
    • Autenticidad

    FASE 9 — ANÁLISIS TÉCNICO

    Tipos de cifrado simétrico

    Cifradores de bloque

    • AES (estándar Federación)
    • DES (obsoleto)
    • 3DES (retirada progresiva)

    Cifradores de flujo

    • ChaCha20 (uso en comunicaciones rápidas)
    • RC4 (inseguro, prohibido)

    Modos de operación

    • ECB → inseguro (filtra patrones)
    • CBC → clásico
    • CTR → moderno
    • GCM → cifrado autenticado (recomendado)

    FASE 10 — EL TALÓN DE AQUILES

    Para descifrar se necesitan:

    1. Archivo cifrado
    2. Clave secreta

    Problema crítico: ¿cómo compartir la clave sin ser interceptada?

    La Flota resuelve esto con:

    • Criptografía asimétrica
    • Intercambio Diffie-Hellman
    • Protocolos TLS

    El cifrado simétrico nunca viaja solo.

    FASE 11 — ERRORES CRÍTICOS (INFORME OWASP)

    Fallos detectados en sistemas comprometidos:

    • Datos sin cifrar
    • Uso de ECB
    • Claves en código fuente
    • Claves débiles
    • Reutilización de claves
    • No usar cifrado autenticado
    • Envío de claves por canales inseguros

    La criptografía no falla por matemáticas.
    Falla por mala ingeniería.

    FASE 12 — EXPERIMENTOS OPCIONALES

    Ver algoritmos disponibles:

    openssl enc -ciphers

    Inspeccionar binario cifrado:

    xxd mensaje.enc | head

    INFORME FINAL DE MISIÓN

    El cadete ha:

    • Aplicado cifrado simétrico real
    • Usado AES correctamente
    • Comprobado resistencia sin clave
    • Entendido intercambio de claves
    • Diferenciado CBC vs GCM
    • Identificado errores criptográficos reales

    La frontera entre matemática y seguridad… apenas comienza.

  • 2.1.3 – [Reto] Cifrado Asimétrico con Clave Pública y Privada

    2.1.3 – [Reto] Cifrado Asimétrico con Clave Pública y Privada

    La criptografía asimétrica es uno de esos inventos humanos que parecen ciencia ficción pero sostienen la realidad cotidiana. Cada vez que abres una web HTTPS, envías un mensaje seguro, firmas un documento digital o te conectas por SSH, estás usando matemáticas diseñadas para resolver un problema aparentemente imposible: compartir secretos sin compartir el secreto.

    En el cifrado simétrico ya viste que dos partes pueden proteger información usando una misma clave. Rápido, eficaz… pero con un punto débil crítico: ¿cómo intercambias esa clave sin que alguien la intercepte? Aquí entra la criptografía de clave pública, una idea brillante basada en funciones matemáticas fáciles de calcular pero extremadamente difíciles de invertir. Gracias a ello, cada entidad puede tener dos claves: una pública que puede compartir con el mundo y una privada que jamás debe revelar. Lo que una cifra, solo la otra puede descifrar; lo que una firma, la otra puede verificar.

    Este modelo no solo permite cifrar mensajes. Permite algo mucho más profundo: crear confianza en sistemas donde las partes no se conocen previamente. De aquí nacen las firmas digitales, los certificados, las autoridades de certificación y, en última instancia, el funcionamiento seguro de Internet mediante TLS. Sin criptografía asimétrica no existirían el comercio electrónico, la identidad digital, ni la mayoría de servicios que hoy consideramos normales.

    En este tema no solo aprenderás comandos. Comprenderás cómo se construye un canal seguro desde cero: cómo se generan identidades criptográficas, cómo se cifra para un destinatario concreto, cómo se garantiza que un mensaje no ha sido alterado, y cómo una infraestructura de certificados permite confiar en claves públicas desconocidas. Es el paso donde la seguridad deja de ser “ocultar datos” y se convierte en demostrar identidad, integridad y autenticidad en un entorno hostil.

    Limitación del cifrado simétrico:

    • Necesita compartir clave secreta
    • Si se intercepta → seguridad rota

    Problema fundamental:

    ¿Cómo compartir un secreto sin compartirlo?

    Solución matemática:
    Criptografía de clave pública

    Cada usuario posee:

    • Clave pública → se puede compartir
    • Clave privada → nunca se revela

    Lo cifrado con una solo puede descifrarse con la otra.

    Resultado esperado:
    El alumno comprende la diferencia simétrico vs asimétrico.

    Conceptos Fundamentales

    Conceptos clave:

    • Par de claves (Key Pair)
    • Clave pública
    • Clave privada
    • Cifrado
    • Descifrado
    • Firma digital
    • Verificación
    • No repudio
    • Confianza
    • Certificados

    Idea central:
    La clave pública cifra o verifica
    La clave privada descifra o firma

    Fundamento Matemático (Nivel Conceptual)

    La criptografía asimétrica usa funciones:

    • Fáciles de calcular
    • Extremadamente difíciles de invertir

    Ejemplo conceptual:

    Multiplicar primos grandes → fácil
    Factorizar resultado → extremadamente difícil

    Este principio sostiene:

    • RSA
    • Diffie-Hellman
    • ECC

    Algoritmos Asimétricos Principales

    RSA

    Basado en factorización de números grandes.
    Usado para:

    • Cifrado
    • Firma digital
    • TLS clásico

    Diffie-Hellman

    Permite generar una clave compartida sin enviarla.
    Base del intercambio seguro.

    ECC (Elliptic Curve Cryptography)

    Versión moderna y eficiente.
    Usada en:

    • TLS moderno
    • Blockchain
    • SSH moderno
    • Certificados

    Resultado esperado:
    El alumno distingue funciones de cada algoritmo.

    Generación de Claves (Práctica)

    Objetivo: crear identidad criptográfica.

    Ejemplo:

    openssl genrsa -out privada.pem 2048
openssl rsa -in privada.pem -pubout -out publica.pem

    Conceptos enseñados:

    • Tamaño de clave
    • Seguridad vs rendimiento
    • Protección de clave privada

    Cifrado con Clave Pública

    Escenario:

    Alice quiere enviar mensaje seguro a Bob.

    Proceso:

    1. Bob genera claves
    2. Bob comparte clave pública
    3. Alice cifra con clave pública de Bob
    4. Solo Bob puede descifrar

    Concepto:
    Cualquiera puede cifrar, solo el dueño puede leer

    Firma Digital

    Proceso:

    1. Emisor firma con su clave privada
    2. Receptor verifica con clave pública

    Garantiza:

    • Autoría
    • Integridad
    • No repudio

    Uso real:

    • Software firmado
    • Certificados
    • Emails seguros
    • Blockchain
    • Documentos legales

    Intercambio de Claves Seguro (Diffie-Hellman)

    El mayor avance criptográfico.

    Permite:

    • Generar clave simétrica
    • Sin transmitirla
    • Incluso con atacante escuchando

    Esto es lo que hace TLS.

    Concepto clave:
    El asimétrico no cifra grandes datos, crea la clave simétrica.

    Criptografía Híbrida (Cómo funciona TLS)

    En el mundo real:

    1. Asimétrico → intercambia clave
    2. Simétrico → cifra datos (rápido)

    Esto es:

    • HTTPS
    • VPN
    • SSH
    • TLS
    • Internet seguro

    Certificados Digitales

    Problema:

    ¿Cómo sé que una clave pública es auténtica?

    Solución:

    Autoridades de Certificación (CA)

    Un certificado vincula:

    • Identidad
    • Clave pública
    • Firma de una CA

    Conceptos:

    • X.509
    • Cadena de confianza
    • Root CA
    • Certificado autofirmado
    • Validación

    Ataques contra Criptografía Asimétrica

    • Robo de clave privada
    • MITM
    • Certificados falsos
    • Claves débiles
    • Mala implementación
    • RNG débil
    • Padding attacks (conceptual)

    Mensaje:
    La criptografía no falla por matemáticas → falla por humanos.

    OWASP y Criptografía

    Relación directa con:

    OWASP A02 — Cryptographic Failures

    Errores reales:

    • Claves expuestas
    • Sin validación de certificados
    • Uso de RSA débil
    • Sin forward secrecy
    • Mala generación de claves

    Recomendaciones

    • Generar par de claves
    • Cifrar mensaje con clave pública
    • Firmar archivo
    • Verificar firma
    • Crear certificado autofirmado
    • Simular TLS
    • MITM conceptual
    • Ver handshake TLS con Wireshark

    Conexión con el Mundo Real

    Esto protege:

    • HTTPS
    • SSH
    • VPN
    • Git firmado
    • Docker firmado
    • Identidad digital
    • Blockchain
    • Infraestructura crítica

    Sin criptografía asimétrica → Internet no existiría.

    Comparativa — Clave Simétrica vs Clave Asimétrica

    PropiedadCriptografía SimétricaCriptografía Asimétrica
    Nº de clavesUna sola clave secreta compartidaDos claves: pública y privada
    Distribución de clavesProblema crítico (debe compartirse en secreto)La pública se puede compartir libremente
    VelocidadMuy rápida (apta para grandes volúmenes de datos)Mucho más lenta
    Uso principalCifrado de datosIntercambio de claves, firma digital, autenticación
    Seguridad depende deMantener la clave secretaProteger la clave privada
    Tamaño de clave típico128 / 192 / 256 bits (AES)2048+ bits RSA / 256 bits ECC
    Cifrado de grandes datosExcelenteIneficiente
    Integridad / autenticidadNecesita mecanismos extra (HMAC, GCM)Incluido mediante firma digital
    No repudioNoSí (firma digital)
    Complejidad matemáticaModeradaAlta
    Resistencia si interceptan el mensajeSegura si no tienen la claveSegura si no tienen la privada
    Ejemplos de algoritmosAES, ChaCha20, BlowfishRSA, ECC, Diffie-Hellman
    Uso en el mundo realDiscos cifrados, VPN, WiFi, bases de datosTLS, certificados, firmas, SSH
    Papel en TLS/HTTPSCifra el tráficoIntercambia la clave simétrica
    Escalabilidad (muchos usuarios)Mala (cada pareja necesita clave distinta)Buena (cada usuario tiene su par de claves)
    Si roban la clavePueden leer todoSolo compromete esa identidad
    Caso de uso idealProteger datos rápidamenteEstablecer confianza entre desconocidos

    TLS = combinación de ambas (criptografía híbrida)

    Simétrica = rapidez para proteger datos

    Asimétrica = confianza e identidad

    MISIÓN DE LA FLOTA ESTELAR

    CANAL SEGURO — CRIPTOGRAFÍA ASIMÉTRICA + FIRMA + CERTIFICADOS (OpenSSL)

    Unidad: USS Horizon — División de Comunicaciones Seguras
    Nivel: Cadete Técnico
    Objetivo general: establecer un canal de comunicación confiable usando clave pública/privada, firma digital, y certificado.

    PARTE 1 — “IDENTIDAD CRIPTOGRÁFICA” (Par de claves)

    FASE 1 — Crear carpeta de misión

    mkdir-p mision_canal_seguro && cd mision_canal_seguro

    FASE 2 — Generar clave privada del oficial Bob (2048 bits)

    Narrativa: Bob es el oficial de comunicaciones. Su clave privada es el “código genético” de su identidad.

    openssl genrsa -out bob_privada.pem 2048

    Comprobación rápida (sin mostrarla entera):

    openssl rsa -in bob_privada.pem -check-noout

    FASE 3 — Obtener la clave pública de Bob

    Narrativa: esta es la clave que Bob puede compartir con toda la Flota.

    openssl rsa -in bob_privada.pem -pubout-out bob_publica.pem

    Verla en modo humano:

    openssl rsa -pubin-in bob_publica.pem -text-noout

    ✅ Resultado esperado: los alumnos ven que la pública se puede inspeccionar sin revelar la privada.

    PARTE 2 — “CIFRADO CON CLAVE PÚBLICA” (Confidencialidad)

    FASE 4 — Crear mensaje secreto de Alice

    echo "Coordenadas del punto de encuentro: Sector 7G. Acceso nivel Alfa." > mensaje_alice.txt
cat mensaje_alice.txt

    FASE 5 — Cifrar para Bob usando su clave pública

    IMPORTANTE (realidad): RSA no se usa para cifrar grandes datos. Aquí lo usamos con un mensaje pequeño para entender el concepto.

    openssl pkeyutl -encrypt -pubin -inkey bob_publica.pem -in mensaje_alice.txt -out mensaje_para_bob.bin

    Ver que es ilegible:

    xxd mensaje_para_bob.bin | head

    ✅ Resultado: datos binarios “ruido”.

    FASE 6 — Descifrar con la clave privada de Bob

    openssl pkeyutl -decrypt -inkey bob_privada.pem -in mensaje_para_bob.bin -out mensaje_descifrado.txt
cat mensaje_descifrado.txt

    ✅ Resultado esperado: el texto original vuelve intacto.

    Aprendizaje clave:

    • Cualquiera con la pública puede cifrar para Bob
    • Solo Bob con la privada puede leerlo

    PARTE 3 — “FIRMA DIGITAL” (Integridad + Autoría)

    Ahora el enemigo puede intentar modificar mensajes. La Flota exige que cada mensaje vaya firmado.

    FASE 7 — Alice firma un mensaje

    Primero Alice genera sus claves (identidad propia):

    openssl genrsa -out alice_privada.pem 2048
openssl rsa -in alice_privada.pem -pubout -out alice_publica.pem

    Mensaje oficial:

    openssl dgst -sha256 -sign alice_privada.pem -out orden.firma orden.txt

    FASE 8 — Crear el hash y firmarlo (firma con clave privada)

    openssl dgst -sha256-sign alice_privada.pem -out orden.firma orden.txt

    ✅ “orden.firma” es la firma digital.

    FASE 9 — Verificar la firma con la clave pública

    openssl dgst -sha256-verify alice_publica.pem -signature orden.firma orden.txt

    ✅ Resultado esperado: Verified OK

    FASE 10 — Simular sabotaje (modificación del mensaje)

    echo "Orden de misión: desactivar escudos y abrir bahía de carga." > orden.txt
openssl dgst -sha256 -verify alice_publica.pem -signature orden.firma orden.txt

    ✅ Resultado esperado: Verification failure

    Aprendizaje clave:

    • La firma no cifra (no oculta).
    • La firma garantiza que el mensaje no fue modificado y que viene de quien dice venir.

    PARTE 4 — “CERTIFICADOS” (Confianza en la clave pública)

    Aquí está la pregunta mortal:
    ¿cómo sabe Bob que la clave pública de Alice es realmente de Alice y no del enemigo?

    Respuesta: certificados.

    Vamos a simular una mini-PKI de la Flota (una CA).

    FASE 11 — Crear la CA de la Flota Estelar

    CA = Autoridad de Certificación (el “notario” criptográfico).

    Clave privada de la CA:

    openssl genrsa -out starfleet_ca_privada.pem 4096

    Certificado autofirmado de la CA (válido 365 días):

    openssl req -x509 -new -key starfleet_ca_privada.pem -sha256 -days 365 -out starfleet_ca.crt \
-subj "/C=ES/O=Starfleet Academy/OU=Security Division/CN=Starfleet Root CA"

    Ver certificado:

    openssl x509 -in starfleet_ca.crt -text-noout | head -n40

    FASE 12 — Alice solicita un certificado (CSR)

    CSR = Certificate Signing Request (petición de certificado).

    openssl req -x509 -new -key starfleet_ca_privada.pem -sha256 -days 365 -out starfleet_ca.crt \
-subj "/C=ES/O=Starfleet Academy/OU=Security Division/CN=Starfleet Root CA"

    FASE 13 — La CA firma el certificado de Alice

    openssl x509 -req -in alice.csr -CA starfleet_ca.crt -CAkey starfleet_ca_privada.pem \
-CAcreateserial -out alice_cert.crt -days 365 -sha256

    Ver contenido:

    openssl x509 -in alice_cert.crt -text-noout | head -n60

    FASE 14 — Verificar que el certificado de Alice “cuelga” de la CA

    openssl verify -CAfile starfleet_ca.crt alice_cert.crt

    ✅ Resultado esperado: alice_cert.crt: OK

    Aprendizaje clave:

    • Ahora Bob no confía “porque sí” en la clave pública de Alice.
    • Confía porque la CA de la Flota la certifica.

    PARTE 5 — “HÍBRIDO” (Cómo funciona Internet de verdad)

    Verdad del universo:
    El asimétrico es lento para datos grandes.
    Se usa para intercambiar/validar una clave simétrica, y luego se cifra todo con AES/ChaCha20.

    Mini-demostración conceptual (sin meternos aún en DH real)

    1. Alice y Bob se validan con certificados (asimétrico)
    2. Se acuerda una clave de sesión (simétrica)
    3. Todo el tráfico va con AES-GCM / ChaCha20-Poly1305

    Eso es TLS.

    INFORME FINAL (lo que tienes que entregar)

    1. Capturas o salida de:
    • creación de claves
    • cifrado/descifrado RSA
    • firma y verificación (OK)
    • verificación fallida tras manipulación
    • creación de CA
    • emisión del certificado de Alice
    • verificación openssl verify
    1. Explicación breve:
    • diferencia cifrado vs firma
    • por qué se necesitan certificados
    • por qué TLS es híbrido

    OPCIONALES (Modo “Cadete con rango”)

    A) Ver handshake TLS real con Wireshark (si tienes tiempo)

    • abrir un sitio HTTPS
    • filtrar tls y ver certificados, cipher suite, etc.

    B) Pasar a ECC

    • generar claves con curvas elípticas y comparar tamaños

    C) Forward secrecy (conceptual)

    • por qué DH/ECDHE evita que roben sesiones antiguas si se filtra una clave

    Registro del Capitán:

    “Cadete, hoy no solo has cifrado un mensaje. Has creado confianza en un universo hostil.
    La seguridad no es ocultar información: es demostrar identidad, detectar manipulación y sobrevivir a la interceptación.”