STRIDE aplicado a una API en la nube

STRIDE aparece en la documentación del Threat Modeling Tool de Microsoft con estas seis categorías. Cada una se opone a una propiedad que se quiere mantener:

• Spoofing (suplantación) rompe la autenticidad: alguien se hace pasar por otro.
• Tampering (manipulación) rompe la integridad: alguien altera datos.
• Repudiation (repudio) rompe la responsabilidad demostrable: alguien niega lo que hizo y no hay con qué probarlo.
• Information Disclosure (divulgación) rompe la confidencialidad.
• Denial of Service (denegación de servicio) rompe la disponibilidad.
• Elevation of Privilege (elevación de privilegios) rompe la autorización: alguien consigue más permiso del que le toca.

Se aplica a cada elemento y a cada flujo del diagrama, preguntando por cada categoría si el diseño ya la cubre.

Autenticar no basta: una operación que recibe un identificador de objeto debe comprobar que el objeto pertenece a quien lo pide. Si solo comprueba que el token es válido, cualquier usuario autenticado puede pedir los objetos de otros cambiando el número. Es un caso típico de divulgación de información, y se ve en el contrato como un «no» en la columna de pertenencia.

Abre el laboratorio y lee api-de-pedidos.txt. Busca la operación que exige token pero no comprueba la pertenencia del objeto.

Un límite de peticiones por cliente es el control básico contra la denegación de servicio causada por picos, errores de un cliente o abuso. Una operación sin límite se puede llamar sin freno, y cada llamada cuesta cómputo, base de datos y dinero.

Cuenta en el contrato las operaciones cuyo límite de peticiones es «sin límite».

La combinación más delicada en un contrato es una operación que cambia datos y no pide ningún tipo de autenticación. Aquí caben a la vez suplantación y manipulación: quien llama no se identifica y lo que envía queda como verdad. Hay una operación que no se autentica porque es el inicio de sesión o el catálogo público y no modifica nada; esas no son el problema.

Busca la operación que modifica datos y no exige autenticación.

El repudio no ocurre por maldad del sistema, sino por falta de evidencia: si una operación no registra la identidad de quien la pidió, nadie puede demostrar después quién la hizo, y quien la hizo puede negarlo. El control típico no es técnico complicado: es dejar un registro con identidad, hora y resultado en un lugar que el usuario no pueda alterar.