Ejemplo del Modelo de Amenazas STRIDE de un Restaurante de Pizza
¿En qué estamos trabajando?
El proyecto que se está revisando es un restaurante de pizza en línea. Para ayudar a que la experiencia sea más atractiva, incluye un componente social donde las personas pueden ver qué pizzas han sido ordenadas y los clientes pueden rastrear su pizza a lo largo del proceso de creación. Por simplicidad, solo se aceptan tarjetas de crédito como forma de pago, solo se utiliza un procesador de pagos, y todas las pizzas se recogen en la tienda (sin entrega). El flujo típico de "camino feliz" incluye:
- El cliente construye su pizza en el sitio web a partir de una lista de ingredientes.
- Cuando termina de construir, el sitio web calcula el precio de la pizza consultando la base de datos.
- El cliente ingresa su información de pago en el sitio web y este se conecta al procesador de tarjetas de crédito para procesar el pago.
- El pedido de pizza se agrega a la base de datos.
- Para el componente social, una vez que el pedido está en la base de datos, también se muestra en la página de inicio del sitio web con el nombre de usuario del usuario.
- Los pizzaiolos en la tienda de pizzas consultan la base de datos y comienzan a construir la pizza a través de varias estaciones, incluyendo masa, salsa, queso, ingredientes, horneado y empaque. Un trabajador de pizza está en cada estación.
- En cada paso, el pizzaiolo actualiza la base de datos con el progreso actual. A medida que la base de datos se actualiza, el rastreador de pizzas en el sitio web también se actualiza, mostrando el progreso actual y quién ha completado ese paso.
- El cliente recoge su pizza una vez que está lista.
¿Qué puede salir mal?
Recordatorios de STRIDE
Amenaza mnemotécnica | Definición | Pregunta |
---|---|---|
Suplantación | La capacidad de suplantar a otro usuario o componente del sistema para obtener acceso no autorizado. | ¿El usuario es quien dice ser? |
Teviceo | Alteración no autorizada de datos o código. | ¿Se ha modificado de alguna manera el código o los datos? |
Repudiación | La capacidad de un sistema o usuario para negar haber realizado una determinada acción. | ¿Hay suficientes datos para "probar" que el usuario tomó la acción si la negara? |
Información confidencial | El compartir en exceso datos que se espera que se mantengan en privado. | ¿Hay algún lugar donde se compartan datos excesivos o no se implementen controles adecuados para proteger la información privada? |
Denegación de servicio | La capacidad de un atacante para afectar negativamente la disponibilidad de un sistema. | ¿Puede alguien, sin autorización, impactar la disponibilidad del servicio o negocio? |
Elevar privilegios | La capacidad de un atacante para obtener privilegios y roles adicionales más allá de los que inicialmente se le otorgaron. | ¿Hay formas para que un usuario, sin la autenticación adecuada (verificación de identidad) y autorización (verificación de permiso) obtenga acceso a privilegios adicionales, ya sea por medios estándar (normalmente legítimos) o ilegítimos? |
Tabla de amenazas
Amenaza | Problemas |
---|---|
Suplantación | Suplantar.1 - (Paso 1) Un atacante podría enviar un pedido como otro usuario. Suplantar.2 - (Paso 3) Si la información de la tarjeta de crédito se almacena en el perfil del usuario, se podría enviar automáticamente un pedido de pizza suplantado al procesador de tarjetas de crédito, haciendo que otro usuario pague por el pedido de pizza. Suplantar.3 - (Paso 7) Un atacante "dispara" actualizaciones erróneas de pizza al sitio web, erosionando la confianza en los datos y el proceso. |
Tampering | Alterar.1 - (Paso 2) Un atacante envía su propia consulta inyectando SQL en la consulta de la base de datos. Alterar.2 - (Paso 2) Un atacante modifica los valores devueltos de su consulta de precio de pizza y se otorga un descuento. Alterar.3 - (Paso 4) Un atacante construye y cotiza una pizza "barata", pero después del pago, envía un pedido mucho más caro. Alterar.4 - (Paso 6) Un pizzaiolo modifica un pedido en la estación de otra persona para hacerlo parecer incompetente. |
Repudiación | Repudiar.1 - (Paso 3) Un atacante coloca un pedido pero refuta el cargo de la tarjeta de crédito. Repudiar.2 - (Paso 4) Un atacante envía un pedido para otro usuario directamente a la base de datos sin nunca interactuar con el resto del sistema. Repudiar.3 - (Paso 4) Se pueden enviar varios pedidos válidos con el mismo token de procesamiento de tarjeta de crédito. |
Información confidencial | Info.1 - (Paso 4) Un atacante cultiva IDs de pedido secuenciales para interactuar con ellos. Info.2 - (Paso 2) Un atacante puede consultar más información y acceder a la información de la tarjeta de crédito almacenada. Info.3 - (Paso 4) - Un atacante puede cultivar códigos de cupón secuenciales. Info.4 - (Paso 5) - Cuando el sitio web se actualiza con el último pedido de pizza, detrás de escena, devuelve todo el pedido de pizza pero solo muestra la pizza. Un atacante puede cultivar PII de la página del pedido de pizza. |
Denegación de servicio | DoS.1 - Un atacante apunta al sitio web para derribarlo. DoS.2 - (Paso 1) Un atacante identifica y llama repetidamente al endpoint de la API para crear un nuevo usuario. DoS.3 - (Paso 4) Un atacante envía pedidos en masa para bloquear el proceso de pedidos. DoS.4 - (Paso 2) Un atacante envía pedidos en masa para bloquear el proceso de precios. |
Elevar privilegios | Elevar.1 - Un atacante puede engañar al sitio web de pizza para que muestre la interfaz de administración en el sitio web. Elevar.2 - (Paso 6) Un pizzaiolo usa el acceso de su gerente para eliminar pedidos de pizza para que no tenga que hacerlos. |
¿Qué vamos a hacer al respecto?
Amenaza | Problemas |
---|---|
Suplantación | Suplantar.1 - (Paso 1) Un atacante podría enviar un pedido como otro usuario. S1R1 - Asegúrate de que se requiera autenticación adecuada antes de que un visitante del sitio web esté autorizado a enviar un pedido. Asegúrate de que la información de ubicación del perfil de usuario se utilice para la información del pedido. Suplantar.2 - (Paso 3) Si la información de la tarjeta de crédito se almacena en el perfil del usuario, se podría enviar automáticamente un pedido de pizza suplantado al procesador de tarjetas de crédito, haciendo que otro usuario pague por el pedido de pizza. S2R1 - Asegúrate de que todos los datos necesarios para procesar un pago con tarjeta de crédito no se almacenen juntos en el perfil del cliente. Todos los datos deben estar encriptados en reposo y en tránsito. Una forma de alcanzar el objetivo final sería usar el CCV como solo datos efímeros y capturarlos cada vez que se use la tarjeta de crédito. El CCV nunca debe ser almacenado. Suplantar.3 - (Paso 7) Un atacante "dispara" actualizaciones erróneas de pizza al sitio web, erosionando la confianza en los datos y el proceso. S3R1 - Asegúrate de que las actualizaciones de los estados de pizza se realicen a través de un estilo PULL donde el sitio web consulta un servidor en el que confía para obtener actualizaciones del estado de la pizza. S3R2 - Alternativamente, permitir actualizaciones de estilo PUSH del servidor de pizza, pero solo exponer ese endpoint de API internamente. |
Tampering | Alterar.1 - (Paso 2) Un atacante envía su propia consulta inyectando SQL en la consulta de la base de datos. T1R1 - Asegúrate de que todas las consultas para todas las búsquedas en la base de datos que utilicen datos de usuarios no confiables se realicen con declaraciones preparadas y que todas las entradas estén correctamente codificadas. Alterar.2 - (Paso 2) Un atacante modifica los valores devueltos de su consulta de precio de pizza y se otorga un descuento. T2R1 - La información de precios devuelta por el servidor de la base de datos solo debe usarse con fines de visualización. El precio debe calcularse en el servidor por separado cuando se aplique el cargo, y la información de seguimiento financiero solo debe confiar en el pedido de pizza específico que sea personalizado. Todos los cálculos para el precio deben realizarse por separado en el back-end. Alterar.3 - (Paso 4) Un atacante construye y cotiza una pizza "barata", pero después del pago, envía un pedido mucho más caro. T3R1 - El pedido de pizza que se estableció un precio debería hacerse directamente desde el servidor de la base de datos hasta el procesador de tarjeta de crédito. Esto previene cotizar una pizza pero ordenar otra. Alterar.4 - (Paso 6) Un pizzaiolo modifica un pedido en la estación de otra persona para hacerlo parecer incompetente. T4R1 - Este es un tipo de ataque de "amenaza interna". Cada pizzaiolo debería tener una forma de autenticarse en su estación, de modo que todas las acciones sean rastreables y auditable. Un enfoque podría ser que cada pizzaiolo tuviera una tarjeta de acceso que lo autentique en su estación de pizza. La tarjeta de acceso debe estar conectada al pizzaiolo, de tal manera que si se va, la tarjeta se elimine automáticamente. La tarjeta de acceso debe estar presente para que se puedan enviar cambios al servidor de base de datos. |
Repudiación | Repudiar.1 - (Paso 3) Un atacante coloca un pedido pero refuta el cargo de la tarjeta de crédito. R1R1 - Asegúrate de que cuando se crea un nuevo perfil de usuario, se genere un par de claves públicas/privadas. Estas deben usarse para firmar y validar mensajes entre el usuario y el servidor. Cuando se envía un pedido de pizza al servidor, este calcula el hash del pedido junto con una sal secreta y devuelve el hash salado al usuario original. El usuario original firma el hash salado con su clave privada y envía el paquete firmado de vuelta al servidor. El servidor debe almacenar el pedido, la sal secreta (a través de persistencia en el entorno de proceso), el hash salado y el paquete firmado. Si un usuario refuta el pedido, el servidor puede verificar simplemente que la clave pública del usuario descifra correctamente el paquete firmado. Repudiar.2 - (Paso 4) Un atacante envía un pedido para otro usuario directamente a la base de datos sin nunca interactuar con el resto del sistema. R2R1 - Asegúrate de que las presentaciones de pedidos requieran un token de sesión JWT activo. Asegúrate de que el tiempo de espera de la sesión refleje los patrones reales de uso esperados (no se tarda 7 horas en pedir una pizza). R2R2 - Asegúrate de que un pedido de pizza haya sido correctamente cotizado al recalcular el precio de la pizza en el momento de la presentación. Repudiar.3 - (Paso 4) Se pueden presentar múltiples pedidos válidos con el mismo token de procesamiento de tarjeta de crédito. R3R1 - Asegúrate de que los tokens de procesamiento de tarjetas de crédito sean lo suficientemente efímeros. R3R2 - Trabaja con el procesador de tarjetas de crédito para invalidar el token después de que se confirme la transacción. |
Información confidencial | Info.1 - (Paso 4) Un atacante cultiva IDs de orden secuenciales para interactuar con ellos. I1R1 - Asegúrate de que todos los IDs (IDs de pedidos, IDs de usuarios, IDs de transacciones, etc.) utilicen GUIDs no secuenciales y difíciles de adivinar. Info.2 - (Paso 2) Un atacante puede consultar más información y acceder a la información de la tarjeta de crédito almacenada. I2R1 - Utiliza un marco de filtrado como CASL para limitar qué información está disponible a través de consultas. I2R2 - Asegúrate de que la información de la tarjeta de crédito se almacene en un contexto separado y no sea de fácil acceso (se segmenta la red para permitir que solo acciones específicas conocidas lleguen al entorno de la tarjeta de crédito). I2R3 - Asegúrate de que se utilice la tokenización para ofuscar la información de la tarjeta de crédito. Un ejemplo podría ser el siguiente: 1. El usuario envía su pedido y se lleva a cabo el proceso de firma. 2. El sitio web solicita al usuario su CVV y lo envía al servidor de la base de datos. 3. El servidor de la base de datos luego envía el precio del pedido que han confirmado junto con un CVV y un identificador de número de tarjeta de crédito al endpoint de la API para enviar una solicitud de pago. 4. La llamada a la API de la solicitud de pago envía una solicitud de pago al procesador de tarjetas de crédito. 5. Cuando se devuelve el éxito, la llamada de la API se resuelve como pagada. Este método nunca expone la tarjeta de crédito al servidor de la base de datos o al servidor web. Info.3 - (Paso 4) - Un atacante puede cultivar códigos de cupón secuenciales. I3R1 - Asegúrate de que los códigos de cupón no sean secuenciales. I3R2 - Alternativamente, si la disponibilidad del código de cupón es más importante (es decir, se utiliza para atraer tráfico y hay poca preocupación por la seguridad), asegúrate de incluir el precio de descuento en los modelos de proyección de costos. Además, considera establecer un número máximo de cupones a utilizar para proporcionar un límite superior para los costos en caso de abuso. Info.4 - (Paso 5) - Cuando el sitio web se actualiza con el pedido de pizza más reciente, tras bambalinas, devuelve todo el pedido de pizza pero solo muestra la pizza. Un atacante puede obtener PII de la página del pedido de pizza. I4R1 - Asegúrate de que la consulta utilizada para presentar los datos en la página del pedido de pizza solo devuelva los datos estrictamente necesarios para llevar a cabo la actualización en la página de estado en contexto. Si la dirección, el correo electrónico o el número de CC no son necesarios para llevar a cabo la actualización del estado de una pizza, no incluyas esos campos en la consulta. |
Denegación de Servicio | DoS.1 - Un atacante apunta al sitio web para derribarlo. D1R1 - Asegúrate de que el sitio web siga alguna estrategia de mitigación para la protección contra DDoS. Esto podría incluir CloudFlare DDoS, Cloudflare WAF, F5 DDoS Mitigation, u otros. D1R2 - Como alternativa o adicional, se debe aplicar limitación de tasa a nivel del servidor para limitar la capacidad de imponer un ataque DDoS. DoS.2 - (Paso 1) Un atacante identifica y llama repetidamente al punto final de la API para crear un nuevo usuario. D2R1 - Configura limitación de tasa para llamadas sensibles a la API (como esta). Asegúrate de que CAPTCHA u otras prevenciones contra bots estén en su lugar para dificultar el acceso. DoS.3 - (Paso 4) Un atacante envía pedidos masivos para bloquear el proceso de pedido. D3R1 - Configura Cloudflare DDoS y Cloudflare WAF. D3R2 - Configura limitación de tasa para la llamada a la API para enviar pedidos. D3R3 - Configura encabezados X-Forwarded-For en el servidor para habilitar la limitación de tasa por IP de origen. D3R4 - Configura limitación de tasa por IP. D3R5 - Asegúrate de que el sitio web pueda identificar grandes cantidades de pedidos de un solo usuario y limitarlo a un valor apropiado. DoS.4 - (Paso 2) Un atacante envía pedidos masivos para bloquear el proceso de precios. D4R1 - Las mismas mitigaciones se aplican aquí que para DoS.3. D4R2 - Además, asegúrate de que el sistema de precios también identifique grandes cantidades de búsquedas de precios o re-búsquedas de precios procedentes de las mismas IPs. |
Elevar privilegio | Elevación.1 - Un atacante puede engañar al sitio web de pizza para que muestre la interfaz de administración en el sitio web. E1R1 - Asegúrate de que la interfaz administrativa del sitio web se presente en una URI diferente. E1R2 - Asegúrate de que la invocación de tareas sensibles o administrativas sea realizada por administradores identificados a partir de una búsqueda de la sesión del usuario en el servidor. Elevación.2 - (Paso 6) Un pizzero utiliza el acceso de su gerente para eliminar pedidos de pizza para no tener que hacerlos. E2R1 - Asegúrate de que la tarjeta clave que otorga acceso no esté desatendida sin el gerente presente. |
¿Hicimos un buen trabajo?
-
¿Se ha referenciado el diagrama de flujo de datos desde que fue creado?
- Sí, fue invaluable en la construcción del perfil de amenaza.
-
¿El modelo STRIDE descubrió algún nuevo problema o preocupación de diseño que no había sido abordado o pensado anteriormente?
- Sí. Nos dimos cuenta de que necesitábamos cambiar el esquema de autenticación de la estación de pizza. Además, reformulamos las consultas para la exhibición social del pedido de pizza para entregar solo la información necesaria.
-
¿Los tratamientos identificados en la sección "¿Qué vamos a hacer al respecto?" abordaron adecuadamente los problemas identificados?
- Sí. Estamos continuando monitoreando estos en caso de que se necesiten mitigaciones adicionales.
-
¿Se han encontrado problemas adicionales después del modelo de amenaza?
- Aún ninguno. A medida que se agreguen nuevas características, el modelo de amenaza se actualizará para reflejar las nuevas adiciones.
-
¿Algún pensamiento o perspectiva adicional sobre el proceso de modelado de amenazas que podría ayudar a mejorarlo la próxima vez?
- Ninguno.