La seguridad como requisito
En resumen: Las pruebas funcionales comprueban lo que puede hacer el cliente. La seguridad pregunta lo que NO debe poder hacer una persona que quiere hacer daño. Por eso un requisito de seguridad se escribe como un escenario con un usuario malintencionado: quién, qué intenta y qué debe pasar en su lugar.
Problema
Todas las pruebas pasan, y los pedidos son de todos
Un cliente abre su pedido: la dirección termina en /orders/1042. Por curiosidad cambia el número a 1041. Ve el pedido de otra persona: nombre, dirección, teléfono, lo que compró.
La tienda tiene 400 pruebas. Una de ellas comprueba que el cliente ve su propio pedido. Pasa. Ninguna prueba pregunta si ve también el de otro, porque ningún requisito dice que no debe.
La idea
La seguridad es un requisito como cualquier otro
En el modelo de calidad del primer módulo, la seguridad es una de las nueve características. Es lo bien que el sistema protege los datos y las acciones de las personas que no tienen derecho a ellos. La ISO/IEC 25010:2023 la divide en seis:
| Subcaracterística | En la tienda |
|---|---|
| Confidencialidad | El cliente ve solo sus propios pedidos. |
| Integridad | El precio no se puede cambiar desde el navegador. |
| No repudio | El cliente no puede afirmar que no hizo el pedido pagado. |
| Responsabilidad | Cada cambio de la dirección queda registrado: quién y cuándo. |
| Autenticidad | La persona que inició sesión es quien dice ser. |
| Resistencia | La tienda resiste 10 000 intentos de código promocional por minuto. |
Un requisito de seguridad se escribe y se acepta como cualquier requisito no funcional: con un comportamiento que se pueda comprobar, y con un límite.
Más precisamente, para curiosos
La resistencia es nueva en la edición de 2023: la capacidad de seguir haciendo el trabajo durante un ataque. La ISO/IEC 25010 describe qué se exige, no cómo se consigue. Cómo se consigue (contraseñas, sesiones, tokens, entrada no confiable) está en el módulo Seguridad para programadores del curso de ingeniería de software, con código.
Pruébalo
¿Qué parte de la seguridad?
La idea
El usuario malintencionado
Una historia dice lo que quiere el cliente honesto. La seguridad pregunta por otro rol: una persona que quiere hacer daño. Por eso para cada historia se escribe también la contraria:
- historia: «Como cliente quiero ver mis pedidos»;
- abuse case: «Como cliente malintencionado quiero ver el pedido de otro, para obtener su dirección y su teléfono».
El segundo dice lo que no debe ser posible y lo que pasa en su lugar. Se escribe con las mismas palabras que los criterios de aceptación:
# language: esCaracterística: Los pedidos del cliente
Escenario: Un cliente no ve el pedido de otro Dado que el cliente A ha iniciado sesión en su cuenta Y el pedido 1041 es del cliente B Cuando el cliente A abre el pedido 1041 Entonces ve «No existe ese pedido» Y no ve el nombre, la dirección ni el teléfono del cliente B Y el intento queda anotado en el registro«No existe ese pedido», no «No tienes acceso»: lo segundo le dice al atacante que el pedido existe.
Más precisamente, para curiosos
En inglés encontrarás los dos nombres: abuse case y misuse case, por «Misuse cases» de Sindre y Opdal (2005). OWASP mantiene listas de ataques típicos y de requisitos de seguridad comprobables para aplicaciones web (el Application Security Verification Standard, ASVS). El control de acceso roto (broken access control), como el pedido del otro cliente de aquí, es el número uno en la edición de 2021 del OWASP Top 10.
Pruébalo
¿Qué no debe ser posible?
La idea
Quién piensa como un atacante
Los escenarios malintencionados no son solo para un equipo de seguridad al final. Se encuentran de la manera más barata en la misma conversación donde se escriben las reglas de la historia. En el Example Mapping, junto a las reglas, los ejemplos y las preguntas, añade una pregunta más: «¿Quién querría abusar de esto, y cómo?»
- el código promocional: dos pedidos pagados a la vez; adivinar códigos;
- las devoluciones: el pedido de otra persona; devolver un producto más caro que el comprado;
- el carrito: un precio cambiado en el navegador; una cantidad negativa.
El riesgo ordena cuáles escribir primero: aquellos donde se pierde dinero o datos personales.
La aceptación funciona como con el desempeño: los requisitos se acuerdan antes con el negocio, y comprobarlos es parte de las pruebas de aceptación. Una prueba de penetración hecha por personas externas es un complemento útil. Pero encuentra lo que nadie pidió. Un requisito hace de la seguridad algo que se comprueba cada vez.
Más precisamente, para curiosos
CT-AcT v1.0, capítulo 4, incluye la seguridad en las pruebas de aceptación de requisitos no funcionales: los requisitos y las medidas se acuerdan de antemano, y el negocio decide qué riesgos acepta. Cómo se hace el modelado de amenazas de forma sistemática (por ejemplo STRIDE) y cómo se comprueban los ataques con código está en el módulo «Seguridad para programadores».
Ejercicio
Un requisito de seguridad
1. Los pedidos. Revisa el requisito de seguridad de los pedidos.
Marca los problemas del requisito y elige el tipo de cada uno.
Pulsa las palabras que son un problema; otra vez para quitar la marca. Con las flechas se pasa de palabra en palabra.
Los problemas del texto
- «protegida de los hackers» no verificable: ¿De qué ataques, y cómo se comprueba? El requisito tiene que nombrar la amenaza y el comportamiento: «un cliente no ve el pedido de otro, ni siquiera cambiando el número en la dirección».
- «usuarios autorizados» ambiguo: ¿Quién está autorizado para qué pedido? ¿El cliente solo para el suyo, el almacén para todos los pagados, soporte solo lectura? Sin esto, cualquiera que haya iniciado sesión puede resultar «autorizado».
- «cifradas con AES» solución en lugar de necesidad: Esto es una solución, y equivocada: las contraseñas no se cifran, se guardan con un hash lento y una sal. La necesidad es «la contraseña no se puede recuperar de la base de datos, ni siquiera si alguien la roba».
La última frase es un buen requisito: un comportamiento y lo que se registra. La primera es un deseo. La segunda no dice quién está autorizado para qué pedido, y justo ahí estaba el agujero del número en la dirección. La tercera es una solución, y equivocada: las contraseñas no se cifran, se guardan con un hash lento.
Test