Categoría: Análisis Forense

  • OSINT: qué revela un documento Word

    OSINT: qué revela un documento Word

    Archivo entregado por el profesor: comunicado_faro_norte.docx. Es un caso ficticio preparado para esta práctica. No difundas una lista de respuestas antes de que todos los grupos terminen.

    Situación

    El equipo de comunicación de una empresa ficticia, Faro Norte, va a publicar un documento Word. Antes de hacerlo, quiere saber qué información podría descubrir cualquier persona que descargue el archivo. Actuarás como analista y elaborarás un informe breve con pruebas y recomendaciones.

    Trabaja únicamente con el documento de la práctica o con archivos propios autorizados. No publiques nombres reales, rutas personales ni documentos de terceros en servicios de análisis en línea.

    Objetivos

    • Distinguir el contenido visible, las propiedades internas del documento y los datos del sistema de archivos.
    • Extraer propiedades con una interfaz gráfica y con ExifTool.
    • Inspeccionar las partes internas de un DOCX sin modificar el original.
    • Explicar qué conclusiones están demostradas y cuáles son solo hipótesis.
    • Comprobar qué información permanece tras preparar una copia para publicación.

    Material

    • Un equipo con Microsoft Word o LibreOffice Writer y acceso a terminal.
    • ExifTool instalado. Comprueba con exiftool -ver. Si no está disponible, realiza los pasos de Word/LibreOffice y la inspección del DOCX; deja constancia de ello.
    • El archivo comunicado_faro_norte.docx, facilitado junto a este enunciado. El documento y las identidades que figuran en él son ficticios.

    Fase 1. Preparar el archivo y leer lo visible (10 minutos)

    1. Descarga comunicado_faro_norte.docx. Conserva este archivo sin abrirlo en un editor que guarde automáticamente.
    2. Duplica el archivo y llama a la copia comunicado_faro_norte_copia.docx. Analiza la copia; conserva el archivo entregado para poder comparar al final. Si usas una aplicación con guardado automático, desactívalo para este caso o trabaja siempre sobre otra copia.
    3. Abre la copia en Word o LibreOffice y anota únicamente lo que cualquiera puede ver al leer el documento: título, lugar, fecha, actividades y correo de contacto. Cierra sin guardar.
    4. Explica por qué los datos visibles no equivalen a los metadatos. Formula dos preguntas que crees que el documento podría responder sin que la información aparezca en la página.

    Evidencia 1: captura del comunicado y tabla con cinco datos visibles. Todos los nombres y lugares pertenecen al caso ficticio.

    Fase 2. Observar antes de extraer (5 minutos)

    1. Apunta el nombre, tamaño y extensión de la copia.
    2. Anota la fecha de modificación que muestra el explorador de archivos.
    3. Abre el documento y localiza su panel de propiedades: Archivo → Información → Propiedades en Word, o Archivo → Propiedades en LibreOffice. Registra los campos que aparezcan.
    4. Responde: ¿la fecha que muestra el sistema operativo pertenece necesariamente al contenido original? Justifica tu respuesta pensando en la copia que acabas de hacer.

    Evidencia 2: tabla con las propiedades visibles y su procedencia (explorador o editor).

    Fase 3. Leer metadatos con ExifTool (10 minutos)

    Abre una terminal en la carpeta del archivo. Ejecuta:

    exiftool -a -G1 -s comunicado_faro_norte_copia.docx

    En Windows PowerShell, si ExifTool no está en PATH, usa la ruta del ejecutable y del archivo entre comillas:

    & "C:\ruta\a\exiftool.exe" -a -G1 -s "C:\ruta\al\comunicado_faro_norte_copia.docx"

    Anota, solo si existen, Creator, LastModifiedBy, Title, Subject, Keywords, CreateDate, ModifyDate, RevisionNumber, Company, Manager, FileSize, FileType y FileModifyDate. Los nombres exactos pueden variar. No inventes campos ausentes. El prefijo entre corchetes indica el grupo de cada dato.

    Evidencia 3: captura o salida copiada del comando y una tabla:

    CampoValor encontradoGrupo / fuente¿Dato introducido, generado o incierto?

    Pregunta: compara las fechas internas con FileModifyDate. ¿Por qué podrían diferir?

    Fase 4. Examinar el interior del DOCX (15 minutos)

    Un DOCX es un paquete de archivos. Inspecciona una copia adicional sin sobrescribir el documento de trabajo.

    Opción gráfica, válida para Windows, macOS y Linux: duplica el .docx, cambia la extensión de esa copia a .zip y ábrela con un descompresor. Si el sistema pregunta si deseas cambiar la extensión, acepta. Abre estos archivos como texto (no ejecutes ningún contenido):

    • docProps/core.xml: propiedades principales, como creador, título y fechas, si están presentes.
    • docProps/app.xml: propiedades de aplicación, como el programa o estadísticas, cuando existen.
    • word/document.xml: texto del documento en formato XML; su lectura puede resultar incómoda porque el texto está dividido en elementos.

    Opción terminal en Linux/macOS:

    unzip -l comunicado_faro_norte_copia.docx
    unzip -p comunicado_faro_norte_copia.docx docProps/core.xml
    unzip -p comunicado_faro_norte_copia.docx docProps/app.xml

    En Windows puedes usar la opción gráfica; no necesitas instalar comandos adicionales.

    Evidencia 4: nombres de al menos cinco entradas del paquete y dos valores concretos encontrados en core.xml o app.xml. Si un archivo no existe, registra esa ausencia.

    Preguntas: ¿qué datos de ExifTool puedes localizar también en XML? ¿Qué datos proceden del sistema de archivos y no están en esos XML? Localiza también, si aparecen, propiedades que apunten a un proyecto o a personas que no se mencionan en el texto visible. ¿Encuentras alguna información que no se vea al leer el comunicado?

    Fase 5. Construir un informe OSINT (15 minutos)

    Rellena esta tabla. Usa «No consta» si un dato no aparece; «Hipótesis» si depende de una interpretación.

    AfirmaciónEvidencia exacta y ubicaciónGrado de confianzaPosible explicación alternativa
    El documento contiene un título interno
    Una persona concreta lo redactó
    Se editó después de crearlo
    Se utilizó un programa determinado

    Después responde en 100–150 palabras: ¿qué podría aprender un tercero que solo recibiese este DOCX? ¿Qué afirmaciones no puedes demostrar con los metadatos? Recuerda que el campo «Autor» puede configurarse manualmente o conservarse de una plantilla y no identifica necesariamente a quien escribió el texto.

    Fase 6. Reducir exposición y volver a comprobar (10–15 minutos)

    1. Conserva intacto el original. Crea comunicado_faro_norte_publicacion.docx.
    2. En Word, si está disponible, utiliza Archivo → Información → Comprobar si hay problemas → Inspeccionar documento; revisa las categorías ofrecidas y elimina de la copia las propiedades personales que decidas retirar. En LibreOffice, revisa Archivo → Propiedades y las opciones de eliminación de información personal al guardar disponibles en tu versión. Anota exactamente qué hiciste.
    3. Repite el comando de la fase 3 para la copia de publicación. Vuelve a examinar docProps/core.xml en esa copia.
    4. Compara antes y después. No des por hecho que todos los campos desaparecieron. Verifica también que el contenido que se pretende publicar sigue presente.
    Campo o contenidoAntesDespués¿Permanece?
    Autor
    Último editor
    Fechas internas
    Título
    Texto visible

    Conclusión: redacta tres medidas concretas que recomendarías antes de publicar documentos de tu centro o empresa.

    Ampliación opcional: formato DOC antiguo

    Si el profesor proporciona un .doc autorizado, repite solo las fases 2, 3 y 5. El formato .doc es binario: no intentes abrirlo como ZIP ni esperes encontrar docProps/core.xml. Compara qué propiedades puede recuperar ExifTool en cada formato y describe los límites de la comparación.

    Entrega

    Sube un ZIP con:

    1. README.md con objetivo, entorno utilizado, pasos realizados, tablas completadas, respuestas y conclusión.
    2. evidencias/ con capturas o salidas de terminal legibles, sin información personal real.
    3. El DOCX ficticio entregado y la copia preparada para publicación. No incluyas otros archivos personales.

    El README debe permitir que otra persona repita la práctica. Identifica cada captura en el texto. No se evaluará encontrar un número determinado de metadatos: algunos dependen del editor, la configuración y cómo se creó el archivo.

  • OSINT: Operación Atlas

    OSINT: Operación Atlas

    Reconocimiento pasivo de dominios desde terminal

    Documentación de apoyo: Reconocimiento de dominios por terminal y scripting


    1. Introducción

    Una organización ficticia llamada Atlas Digital está revisando la información que su infraestructura publica en Internet. Durante los últimos años ha creado páginas web, aplicaciones, servicios de correo y entornos de pruebas, pero no dispone de un inventario actualizado.

    El equipo de seguridad necesita conocer su superficie externa visible mediante fuentes públicas antes de realizar una auditoría más profunda.

    Tu misión será actuar como analista OSINT. Utilizarás la terminal de Linux para descubrir subdominios, resolver direcciones IP, consultar información pública sobre esas direcciones y automatizar parte del proceso mediante un script en Bash.

    El objetivo no consiste únicamente en ejecutar comandos. Tendrás que interpretar, relacionar y documentar los resultados.


    2. Objetivos de aprendizaje

    Al finalizar el reto deberás ser capaz de:

    • Explicar qué es el reconocimiento OSINT pasivo.
    • Utilizar herramientas desde una terminal Linux.
    • Enumerar subdominios con Amass y Subfinder.
    • guardar, ordenar, combinar y filtrar resultados.
    • Resolver nombres de dominio y obtener sus direcciones IP.
    • Consultar información WHOIS y datos aproximados de geolocalización.
    • Procesar respuestas JSON con curl y jq.
    • Crear un script Bash sencillo para automatizar el análisis.
    • Diferenciar entre un dato, una evidencia y una conclusión.
    • Elaborar un informe técnico reproducible.

    3. Normas y alcance autorizado

    Esta actividad es exclusivamente de reconocimiento pasivo.

    Está permitido

    • Consultar fuentes públicas.
    • Utilizar Amass en modo -passive.
    • Utilizar Subfinder con sus fuentes OSINT.
    • Resolver registros DNS.
    • Consultar WHOIS y servicios públicos de información de IP.
    • Trabajar únicamente con el dominio indicado por el profesor.

    No está permitido

    • Escanear puertos con Nmap u otras herramientas.
    • Buscar vulnerabilidades o ejecutar exploits.
    • Realizar fuerza bruta de subdominios, directorios o credenciales.
    • Acceder a paneles, cuentas o zonas privadas.
    • Enviar tráfico masivo o intentar evadir límites.
    • Investigar dominios distintos de los autorizados.

    Encontrar un servicio visible no autoriza a entrar en él. Si descubres algo que parezca sensible, registra únicamente el nombre y comunícalo al profesor.


    4. Material necesario

    • Ubuntu, Debian, Kali Linux o una máquina virtual Linux.
    • Conexión a Internet.
    • Un dominio autorizado por el profesor.
    • Terminal y editor de texto.
    • Herramientas: amass, subfinder, dnsutils, whois, curl, jq y, opcionalmente, geoip-bin.

    El profesor proporcionará el objetivo:

    DOMINIO_AUTORIZADO=____________________________

    No sustituyas esta variable por el dominio de una empresa elegida al azar.


    5. Preparación del entorno

    Paso 1. Crear la estructura de trabajo

    mkdir -p operacion-atlas/{capturas,resultados,script}
    cd operacion-atlas

    Comprueba la estructura:

    find . -maxdepth 2 -type d

    Paso 2. Instalar las herramientas

    En una distribución basada en Ubuntu o Debian:

    sudo apt update
    sudo apt install amass dnsutils whois curl jq geoip-bin

    Si Subfinder no está disponible en los repositorios de tu distribución, sigue la opción de instalación explicada en la documentación del curso. Por ejemplo, si tienes Snap:

    sudo snap install subfinder

    Paso 3. Comprobar la instalación

    amass version
    subfinder -version
    host -V
    whois --version
    curl --version
    jq --version

    Evidencia 1: incluye una captura o salida de terminal que demuestre que las herramientas están disponibles. Si alguna no se puede instalar, explica el problema y continúa con las que funcionen.


    6. Fase 1: reconocimiento inicial

    Antes de ejecutar herramientas, completa una pequeña ficha:

    CampoRespuesta
    Dominio autorizado
    Fecha y hora de inicio
    Sistema operativo
    Hipótesis inicial
    ¿Qué información esperas encontrar?

    Formula al menos dos hipótesis. Por ejemplo:

    • El dominio puede utilizar varios subdominios para separar servicios.
    • Parte de la infraestructura puede estar alojada en un proveedor cloud.

    No importa si después resultan incorrectas: deberán contrastarse con evidencias.


    7. Fase 2: enumeración pasiva con Amass

    Paso 1. Ejecutar Amass en modo pasivo

    Sustituye dominio-autorizado.example por el objetivo indicado por el profesor:

    amass enum -passive -d dominio-autorizado.example \
      -o resultados/amass.txt

    El parámetro -passive es obligatorio en este reto.

    Paso 2. Revisar los resultados

    cat resultados/amass.txt

    Cuenta los resultados:

    wc -l resultados/amass.txt

    Ordénalos y elimina duplicados:

    sort -u resultados/amass.txt -o resultados/amass_limpio.txt

    Paso 3. Interpretar

    Responde:

    1. ¿Cuántos subdominios distintos encontró Amass?
    2. ¿Qué nombres parecen corresponder a servicios web, correo, API, desarrollo o administración?
    3. ¿Un nombre como dev, test o staging demuestra que existe un entorno vulnerable? Justifica la respuesta.
    4. ¿Por qué el resultado de una fuente OSINT puede estar desactualizado?

    Evidencia 2: incluye el comando, el número de resultados y una selección razonada de hasta diez subdominios. No llenes el informe con capturas repetitivas.


    8. Fase 3: enumeración con Subfinder

    Paso 1. Ejecutar la segunda herramienta

    subfinder -d dominio-autorizado.example \
      -o resultados/subfinder.txt

    Paso 2. Limpiar la salida

    sort -u resultados/subfinder.txt -o resultados/subfinder_limpio.txt

    Paso 3. Comparar las herramientas

    Subdominios encontrados por ambas:

    comm -12 resultados/amass_limpio.txt resultados/subfinder_limpio.txt \
      > resultados/coincidencias.txt

    Encontrados solamente por Amass:

    comm -23 resultados/amass_limpio.txt resultados/subfinder_limpio.txt \
      > resultados/solo_amass.txt

    Encontrados solamente por Subfinder:

    comm -13 resultados/amass_limpio.txt resultados/subfinder_limpio.txt \
      > resultados/solo_subfinder.txt

    Combina todos los resultados:

    sort -u resultados/amass_limpio.txt resultados/subfinder_limpio.txt \
      > resultados/subdominios_finales.txt

    Obtén los recuentos:

    wc -l resultados/amass_limpio.txt \
          resultados/subfinder_limpio.txt \
          resultados/coincidencias.txt \
          resultados/subdominios_finales.txt

    Completa la tabla:

    ResultadoCantidad
    Amass
    Subfinder
    Coincidencias
    Total único

    Preguntas:

    1. ¿Qué herramienta ha encontrado más resultados?
    2. ¿Por qué dos herramientas OSINT pueden devolver resultados diferentes?
    3. ¿Por qué una coincidencia entre ambas fuentes aumenta la confianza, pero no confirma por sí sola que el servicio esté activo?

    Evidencia 3: tabla comparativa y explicación de las diferencias.


    9. Fase 4: resolución DNS

    Ahora comprobarás qué nombres de la lista pueden resolverse actualmente.

    Paso 1. Probar manualmente un subdominio

    host subdominio.dominio-autorizado.example

    También puedes consultar registros concretos:

    dig +short A subdominio.dominio-autorizado.example
    dig +short AAAA subdominio.dominio-autorizado.example
    dig +short CNAME subdominio.dominio-autorizado.example

    Paso 2. Automatizar la resolución de la lista

    while IFS= read -r subdominio; do
      echo "### $subdominio"
      host "$subdominio"
    done < resultados/subdominios_finales.txt \
      | tee resultados/resolucion_dns.txt

    Paso 3. Crear una lista única de IPv4

    while IFS= read -r subdominio; do
      dig +short A "$subdominio"
    done < resultados/subdominios_finales.txt \
      | grep -E '^[0-9]+(\.[0-9]+){3}$' \
      | sort -u \
      > resultados/ips.txt

    Revisa el resultado:

    cat resultados/ips.txt
    wc -l resultados/ips.txt

    Paso 4. Analizar

    Responde:

    1. ¿Todos los nombres encontrados mediante OSINT resuelven actualmente?
    2. ¿Hay varios subdominios que apunten a la misma IP?
    3. ¿Has encontrado registros CNAME?
    4. ¿Qué puede significar que varios servicios compartan dirección IP?
    5. ¿Qué diferencia existe entre no resolver un nombre y demostrar que nunca existió?

    Evidencia 4: presenta una tabla con una muestra de entre cinco y diez resultados.

    SubdominioTipo de registroIP o destino¿Resuelve?Observación

    10. Fase 5: contexto de las direcciones IP

    Selecciona un máximo de cinco IP públicas distintas. No es necesario consultar todas si la lista es muy grande.

    Paso 1. Consulta WHOIS

    whois DIRECCION_IP

    Busca datos como:

    • Organización o propietario del rango.
    • ASN, si aparece.
    • País de registro.
    • Rango o bloque de red.
    • Contactos de abuso, sin utilizarlos ni recopilar datos innecesarios.

    El país registrado en WHOIS no tiene por qué coincidir con la ubicación física exacta del servidor.

    Paso 2. Consulta GeoIP local

    geoiplookup DIRECCION_IP

    Paso 3. Consulta una API desde terminal

    curl -s "https://ipinfo.io/DIRECCION_IP/json" | jq

    Extrae solamente algunos campos:

    curl -s "https://ipinfo.io/DIRECCION_IP/json" \
      | jq '{ip, city, region, country, org, loc}'

    Respeta los límites del servicio: una consulta por cada IP seleccionada es suficiente.

    Paso 4. Correlacionar

    Completa la tabla:

    IPSubdominios asociadosOrganización/ASNPaís aproximadoPosible proveedorConfianza
    Alta/Media/Baja

    Responde:

    1. ¿Parece infraestructura propia, alojamiento compartido, CDN o proveedor cloud?
    2. ¿Coinciden WHOIS, GeoIP y la API?
    3. ¿Qué campos son hechos observados y cuáles son inferencias?
    4. ¿Por qué no debemos presentar una geolocalización de IP como una ubicación exacta?

    Evidencia 5: tabla completada y una conclusión prudente sobre la infraestructura.


    11. Fase 6: construir el script atlas.sh

    Debes crear un script que automatice el proceso básico.

    Requisitos mínimos

    El script deberá:

    1. Recibir un dominio como argumento.
    2. Comprobar que se ha indicado dicho argumento.
    3. Crear un directorio de resultados.
    4. Ejecutar Amass en modo pasivo.
    5. Ejecutar Subfinder.
    6. Combinar y eliminar duplicados.
    7. Resolver las direcciones IPv4.
    8. Guardar los resultados en archivos.
    9. Mostrar un resumen final.

    Plantilla orientativa

    Guárdala como script/atlas.sh y completa las partes marcadas:

    #!/usr/bin/env bash
    
    set -u
    
    if [ "$#" -ne 1 ]; then
      echo "Uso: $0 dominio-autorizado.example"
      exit 1
    fi
    
    DOMINIO="$1"
    FECHA="$(date +%Y%m%d_%H%M%S)"
    SALIDA="resultados_${DOMINIO}_${FECHA}"
    
    mkdir -p "$SALIDA"
    
    echo "[+] Iniciando reconocimiento pasivo de: $DOMINIO"
    
    # 1. Comprobar que las herramientas necesarias existen.
    # PISTA: command -v nombre_herramienta
    
    # 2. Ejecutar Amass exclusivamente en modo pasivo.
    
    # 3. Ejecutar Subfinder.
    
    # 4. Ordenar, combinar y eliminar duplicados.
    
    # 5. Resolver las direcciones IPv4 con dig.
    
    # 6. Mostrar el número de subdominios e IP únicas.
    
    echo "[+] Proceso finalizado. Resultados guardados en: $SALIDA"

    Da permiso de ejecución:

    chmod +x script/atlas.sh

    Ejecútalo únicamente con el dominio autorizado:

    ./script/atlas.sh dominio-autorizado.example

    Validaciones que debe incorporar

    Como mínimo, comprueba la presencia de cada herramienta:

    if ! command -v amass >/dev/null 2>&1; then
      echo "Error: Amass no está instalado."
      exit 1
    fi

    Repite o adapta la validación para las demás herramientas.

    Pruebas obligatorias

    Documenta qué ocurre cuando:

    • Se ejecuta sin argumentos.
    • Se ejecuta con el dominio autorizado.
    • Falta una herramienta necesaria.
    • Una de las herramientas no devuelve resultados.

    Evidencia 6: código completo del script, capturas o salidas de las pruebas y explicación de su funcionamiento.


    12. Fase 7: análisis final

    Redacta una conclusión que responda a estas preguntas:

    1. ¿Cuál es la superficie externa observada?
    2. ¿Cuántos subdominios únicos se han identificado?
    3. ¿Cuántos resolvían en el momento del análisis?
    4. ¿Qué proveedores o redes parecen alojarlos?
    5. ¿Existen indicios de servicios de desarrollo, pruebas, API o correo?
    6. ¿Qué resultados tienen una confianza alta, media o baja?
    7. ¿Qué limitaciones ha tenido la investigación?
    8. ¿Se confirmaron las hipótesis iniciales?
    9. ¿Qué recomendarías revisar al responsable del dominio?

    Las recomendaciones deben ser defensivas. Por ejemplo:

    • Mantener un inventario de subdominios.
    • Eliminar registros DNS abandonados.
    • Revisar nombres que revelen información innecesaria.
    • Comprobar que los entornos de prueba no estén publicados accidentalmente.
    • Repetir periódicamente el inventario pasivo.

    No afirmes que existe una vulnerabilidad si no dispones de evidencia suficiente.


    13. Entrega

    Entrega un archivo ZIP con esta estructura:

    operacion-atlas/
    ├── README.md
    ├── capturas/
    │   ├── 01_herramientas.png
    │   ├── 02_amass.png
    │   ├── 03_subfinder.png
    │   └── ...
    ├── resultados/
    │   ├── amass.txt
    │   ├── subfinder.txt
    │   ├── coincidencias.txt
    │   ├── subdominios_finales.txt
    │   ├── resolucion_dns.txt
    │   └── ips.txt
    └── script/
        └── atlas.sh

    El archivo README.md será el informe principal y deberá contener:

    1. Portada e identificación del alumno o equipo.
    2. Objetivo y alcance autorizado.
    3. Entorno y herramientas.
    4. Hipótesis iniciales.
    5. Procedimiento reproducible.
    6. Evidencias seleccionadas.
    7. Tablas de resultados.
    8. Explicación del script.
    9. Conclusiones y recomendaciones.
    10. Limitaciones y fuentes consultadas.

    No se valorará mejor un informe por tener más capturas. Se valorará que cada evidencia sea legible, necesaria y esté interpretada.


    14. Rúbrica de evaluación

    CriterioPuntuación
    Preparación, alcance ético y organización1 punto
    Enumeración pasiva con Amass y Subfinder2 puntos
    Limpieza, comparación y combinación de resultados1,5 puntos
    Resolución DNS y análisis de IP1,5 puntos
    Script Bash, validaciones y pruebas2 puntos
    Interpretación, correlación y conclusiones1,5 puntos
    Calidad del README y evidencias0,5 puntos
    Total10 puntos

    Penalizaciones importantes

    • Uso de técnicas activas no autorizadas: la práctica podrá considerarse no superada.
    • Investigación de dominios fuera del alcance: la práctica podrá considerarse no superada.
    • Script que no se explica o no se prueba: no se considerará completamente válido.
    • Capturas sin interpretación: tendrán poco valor como evidencia.
    • Resultados o conclusiones inventados: penalización grave.

    15. Nivel avanzado opcional: inteligencia reproducible

    Quienes terminen antes pueden incorporar estas mejoras:

    Mejora A. Archivo CSV

    Genera un archivo con el formato:

    subdominio,ip
    www.dominio.example,203.0.113.10
    api.dominio.example,203.0.113.20

    Mejora B. Parámetros adicionales

    Permite utilizar:

    ./script/atlas.sh -d dominio-autorizado.example -o informe

    Mejora C. Registro de ejecución

    Guarda fecha, herramienta, versión y comando ejecutado en un archivo log.txt.

    Mejora D. Manejo de errores

    Haz que el script continúe de forma controlada si Amass o Subfinder falla, indicando qué fuente no estuvo disponible.

    Mejora E. Comparación temporal

    Ejecuta el análisis en dos momentos autorizados distintos y compara las listas:

    comm -13 resultado_anterior.txt resultado_actual.txt

    Explica qué nombres son nuevos, cuáles han desaparecido y por qué eso no basta para asegurar que se haya producido un cambio real en la infraestructura.


    16. Pregunta de cierre

    Si todas las herramientas utilizadas consultan fuentes públicas, ¿por qué sigue siendo necesario definir un alcance, aplicar límites y tratar los resultados con responsabilidad?

  • Auditoría pasiva con Google Dorks

    Auditoría pasiva con Google Dorks

    Situación

    La empresa ficticia Nébula Systems está preparando una revisión de seguridad. La dirección sospecha que algunos documentos, formularios, directorios o páginas antiguas pueden estar apareciendo en buscadores sin que el equipo técnico sea consciente de ello.

    Vuestro equipo ha sido contratado para realizar una auditoría OSINT pasiva. No debéis atacar servidores, probar contraseñas ni explotar vulnerabilidades. Vuestra misión consiste en utilizar operadores avanzados de búsqueda para descubrir qué información pública puede localizar un usuario externo y proponer cómo reducir esa exposición.

    El trabajo se basa en la documentación Google Hacking de La Aventura de Aprender:


    Objetivos de aprendizaje

    Al finalizar el reto deberéis ser capaces de:

    • Explicar qué son Google Hacking y Google Dorks.
    • Utilizar operadores avanzados de búsqueda de forma combinada.
    • Diferenciar un hallazgo real, un falso positivo y un resultado irrelevante.
    • Evaluar el riesgo de la información indexada.
    • Registrar evidencias sin recopilar datos personales ni información sensible.
    • Proponer medidas de mitigación adecuadas.
    • Elaborar un informe técnico reproducible en Markdown.

    Normas de seguridad y uso ético

    Este reto solo puede realizarse sobre uno de estos objetivos:

    1. Un dominio de laboratorio proporcionado por el profesor.
    2. Un dominio propio del centro o del alumno para el que exista autorización.
    3. Dominios de demostración indicados expresamente por el profesor.

    Está permitido

    • Realizar búsquedas en Google, Bing o DuckDuckGo.
    • Analizar únicamente la información que aparece en los resultados del buscador.
    • Visitar páginas públicas ordinarias cuando el profesor lo haya autorizado.
    • Registrar URL, título, descripción y tipo de información encontrada.
    • Consultar GHDB para aprender a construir consultas.

    Está prohibido

    • Buscar deliberadamente contraseñas, claves privadas, tokens, datos médicos o datos personales reales.
    • Descargar bases de datos, copias de seguridad, archivos de configuración o documentos sensibles.
    • Acceder a paneles de administración o intentar iniciar sesión.
    • Realizar escaneos, fuerza bruta, explotación de vulnerabilidades o evasión de controles.
    • Automatizar búsquedas masivas.
    • Compartir públicamente una exposición real.

    Si aparece accidentalmente información sensible, no la abráis, no la descarguéis y no la copiéis. Detened la investigación, anotad de forma genérica que se ha localizado un posible hallazgo y avisad al profesor.


    Organización

    • Modalidad: individual o parejas.
    • Duración recomendada: 2 sesiones de 90 minutos.
    • Producto final: un repositorio o archivo ZIP con un README.md y una carpeta img.
    • Nombre recomendado: reto-google-dorks-apellido1-apellido2.

    Desarrollo paso a paso

    Fase 0. Preparación del entorno

    1. Cread una carpeta con la siguiente estructura:
    reto-google-dorks/
    ├── README.md
    └── img/
    1. En el README.md, añadid:
    • Título del reto.
    • Nombre de los integrantes.
    • Fecha.
    • Dominio autorizado asignado.
    • Buscador utilizado.
    • Declaración ética: “La investigación se ha realizado mediante técnicas pasivas y sobre un objetivo autorizado”.
    1. Leed la documentación de referencia antes de realizar búsquedas.

    Evidencia requerida: captura de la estructura del proyecto o bloque de código que la represente.


    Fase 1. Comprender los operadores

    Explicad con vuestras propias palabras para qué sirven los siguientes operadores:

    Operador¿Qué debéis explicar?
    site:Cómo limita la búsqueda a un dominio
    filetype:Cómo filtra por tipo de documento
    inurl:Cómo busca términos dentro de la URL
    intitle:Cómo busca términos en el título
    intext:Cómo busca texto dentro de una página
    "frase exacta"Qué cambia al utilizar comillas
    -terminoCómo se excluyen resultados
    ORCómo se ofrecen alternativas

    Después, cread un ejemplo seguro y genérico de cada uno empleando example.com o el dominio autorizado.

    No copiéis únicamente las definiciones de la documentación. Debéis explicar qué utilidad tendría cada operador durante una auditoría.

    Evidencia requerida: tabla de operadores, explicación y ejemplo.


    Fase 2. Reconocimiento inicial del dominio

    Sustituid DOMINIO-AUTORIZADO por el objetivo asignado.

    1. Ejecutad una búsqueda general:
    site:DOMINIO-AUTORIZADO
    1. Observad las primeras páginas de resultados y anotad:
    • Número aproximado de resultados indicado por el buscador.
    • Tipos de páginas que aparecen.
    • Secciones o subdominios visibles.
    • Resultados antiguos, duplicados o inesperados.
    1. Repetid la consulta añadiendo al menos dos palabras relevantes para la organización, por ejemplo:
    site:DOMINIO-AUTORIZADO contacto
    site:DOMINIO-AUTORIZADO formación
    1. Comparad los resultados y explicad qué información básica podría obtener un tercero.

    El número de resultados del buscador es aproximado y puede variar. No debe tratarse como una medición exacta.

    Evidencia requerida: consultas empleadas, fecha, resumen de resultados y una captura sin datos personales.


    Fase 3. Localización de documentos públicos

    Buscad documentos que la organización publique de forma legítima. Realizad al menos cuatro consultas usando tipos diferentes:

    site:DOMINIO-AUTORIZADO filetype:pdf
    site:DOMINIO-AUTORIZADO filetype:docx
    site:DOMINIO-AUTORIZADO filetype:xlsx
    site:DOMINIO-AUTORIZADO filetype:pptx

    Si una extensión no ofrece resultados, registrad igualmente la consulta. Un resultado negativo también es una evidencia válida.

    Para cada consulta, indicad:

    • Qué pretendíais encontrar.
    • Qué habéis encontrado.
    • Si el resultado parece intencionadamente público.
    • Qué información revela el título o el fragmento mostrado por Google.
    • Riesgo inicial: informativo, bajo, medio o alto.

    No descarguéis documentos que parezcan internos, confidenciales o que contengan datos personales.

    Evidencia requerida: tabla comparativa de al menos cuatro búsquedas.


    Fase 4. Identificación de rutas y servicios visibles

    Realizad búsquedas orientadas a reconocer la estructura pública del sitio:

    site:DOMINIO-AUTORIZADO inurl:login
    site:DOMINIO-AUTORIZADO inurl:admin
    site:DOMINIO-AUTORIZADO inurl:portal
    site:DOMINIO-AUTORIZADO inurl:uploads
    site:DOMINIO-AUTORIZADO inurl:documentos

    Podéis adaptar las palabras al contexto del objetivo. No accedáis a paneles ni intentéis autenticaros.

    Responded:

    1. ¿La existencia pública de una página de inicio de sesión es por sí sola una vulnerabilidad?
    2. ¿Qué información puede revelar la estructura de una URL?
    3. ¿Qué resultados son normales y cuáles deberían revisarse?
    4. ¿Habéis detectado falsos positivos?

    Evidencia requerida: mínimo tres consultas comentadas y clasificación de sus resultados.


    Fase 5. Consultas combinadas

    Ahora debéis construir búsquedas más precisas combinando operadores. Cread y probad al menos cinco consultas propias.

    Ejemplos seguros:

    site:DOMINIO-AUTORIZADO filetype:pdf "manual"
    site:DOMINIO-AUTORIZADO (filetype:pdf OR filetype:docx) "curso"
    site:DOMINIO-AUTORIZADO inurl:uploads filetype:pdf
    site:DOMINIO-AUTORIZADO intitle:"contacto"
    site:DOMINIO-AUTORIZADO filetype:pdf -inurl:blog

    Cada consulta deberá incluir:

    • Hipótesis: qué creéis que puede localizar.
    • Dork utilizado.
    • Resultado obtenido.
    • Interpretación.
    • Modificación realizada para mejorar la precisión.

    Al menos una consulta debe usar OR, otra debe excluir un término con - y otra debe combinar tres operadores.

    Evidencia requerida: cinco fichas de consulta completas.


    Fase 6. Investigación en GHDB

    Consultad la Google Hacking Database enlazada en la documentación.

    1. Elegid dos categorías relacionadas con exposición de información.
    2. Seleccionad un ejemplo de consulta de cada categoría.
    3. Explicad qué intenta localizar, sin ejecutarlo sobre organizaciones reales.
    4. Transformadlo en una versión segura para el dominio de laboratorio.
    5. Indicad qué riesgo representaría un resultado positivo.

    No se valorará que el dork sea espectacular, sino que comprendáis su funcionamiento y sepáis adaptarlo de manera responsable.

    Evidencia requerida: dos análisis de dorks de GHDB, con referencia a su categoría y versión adaptada.


    Fase 7. Comparación entre buscadores

    Elegid dos consultas anteriores y repetidlas en otro buscador, como Bing o DuckDuckGo.

    Comparad:

    • Cantidad y relevancia de resultados.
    • Documentos que aparecen en uno y no en otro.
    • Diferencias en títulos y fragmentos.
    • Posibles causas de las diferencias.

    No es necesario que todos los buscadores admitan exactamente los mismos operadores. Si uno no funciona, documentadlo.

    Evidencia requerida: tabla comparativa de dos consultas en dos buscadores.


    Fase 8. Registro y clasificación de hallazgos

    Reunid los resultados relevantes en una tabla como esta:

    IDConsultaHallazgo resumidoEvidenciaProbabilidadImpactoRiesgo¿Falso positivo?
    H-01site:... filetype:pdfDocumento público antiguoURL y capturaMediaBajoBajoNo

    Utilizad esta escala:

    • Informativo: no existe un problema, pero el resultado ayuda a conocer la huella digital.
    • Bajo: información pública poco sensible o desactualizada.
    • Medio: información no prevista que facilita reconocimiento o ingeniería social.
    • Alto: posible exposición de información interna o sensible. No debe abrirse; se comunica al profesor.

    Para cada hallazgo relevante, explicad por qué le asignáis esa valoración. El nivel de riesgo no depende de que el resultado “parezca interesante”, sino de su impacto y probabilidad.

    Evidencia requerida: inventario de hallazgos. Puede haber hallazgos informativos o resultados negativos.


    Fase 9. Plan de mitigación

    Proponed al menos una medida concreta para cada hallazgo que necesite corrección. Podéis considerar:

    • Retirar documentos que ya no deban ser públicos.
    • Mover copias de seguridad fuera del directorio web.
    • Desactivar el listado de directorios.
    • Revisar permisos y reglas del servidor.
    • Proteger áreas privadas mediante autenticación y autorización.
    • Evitar publicar información sensible en nombres de archivo, títulos o metadatos.
    • Solicitar la retirada de resultados obsoletos del buscador.
    • Utilizar noindex cuando proceda.
    • Revisar robots.txt, entendiendo que no es un mecanismo de seguridad.

    Para cada medida indicad:

    • Hallazgo al que responde.
    • Acción propuesta.
    • Responsable recomendado.
    • Prioridad.
    • Cómo comprobaríais posteriormente que la corrección funciona.

    Evidencia requerida: plan de mitigación priorizado.


    Fase 10. Conclusiones

    Responded razonadamente:

    1. ¿Qué diferencia existe entre una búsqueda normal y un Google Dork?
    2. ¿Por qué una página indexada no es automáticamente una vulnerabilidad?
    3. ¿Cuál ha sido la combinación de operadores más útil?
    4. ¿Qué limitaciones tiene este tipo de auditoría?
    5. ¿Qué riesgo puede tener publicar documentos aparentemente inofensivos?
    6. ¿Qué debe hacer un auditor si encuentra información sensible de forma accidental?
    7. ¿Qué cambiaríais en la exposición pública del dominio analizado?

    Misión extra

    Quienes terminen el reto principal pueden realizar esta ampliación:

    1. Diseñad una matriz con tres objetivos: documentos, rutas y contenido textual.
    2. Cread tres consultas diferentes para cada objetivo, sin ejecutar búsquedas agresivas.
    3. Comparad los resultados actuales con una versión histórica pública del sitio mediante Wayback Machine, si el profesor lo autoriza.
    4. Seleccionad un documento público e indicad qué metadatos sería razonable revisar en un laboratorio, sin descargar material sensible.
    5. Diseñad una consulta periódica que la propia organización podría usar para vigilar su exposición.
    6. Proponed un procedimiento responsable de notificación de hallazgos.

    La ampliación debe centrarse en la metodología y la defensa. No se permite utilizar herramientas automáticas de escaneo.


    Estructura obligatoria del README.md

    # Operación Huella Digital
    
    ## 1. Datos del equipo
    ## 2. Objetivo y autorización
    ## 3. Declaración ética
    ## 4. Operadores estudiados
    ## 5. Reconocimiento inicial
    ## 6. Búsqueda de documentos
    ## 7. Rutas y servicios visibles
    ## 8. Consultas combinadas
    ## 9. Investigación en GHDB
    ## 10. Comparación de buscadores
    ## 11. Inventario de hallazgos
    ## 12. Plan de mitigación
    ## 13. Conclusiones
    ## 14. Bibliografía y recursos

    Las capturas deberán guardarse en img/ y enlazarse mediante rutas relativas:

    ![Resultado de una consulta autorizada](img/consulta-01.png)

    Antes de incluir una captura, ocultad nombres, correos, identificadores, cookies, cuentas abiertas y cualquier dato personal.


    Entrega

    La entrega debe contener:

    • README.md completo y bien estructurado.
    • Carpeta img con las evidencias necesarias.
    • Entre 10 y 15 consultas propias documentadas.
    • Al menos cinco consultas combinadas.
    • Comparación de dos buscadores.
    • Inventario de hallazgos.
    • Plan de mitigación.
    • Conclusiones personales.

    Aunque inicialmente se entregue como ZIP, el proyecto deberá estar preparado para subirse posteriormente a un repositorio Git.

    No incluyáis archivos obtenidos durante la investigación. Solo se entregarán el informe y capturas saneadas.


    Rúbrica de evaluación

    CriterioPeso
    Uso correcto y variado de operadores20 %
    Metodología paso a paso y reproducibilidad15 %
    Interpretación de resultados y falsos positivos15 %
    Clasificación razonada de riesgos15 %
    Medidas de mitigación15 %
    Calidad del README.md y de las evidencias10 %
    Ética, privacidad y cumplimiento de las normas10 %

    Penalizaciones

    • Ejecutar pruebas fuera de los objetivos autorizados: actividad no superada.
    • Incluir datos personales o información sensible en la entrega: actividad no superada hasta corregirla.
    • Presentar consultas sin explicar su finalidad y sus resultados: no se consideran realizadas.
    • Copiar definiciones sin interpretación propia: reducción de la puntuación correspondiente.

    Lista de comprobación final

    • He trabajado únicamente sobre un objetivo autorizado.
    • No he intentado iniciar sesión ni explotar ningún sistema.
    • He documentado las consultas aunque no ofrecieran resultados.
    • He diferenciado hallazgos, falsos positivos y resultados irrelevantes.
    • Las capturas no contienen datos personales.
    • No he descargado ni adjuntado información sensible.
    • Cada riesgo incluye una medida de mitigación.
    • El README.md puede entenderse sin explicaciones adicionales.
    • He citado la documentación utilizada.

    Resultado esperado

    El objetivo no es encontrar “secretos”, sino demostrar que sabéis formular preguntas precisas a un buscador, interpretar responsablemente las respuestas y convertir la información pública en recomendaciones defensivas útiles.

    Dominios recomendados para búsquedas inocuas

    En estos dominios limitaría la práctica a operadores como site:, filetype:, intitle:, inurl: y frases entre comillas, buscando exclusivamente información pública.

    DominioTemáticaEjemplos seguros
    boe.esLegislación españolasite:boe.es filetype:pdf ciberseguridad
    ine.esEstadísticas públicassite:ine.es filetype:xlsx población
    datos.gob.esDatos abiertossite:datos.gob.es filetype:csv transporte
    administracion.gob.esAdministración públicasite:administracion.gob.es filetype:pdf empleo
    europa.euUnión Europeasite:europa.eu filetype:pdf cybersecurity
    data.europa.euDatos abiertos europeossite:data.europa.eu \"open data\"
    who.intSalud pública internacionalsite:who.int filetype:pdf cybersecurity
    un.orgNaciones Unidassite:un.org filetype:pdf \"artificial intelligence\"
    nasa.govCiencia y espaciosite:nasa.gov filetype:pdf mars
    noaa.govMeteorología y océanossite:noaa.gov filetype:pdf climate
    mit.eduUniversidad e investigaciónsite:mit.edu filetype:pdf \"computer security\"
    stanford.eduInvestigación académicasite:stanford.edu filetype:pptx cybersecurity
    docs.python.orgDocumentación técnicasite:docs.python.org intitle:\"Python\" tutorial
    developer.mozilla.orgDesarrollo website:developer.mozilla.org \"HTTP authentication\"
    wikipedia.orgContenido enciclopédicosite:wikipedia.org intitle:OSINT
    archive.orgArchivo históricosite:archive.org filetype:pdf networking
  • OSINT – Investigación digital a partir de una fotografía

    OSINT – Investigación digital a partir de una fotografía

    Investigación digital a partir de una fotografía

    1. Introducción

    Una fotografía puede contener mucha más información de la que se aprecia a simple vista. Además de la propia imagen, el archivo puede guardar metadatos técnicos, fechas, coordenadas, información del dispositivo utilizado y otros datos.

    En esta práctica asumirás el papel de un analista OSINT (Open Source Intelligence). Tu misión será investigar una fotografía y obtener toda la información posible empleando únicamente fuentes abiertas, herramientas gratuitas y técnicas legales.

    No todas las fotografías contienen las mismas pistas. Por tanto, no es obligatorio completar con éxito todos los apartados. También se valorará que expliques correctamente:

    • Qué técnica has utilizado.
    • Qué resultado has obtenido.
    • Qué limitaciones has encontrado.
    • Qué información no has podido verificar.
    • Por qué consideras fiable o no una conclusión.

    2. Objetivos

    Al finalizar la práctica deberás ser capaz de:

    • Examinar técnicamente un archivo de imagen.
    • Extraer e interpretar sus metadatos.
    • Realizar búsquedas inversas de imágenes.
    • Analizar visualmente lugares, objetos, textos y personas sin identificarlas de forma invasiva.
    • Aplicar técnicas básicas de geolocalización.
    • Buscar información relacionada en fuentes abiertas.
    • Contrastar información utilizando varias fuentes.
    • Diferenciar entre evidencia, indicio, hipótesis y conclusión.
    • Documentar de forma ordenada una investigación OSINT.
    • Comprender los riesgos de privacidad asociados a las fotografías.

    3. Normas de la investigación

    La práctica se realizará únicamente con:

    • Fotografías proporcionadas por el profesor.
    • Fotografías propias.
    • Imágenes publicadas con una licencia adecuada.
    • Imágenes de lugares públicos o utilizadas expresamente con fines educativos.

    No está permitido:

    • Investigar a compañeros, profesores o particulares sin su consentimiento.
    • Intentar acceder a cuentas privadas.
    • Contactar con personas que aparezcan en la fotografía.
    • Publicar datos personales obtenidos durante la investigación.
    • Utilizar reconocimiento facial para identificar personas reales.
    • Acosar, seguir o localizar el domicilio de una persona.
    • Modificar o destruir el archivo original.
    • Presentar como segura una información que solamente es una suposición.

    4. Preparación del archivo

    Antes de empezar, crea una carpeta con la siguiente estructura:

    investigacion-osint/
    ├── imagen-original/
    ├── copias-trabajo/
    ├── capturas/
    ├── evidencias/
    └── README.md

    Guarda la fotografía original sin modificar dentro de imagen-original.

    Realiza todas las pruebas sobre una copia situada en copias-trabajo.

    Registro inicial

    Anota:

    • Nombre del archivo.
    • Formato.
    • Tamaño en bytes.
    • Dimensiones en píxeles.
    • Fecha y hora en la que recibiste el archivo.
    • Procedencia conocida de la fotografía.
    • Herramienta utilizada para obtener cada dato.

    Integridad del archivo

    Calcula al menos el hash SHA-256 de la fotografía.

    Ejemplo con Linux:

    sha256sum fotografia.jpg

    Ejemplo con PowerShell:

    Get-FileHash fotografia.jpg -Algorithm SHA256

    Explica para qué sirve un hash y por qué resulta útil conservarlo durante una investigación.


    5. Líneas posibles de investigación

    Deberás realizar todas las fases básicas y elegir varias investigaciones adicionales según las características de la fotografía.

    Fase 1. Inspección visual inicial

    Observa la imagen antes de utilizar buscadores o herramientas automáticas.

    Busca y registra elementos como:

    • Carteles.
    • Matrículas, que deberán ocultarse en la entrega.
    • Nombres de calles.
    • Nombres de comercios.
    • Logotipos.
    • Idiomas.
    • Señales de tráfico.
    • Banderas.
    • Edificios o monumentos.
    • Medios de transporte.
    • Uniformes.
    • Vegetación.
    • Tipo de carretera.
    • Arquitectura.
    • Mobiliario urbano.
    • Clima.
    • Relieve del terreno.
    • Posición del sol.
    • Sombras.
    • Cualquier elemento poco habitual.

    Crea una primera lista de hipótesis sin realizar todavía búsquedas.

    Ejemplo:

    ObservaciónPosible significadoGrado de confianza
    Señal triangular con borde rojoProbablemente EuropaMedio
    Texto aparentemente en portuguésPortugal o BrasilBajo
    Tranvía amarilloPodría ser LisboaBajo

    Las primeras hipótesis pueden ser incorrectas. Esto no se penalizará si posteriormente se contrastan.


    Fase 2. Análisis de metadatos

    Comprueba si la fotografía contiene metadatos EXIF, IPTC o XMP.

    Puedes utilizar herramientas como:

    • ExifTool.
    • Metadata2Go.
    • Jeffrey’s Image Metadata Viewer.
    • Exif.tools.
    • Propiedades del archivo del sistema operativo.

    Busca, si están disponibles, los siguientes campos:

    • Fabricante del dispositivo.
    • Modelo de cámara o teléfono.
    • Fecha y hora de captura.
    • Fecha de modificación.
    • Software utilizado.
    • Orientación.
    • Resolución.
    • Distancia focal.
    • Apertura.
    • Tiempo de exposición.
    • Sensibilidad ISO.
    • Uso del flash.
    • Coordenadas GPS.
    • Altitud.
    • Miniatura incrustada.
    • Autor o propietario.
    • Comentarios.
    • Copyright.

    Debes responder:

    1. ¿Qué metadatos conserva la fotografía?
    2. ¿Cuáles pueden ser útiles para la investigación?
    3. ¿Podrían haber sido modificados?
    4. ¿Existe alguna contradicción entre los metadatos y la imagen?
    5. ¿La fecha corresponde a la captura o a una modificación posterior?
    6. ¿Qué información privada podría revelar el archivo?

    Si aparecen coordenadas GPS, represéntalas en un mapa y compáralas con el contenido visible en la fotografía. No publiques coordenadas de domicilios particulares.


    Fase 3. Búsqueda inversa de imágenes

    Utiliza al menos dos servicios diferentes:

    • Google Lens.
    • Bing Visual Search.
    • TinEye.
    • Yandex Images.

    Compara los resultados obtenidos en cada buscador.

    Busca:

    • La misma fotografía.
    • Versiones recortadas.
    • Versiones con diferente resolución.
    • Publicaciones anteriores.
    • La posible fuente original.
    • Páginas donde se haya reutilizado.
    • Imágenes visualmente parecidas.
    • Posibles manipulaciones.

    Registra:

    BuscadorConsulta o imagen utilizadaResultado relevanteFecha del resultadoValoración

    Prueba también a realizar búsquedas con:

    • La imagen completa.
    • Un recorte de un edificio.
    • Un cartel o logotipo.
    • Un objeto singular.
    • El paisaje del fondo.
    • Una marca de agua.

    Indica cuál de los buscadores ha proporcionado mejores resultados y por qué.


    Fase 4. Extracción y análisis de texto

    Busca cualquier texto presente en la imagen:

    • Carteles.
    • Escaparates.
    • Camisetas.
    • Vehículos.
    • Señales.
    • Billetes.
    • Pantallas.
    • Documentos.
    • Nombres comerciales.

    Puedes utilizar herramientas OCR como:

    • Google Lens.
    • Microsoft Lens.
    • OCR.Space.
    • Tesseract.
    • Herramientas de OCR integradas en móviles u ordenadores.

    Después:

    1. Copia el texto detectado.
    2. Corrige posibles errores del OCR.
    3. Identifica el idioma.
    4. Traduce el texto si es necesario.
    5. Busca frases exactas entre comillas.
    6. Investiga nombres, dominios, teléfonos o establecimientos.
    7. Comprueba si el texto permite relacionar la fotografía con una ubicación o acontecimiento.

    No debes llamar a teléfonos, escribir a direcciones ni contactar con las personas encontradas.


    Fase 5. Geolocalización

    Intenta determinar:

    • País.
    • Región o provincia.
    • Ciudad.
    • Zona aproximada.
    • Punto concreto, únicamente si se trata de un lugar público.

    Puedes utilizar las siguientes pistas:

    Infraestructura

    • Forma y color de las señales.
    • Marcas de la carretera.
    • Semáforos.
    • Farolas.
    • Contenedores.
    • Bolardos.
    • Aceras.
    • Cableado.
    • Postes eléctricos.
    • Paradas de transporte.
    • Matrículas, sin publicar números completos.

    Entorno natural

    • Vegetación.
    • Tipo de suelo.
    • Montañas.
    • Costa.
    • Clima.
    • Estación del año.
    • Fauna visible.

    Entorno urbano

    • Arquitectura.
    • Materiales de construcción.
    • Numeración de edificios.
    • Comercios.
    • Monumentos.
    • Transporte público.
    • Logotipos municipales.

    Herramientas de apoyo

    • Google Maps.
    • Google Street View.
    • Google Earth.
    • OpenStreetMap.
    • Mapillary.
    • Wikimapia.
    • GeoHints.
    • Overpass Turbo, como opción avanzada.

    La ubicación debe justificarse comparando elementos visibles. No será suficiente escribir: “Google Lens dice que es Madrid”.


    Fase 6. Análisis de objetos y elementos

    Selecciona varios objetos relevantes y trata de identificarlos:

    • Modelo aproximado de vehículo.
    • Marca de un producto.
    • Tipo de uniforme.
    • Modelo de teléfono u ordenador.
    • Obra de arte.
    • Monumento.
    • Planta o animal.
    • Máquina o herramienta.
    • Cartel publicitario.
    • Logotipo.

    Para cada elemento indica:

    • Qué crees que es.
    • Cómo lo has buscado.
    • Qué fuentes has consultado.
    • Qué características coinciden.
    • Qué características no coinciden.
    • Nivel de confianza de la identificación.

    Fase 7. Análisis temporal o cronolocalización

    Intenta estimar cuándo fue tomada la fotografía.

    Puedes investigar:

    • Fecha incluida en los metadatos.
    • Carteles de eventos.
    • Publicidad temporal.
    • Obras en edificios.
    • Estado de la vegetación.
    • Ropa de las personas.
    • Meteorología.
    • Decoración navideña o festividades.
    • Modelos de vehículos.
    • Versiones de productos.
    • Posición del sol y dirección de las sombras.
    • Imágenes históricas de Street View.
    • Noticias o publicaciones relacionadas.

    Clasifica el resultado como:

    • Fecha exacta confirmada.
    • Intervalo temporal probable.
    • Estación del año estimada.
    • Fecha desconocida.

    Explica siempre qué evidencias apoyan la estimación.


    Fase 8. Análisis meteorológico

    Si has deducido una posible fecha y lugar, comprueba si el tiempo visible coincide con registros meteorológicos históricos.

    Observa:

    • Cielo despejado o cubierto.
    • Lluvia.
    • Nieve.
    • Suelo mojado.
    • Dirección aparente del viento.
    • Tipo de ropa.
    • Longitud de las sombras.
    • Estado de la vegetación.

    Este análisis no suele demostrar por sí solo una ubicación o fecha, pero puede servir para apoyar o descartar una hipótesis.


    Fase 9. Investigación del contexto

    Trata de averiguar por qué pudo tomarse la fotografía.

    Busca relaciones con:

    • Noticias.
    • Eventos.
    • Manifestaciones.
    • Conciertos.
    • Competiciones deportivas.
    • Ferias.
    • Inauguraciones.
    • Catástrofes naturales.
    • Obras públicas.
    • Publicaciones en páginas institucionales.
    • Bancos de imágenes.
    • Páginas turísticas.
    • Redes sociales públicas.

    No des por hecho que dos fotografías corresponden al mismo acontecimiento únicamente porque se parezcan.


    Fase 10. Comprobación de manipulación

    Analiza si la imagen presenta señales de edición o manipulación.

    Busca:

    • Sombras incoherentes.
    • Reflejos imposibles.
    • Diferencias de iluminación.
    • Bordes extraños.
    • Elementos repetidos.
    • Perspectiva incorrecta.
    • Texto deformado.
    • Zonas excesivamente borrosas.
    • Diferencias de compresión.
    • Metadatos de programas de edición.
    • Partes con distinta resolución.

    Puedes utilizar herramientas como:

    • Forensically.
    • FotoForensics.
    • ExifTool.
    • Ampliación y ajustes de contraste.
    • Búsqueda inversa de recortes.

    Las herramientas automáticas no proporcionan una prueba definitiva. Sus resultados deben interpretarse con prudencia.


    Fase 11. Esteganografía — ampliación avanzada

    Comprueba si la imagen podría contener información oculta.

    Posibles comprobaciones:

    • Archivos añadidos después del final de la imagen.
    • Texto incrustado.
    • Datos ocultos en los bits menos significativos.
    • Contenido comprimido dentro del archivo.
    • Información visible al separar canales de color.

    Herramientas posibles:

    • Binwalk.
    • Strings.
    • StegHide.
    • StegSeek.
    • Zsteg, para formatos compatibles.
    • Aperi’Solve.
    • CyberChef.

    Esta fase solamente debe realizarse sobre la imagen entregada para la práctica. No descargues ni ejecutes archivos desconocidos fuera del entorno controlado del laboratorio.


    6. Clasificación de los resultados

    Cada descubrimiento deberá etiquetarse de una de estas maneras:

    ClasificaciónSignificado
    Hecho confirmadoEstá demostrado mediante una evidencia fiable
    Muy probableExisten varias evidencias coincidentes
    PosibleHay algún indicio, pero no es suficiente
    HipótesisExplicación pendiente de comprobación
    DescartadoLas evidencias demuestran que no es correcto
    No determinadoNo se ha podido obtener información suficiente

    También asignarás un nivel de confianza:

    • Alto.
    • Medio.
    • Bajo.

    Ejemplo:

    La fotografía probablemente fue tomada en la Plaza Mayor de Salamanca. La arquitectura y el nombre visible de un comercio coinciden con Street View. Nivel de confianza: alto.


    7. Registro de evidencias

    Incluye una tabla general:

    IDDato investigadoHerramienta o fuenteResultadoClasificaciónConfianza
    E01Modelo del dispositivoExifTooliPhone 14Hecho confirmadoAlto
    E02CiudadStreet View y cartelValenciaMuy probableAlto
    E03FechaTipo de eventoMayo de 2024PosibleMedio

    Cada evidencia debe incluir:

    • Captura de pantalla.
    • Enlace a la fuente, cuando exista.
    • Fecha y hora de consulta.
    • Explicación del proceso.
    • Interpretación del resultado.

    Las capturas deben ocultar datos personales que no sean necesarios para la práctica.


    8. Informe final

    La entrega se realizará en un archivo README.md escrito en Markdown.

    Estructura obligatoria

    • Título de la investigación.
    • Nombre del alumno o equipo.
    • Curso.
    • Fecha.
    • Imagen reducida o censurada, si procede.

    2. Resumen ejecutivo

    Explicación breve de los principales descubrimientos.

    3. Descripción del archivo

    • Nombre.
    • Formato.
    • Tamaño.
    • Dimensiones.
    • Hash SHA-256.
    • Procedencia.

    4. Metodología

    Explicación de las fases realizadas y las herramientas empleadas.

    5. Análisis visual

    Observaciones iniciales e hipótesis.

    6. Análisis de metadatos

    Resultados obtenidos e interpretación.

    7. Búsqueda inversa

    Buscadores utilizados y resultados.

    8. Investigación del texto

    OCR, traducciones y búsquedas relacionadas.

    9. Geolocalización

    Proceso seguido para identificar el lugar.

    10. Análisis temporal

    Fecha o intervalo estimado.

    11. Otros análisis

    Objetos, contexto, meteorología, manipulación o esteganografía.

    12. Tabla de evidencias

    Listado completo de descubrimientos y nivel de confianza.

    13. Conclusiones

    Debes separar claramente:

    • Lo que has podido confirmar.
    • Lo que consideras probable.
    • Lo que no has podido determinar.
    • Las hipótesis descartadas.

    14. Reflexión sobre privacidad

    Responde:

    1. ¿Qué información sensible podría revelar una fotografía?
    2. ¿Qué datos eliminarías antes de publicarla?
    3. ¿Las redes sociales conservan siempre los metadatos?
    4. ¿Qué riesgos tiene publicar una imagen tomada en casa?
    5. ¿Cómo podría protegerse una persona antes de compartir fotografías?

    15. Fuentes consultadas

    Incluye todas las herramientas, páginas, mapas, artículos y documentos utilizados.


    9. Requisitos mínimos

    Para superar la práctica deberás realizar, como mínimo:

    • Inspección visual.
    • Cálculo del hash.
    • Análisis de metadatos.
    • Dos búsquedas inversas.
    • Extracción de texto, si existe.
    • Un intento razonado de geolocalización.
    • Análisis de al menos tres elementos visibles.
    • Tabla de evidencias.
    • Clasificación del nivel de confianza.
    • Reflexión sobre privacidad.
    • Documentación completa en Markdown.

    10. Opciones de ampliación

    Los alumnos que quieran profundizar podrán realizar una o varias de estas tareas:

    • Comparar los metadatos antes y después de enviar la fotografía por distintas plataformas.
    • Crear una copia sin metadatos y verificar su eliminación.
    • Analizar diferencias entre la imagen original y una versión publicada en una red social.
    • Utilizar Street View histórico.
    • Investigar la dirección de las sombras.
    • Comparar registros meteorológicos.
    • Buscar versiones anteriores de la fotografía.
    • Detectar posibles recortes o ediciones.
    • Utilizar herramientas de análisis forense.
    • Examinar si existe información oculta mediante esteganografía.
    • Elaborar una línea temporal de publicación.
    • Crear un mapa con los lugares candidatos.
    • Analizar cómo cambiarían los resultados si solamente se dispusiera de una captura de pantalla.

    11. Rúbrica orientativa

    ApartadoPorcentaje
    Organización, Markdown y presentación10 %
    Inspección visual y formulación de hipótesis10 %
    Análisis técnico y metadatos15 %
    Búsqueda inversa y localización de fuentes15 %
    OCR, objetos y pistas visuales10 %
    Geolocalización y análisis temporal15 %
    Evidencias, contraste y nivel de confianza15 %
    Conclusiones, privacidad y límites éticos10 %

    No se calificará únicamente la cantidad de información encontrada. Se valorará especialmente:

    • La calidad del razonamiento.
    • La capacidad de contrastar fuentes.
    • La documentación de los intentos fallidos.
    • La separación entre hechos e hipótesis.
    • El uso responsable de las herramientas.
    • La claridad de las conclusiones.

    12. Preguntas para la defensa

    El profesor podrá preguntar:

    • ¿Cuál ha sido la evidencia más importante?
    • ¿Qué dato parecía correcto inicialmente y luego descartaste?
    • ¿Qué herramienta te ha dado mejores resultados?
    • ¿Podrían estar manipulados los metadatos?
    • ¿Cómo has confirmado la ubicación?
    • ¿Qué grado de confianza asignas a tu conclusión?
    • ¿Qué otra explicación podría tener la evidencia?
    • ¿Qué dato no publicarías por motivos de privacidad?
    • ¿Podría otra persona reproducir tu investigación?
    • ¿Qué harías a continuación si dispusieras de más tiempo?

    13. Resultado esperado

    La investigación deberá finalizar con una conclusión prudente y verificable.

    No debes escribir:

    La foto fue tomada en Sevilla.

    Es preferible escribir:

    La fotografía fue tomada probablemente en Sevilla. El nombre del establecimiento visible coincide con un comercio situado en esa ciudad y la fachada puede verificarse en Street View. No se dispone de coordenadas GPS, por lo que la ubicación se clasifica como muy probable, con un nivel de confianza alto.

    En OSINT, reconocer que no existen pruebas suficientes también es un resultado válido.


    RETOS

    1. Plaza del Faro

    naliza el archivo reto_osint_plaza_del_faro.jpg y obtén toda la información posible sin consultar la solución del profesor.

    Debes estudiar:

    • Elementos visibles y posibles pistas engañosas.
    • Textos mediante OCR.
    • Lugar y momento aproximados.
    • Coherencia de luces y sombras.
    • Metadatos técnicos, EXIF, IPTC o XMP.
    • Posible contenido añadido u oculto en el archivo.
    • Diferencia entre hechos, indicios e hipótesis.

    2. Estación ferroviaria ficticia de montaña.

    Analiza reto_osint_estacion_valle_nevado.jpg sin consultar la soluciçon del profesor.

    Investiga los elementos visibles, los textos mediante OCR, la estación del año, la meteorología, la hora aproximada, los metadatos y cualquier contenido añadido al archivo.

    Debes diferenciar entre:

    • Evidencias confirmadas.
    • Indicios razonables.
    • Hipótesis pendientes.
    • Pistas engañosas.

    3. Bilbao

    Analiza el archivo reto_osint_avanzado_bilbao.png y reconstruye toda la cadena de evidencias.

    Objetivos

    • Geolocalizar la escena utilizando varias evidencias independientes.
    • Estimar fecha, hora, estación del año y condiciones meteorológicas.
    • Extraer textos mediante OCR y distinguir pistas válidas de señuelos.
    • Examinar la estructura interna del PNG y sus bloques de metadatos.
    • Detectar información codificada y explicar cómo se ha decodificado.
    • Comprobar si los canales de color contienen información oculta.
    • Detectar datos anexados después del final lógico de la imagen.
    • Construir y justificar la contraseña necesaria para recuperar la evidencia final.
    • Diferenciar entre indicio de edición y prueba de manipulación visual.

    Reglas

    No se proporciona una lista cerrada de herramientas. Cada decisión debe quedar documentada con comandos, capturas, resultados y nivel de confianza.

    El informe deberá incluir:

    1. Hash SHA-256 del archivo recibido.
    2. Análisis visual y OCR.
    3. Geolocalización razonada con al menos tres evidencias.
    4. Línea temporal y análisis de zona horaria.
    5. Inventario de bloques o chunks del PNG.
    6. Metadatos y cadenas encontradas.
    7. Análisis de esteganografía por canales y planos de bits.
    8. Búsqueda de firmas de archivos incrustados o anexados.
    9. Recuperación del código final.
    10. Separación entre hechos, hipótesis y pistas engañosas.

    No se considerará completa la práctica si únicamente se identifica la ciudad. El objetivo es reconstruir todas las capas del archivo.

  • 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:

    • GETPUT
    • PUTDELETE

    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.txtcrear sesión
    2. curl -b cookies.txtusar 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.txtguarda 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.txtcrear sesión
    2. curl -b cookies.txtusar 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.