Modelado de amenazas con STRIDE: un primer modelo de una aplicación web

#Qué es STRIDE

STRIDE es una lista de seis categorías de amenaza: suplantación de identidad (spoofing), manipulación (tampering), repudio (repudiation), revelación de información (information disclosure), denegación de servicio (denial of service) y elevación de privilegios (elevation of privilege). Microsoft lo usa en su guía de modelado de amenazas. STRIDE no encuentra amenazas por usted. Le da seis preguntas que hacerle a cada parte de un diseño, para que el resultado no dependa de lo que recuerde en una tarde cualquiera.

El método va antes que la mayoría de las herramientas de seguridad. Un escáner revisa un sistema que ya está en marcha. Un modelo de amenazas revisa el plan: qué componentes existen, qué datos pasan entre ellos y en qué punto cambia el nivel de confianza. Se puede empezar con papel y lápiz antes de que exista cualquier código.

#Por qué importa

Muchas fallas de seguridad en aplicaciones web son fallas de diseño. El servidor confía en un precio que envió el navegador. Una ruta de administración comprueba que el usuario inició sesión, pero nunca comprueba que sea administrador. Un archivo de registro guarda tokens de sesión. Cada una de estas fallas se puede corregir en el código, pero el código suele reflejar el diseño que recibió. El problema empieza en el diseño.

La OWASP Threat Modeling Cheat Sheet dice lo mismo. Antes de saber qué amenazas aplican, hace falta entender los flujos de datos, los límites de confianza y las demás partes del sistema. Un modelo de amenazas deja escrito ese entendimiento en una forma que otras personas pueden revisar.

#Los bloques básicos

#Diagramas de flujo de datos

Un diagrama de flujo de datos (DFD) tiene cuatro tipos de elemento:

• Entidades externas: personas o sistemas fuera de su control, como el navegador de un cliente.
• Procesos: código que recibe, modifica o envía datos, como una API web.
• Almacenes de datos: lugares donde los datos quedan guardados, como una base de datos o un archivo de registro.
• Flujos de datos: flechas que muestran datos que pasan entre los otros tres.

Mantenga el diagrama en una sola página. Si necesita una segunda, probablemente está dibujando dos sistemas.

#Límites de confianza

Un límite de confianza es la línea por la que los datos pasan de un lugar con cierto nivel de confianza a otro con un nivel distinto. Su servidor está dentro de la línea. El navegador está fuera, porque quien lo usa puede cambiar cualquier solicitud antes de que llegue a usted. Todo flujo que cruza un límite necesita validación, y la mayoría de las amenazas interesantes están en esos cruces. La OWASP Cheat Sheet llama a estos cruces posibles puntos de ataque.

Los límites no son solo bordes de red. Un proceso que corre con otra cuenta del sistema operativo, un proveedor de identidad externo o una base de datos que acepta conexiones de varios servicios pueden ser, cada uno, un límite.

#Las seis categorías

Cada categoría rompe una propiedad de seguridad.

Estas descripciones coinciden con la documentación de modelado de amenazas de Microsoft. La suplantación, por ejemplo, consiste en usar la información de autenticación de otro usuario.

No todas las categorías aplican a todos los elementos. Un mapa inicial habitual, que usan muchas herramientas de modelado, es este: las entidades externas reciben spoofing y repudiation; los procesos reciben las seis; los almacenes reciben tampering, repudiation, information disclosure y denial of service; los flujos reciben tampering, information disclosure y denial of service. Trate el mapa como un recordatorio, no como una regla. Si una categoría le parece irrelevante para un elemento, anote por qué, para que quien revise pueda cuestionarlo.

#Cómo funciona, paso a paso

1. Defina el alcance. Escriba una frase que indique el sistema, la versión y qué queda fuera. "La aplicación Juice Shop y su API, ejecutándose en local, sin incluir el sistema operativo del host" basta.
2. Dibuje el diagrama de flujo de datos. Agregue las entidades externas, los procesos, los almacenes y los flujos. Indique en cada flujo qué datos transporta.
3. Dibuje los límites de confianza. Ponga una línea en cada punto donde cambia la confianza.
4. Revise cada elemento con las categorías. Para cada categoría que aplique, haga la pregunta de la tabla y escriba la amenaza en una frase corta. Una forma útil es decir quién hace qué y qué sale mal: "Un token de sesión robado permite que un atacante haga pedidos como si fuera el cliente."
5. Elija una respuesta para cada amenaza: una mitigación, un riesgo aceptado con una razón escrita o una transferencia a otra parte. Una amenaza sin respuesta sigue abierta.
6. Guarde el modelo en control de versiones, junto al código, y fije una fecha para revisarlo.

En una funcionalidad pequeña, los pasos del 1 al 5 pueden tomar una hora. La primera vez, espere rehacer el diagrama al menos una vez. Es normal.

#Manos a la obra: modelar OWASP Juice Shop

OWASP Juice Shop es una aplicación web intencionalmente insegura para practicar. En este laboratorio usted no la explota. Dibuja su diseño, enumera amenazas y escribe mitigaciones. Las amenazas salen de leer el diseño, no de atacar la aplicación.

Ejecute el laboratorio solo en su propia máquina, con el acceso limitado a 127.0.0.1. Si todavía no preparó el contenedor, siga primero OWASP Juice Shop con Docker.

#Requisitos previos

Necesita:

• Docker, para ejecutar el contenedor del laboratorio
• Git, para registrar el modelo
• OWASP Threat Dragon para escritorio, gratuito y de código abierto, desde la página de releases: https://github.com/OWASP/threat-dragon/releases
• Una carpeta vacía para el repositorio del laboratorio

En la máquina de prueba usada para este artículo, git --version mostró:

git version 2.49.0.windows.1

#Paso 1: levantar el laboratorio

docker run --rm -d --name juice-shop-lab -p 127.0.0.1:3000:3000 bkimminich/juice-shop

La parte -p 127.0.0.1:3000:3000 publica el puerto solo en la interfaz de loopback, así que otros equipos de su red no pueden alcanzarlo.

Confirme que la aplicación web responde:

curl -sI http://127.0.0.1:3000/ | head -n 1

En la máquina de prueba, la primera línea de la salida fue:

HTTP/1.1 200 OK

Confirme que la API responde. Esta es una solicitud GET sencilla para una lista de productos:

curl -s -o /dev/null -w "products %{http_code} %{content_type}\n" http://127.0.0.1:3000/api/Products

Salida:

products 200 application/json; charset=utf-8

Revise la versión que informa la aplicación:

curl -s http://127.0.0.1:3000/rest/admin/application-version

Salida:

{"version":"20.3.0"}

Esa versión es la que informó la imagen el 8 de noviembre de 2026 en la máquina de prueba. Su imagen puede informar otra. Anote la versión que vea, porque el modelo de amenazas describe una versión concreta.

#Paso 2: instalar Threat Dragon

Descargue el build de escritorio para su sistema operativo desde la página de releases, instálelo y ábralo. Los nombres de los menús de los pasos siguientes no se comprobaron con un build de Threat Dragon para este artículo, y cambian entre versiones. Use los nombres que muestre su build.

#Paso 3: dibujar el diagrama

Cree un modelo de amenazas nuevo y agregue estos elementos:

• Un actor externo llamado Browser, descrito como "navegador del cliente, fuera de nuestro control".
• Un proceso llamado Juice Shop web y API, descrito como "aplicación web y API en 127.0.0.1:3000".
• Un almacén de datos llamado base de datos SQLite, descrito como "archivo de datos de la aplicación".
• Dos flujos del navegador al proceso: solicitudes HTTP y, de vuelta, respuestas HTTP.
• Dos flujos del proceso al almacén: consultas SQL y las filas devueltas.
• Un límite de confianza que separe el navegador del proceso y del almacén.

El modelo debería verse así:

Browser (actor externo)
   |  solicitudes y respuestas HTTP
   v
=================== límite de confianza ===================
   Juice Shop web y API (proceso, 127.0.0.1:3000)
   |  consultas SQL y filas
   v
Base de datos SQLite (almacén de datos)

El esquema de texto es solo una guía. El archivo real es el que guarda Threat Dragon.

El modelo usa SQLite como almacén de datos. Revise la documentación del proyecto para la versión que ejecute, porque los detalles de almacenamiento pueden cambiar entre releases.

#Paso 4: enumerar amenazas por elemento

Aplique el mapa inicial que vio antes. El navegador es una entidad externa, así que recibe spoofing y repudiation. Cada flujo del navegador a la API recibe tampering, information disclosure y denial of service. El proceso de la API recibe las seis categorías. El almacén SQLite recibe tampering, repudiation, information disclosure y denial of service.

Aquí hay un ejemplo por categoría. Un modelo real tendrá más filas para cada elemento.

Use la documentación del proyecto para ver qué debilidades incluye su versión a propósito. Describa cada amenaza en términos de diseño. No escriba pasos de explotación en el modelo. Este laboratorio no necesita tráfico de ataque.

En Threat Dragon, agregue cada amenaza al elemento al que pertenece, con un título, una descripción y la mitigación. Si su build tiene un campo de estado, márquelo como abierto para las mitigaciones que todavía no implementó.

#Paso 5: exportar y registrar el commit

Exporte el modelo como JSON desde el menú de archivo y llame al archivo juice-shop-threat-model.json. Después, en la carpeta del laboratorio:

git init
cp /ruta/a/juice-shop-threat-model.json .
git add juice-shop-threat-model.json && git commit -m "First STRIDE model"

Git muestra un resumen corto con el nombre de la rama y el mensaje del commit. El texto exacto depende de su versión de Git y de la configuración. Si Git pide una identidad, defínala con git config user.name y git config user.email, y haga el commit con su propio nombre.

Antes de hacer el commit, lea el archivo. No debe contener nombres de host reales, tokens ni datos de clientes. Este modelo usa solo 127.0.0.1.

Detenga el laboratorio al terminar:

docker stop juice-shop-lab
curl -s -o /dev/null -w "%{http_code}\n" --max-time 2 http://127.0.0.1:3000/

En la máquina de prueba, la salida fue:

juice-shop-lab
000

La primera línea viene de docker stop. El 000 significa que curl no recibió respuesta del puerto, o sea, el laboratorio está apagado.

#Un modelo de amenazas es un documento vivo

Un modelo de amenazas describe un diseño el día en que se escribió. Cuando el diseño cambia, el modelo queda desactualizado. Algunos disparadores comunes:

• un endpoint nuevo o un rol nuevo
• un proveedor de inicio de sesión nuevo
• una base de datos movida a otro servicio, lo que agrega un flujo de red y, posiblemente, un nuevo límite de confianza
• un tipo de dato nuevo, como datos de pago o datos personales
• una dependencia que ahora corre con más acceso que antes

El Threat Modeling Manifesto dice que el modelado de amenazas debe seguir los cambios de diseño, en iteraciones, cada una limitada a una parte manejable del sistema. En la práctica, eso significa tres hábitos. Mantenga el archivo JSON en el repositorio, junto al código. Agregue una pregunta de revisión a los pull requests que tocan autenticación, flujos de datos o integraciones externas: ¿el modelo sigue coincidiendo con el sistema? Registre la fecha y la versión de la aplicación que describe el modelo. Las amenazas marcadas como mitigadas siguen siendo un historial útil, así que consérvelas.

#Errores comunes

• Dibujar el sistema que le gustaría tener. Dibuje el que realmente corre, con el proxy, la caché y los trabajos en segundo plano.
• Empezar por toda la empresa. Empiece por una funcionalidad y un flujo, y luego amplíe.
• Listar amenazas sin mitigaciones ni responsables. Una amenaza sin respuesta sigue abierta.
• Escribir una mitigación como "usar cifrado" sin detalle. Diga qué está protegido, dónde y cómo lo verifica alguien.
• Olvidar las flechas. La mayoría de las amenazas viven en los flujos y en los límites, no dentro de las cajas.
• Tratar las seis categorías como una lista de tareas por completar. Son recordatorios. El resultado útil es una decisión para cada amenaza.
• Probar sistemas que no le pertenecen para confirmar una amenaza. El modelo no necesita pruebas en vivo, y cualquier prueba pertenece a su laboratorio autorizado.

#Cómo seguir

• Lea juntos la lista de amenazas de Microsoft y la OWASP Cheat Sheet. Anote en qué coinciden las categorías y en qué difiere la redacción.
• Modele una funcionalidad de un proyecto que mantenga, como el inicio de sesión o la recuperación de contraseña.
• Continúe con el OWASP Top 10 para desarrolladores. Enumera las debilidades web con las que se encontrará con más frecuencia, y encajan bien en las filas de su tabla.
• Sepa que existen otros métodos, como los árboles de ataque y los métodos centrados en la privacidad, para preguntas que STRIDE responde de forma menos directa.

#Fuentes

• Microsoft: Threat modeling tool threats
• OWASP Threat Modeling Cheat Sheet
• OWASP Threat Dragon
• Threat Modeling Manifesto
• OWASP Juice Shop project
• Docker port publishing