Autenticación y autorización
El tema de la autenticación (AuthN) y la autorización (AuthZ) es extremadamente importante debido a la frecuencia de las vulnerabilidades que implican que cualquiera de ellas sea vulnerable. Dado que parecen aparecer con tanta frecuencia, eso suele significar que hay un poco de incertidumbre en torno a qué son o incluso a qué es lo que las causa.
Como recordatorio, cada término abarca lo siguiente:
- Autenticación: ¿Quién es el usuario?
- Autorización: ¿A qué debe tener acceso el usuario?
Los veremos por separado a continuación.
Autenticación (errores de identificación y autenticación)
La autenticación incorrecta puede cubrir una gran variedad de vulnerabilidades, como:
- La ausencia de autenticación en una página/punto final específicos
- Falta de protección contra los ataques de fuerza bruta (acumulación de credenciales)
- Procesos inseguros de recuperación de cuentas y contraseñas
- Generación, validación, caducidad, transmisión o almacenamiento de tokens de autenticación inseguros
- Validación incorrecta o faltante de que el usuario ha autenticado con 2FA (cuando corresponda)
El primer elemento de la lista (ausencia de autenticación) es, con mucho, el problema más común que se observa en la naturaleza. Muchas veces, un desarrollador tendrá que anotar o configurar de forma explícita el nivel de autenticación que va a requerir una página o un punto final, y ese paso puede pasarse por alto fácilmente.
Es una buena práctica garantizar que un sistema falle cerrada, en lugar de fallar al abrirse. Por lo tanto, en lugar de anotar en cada terminal la información de que necesitan una sesión de usuario autenticada, el valor predeterminado debería ser todo las rutas requieren una sesión de usuario autenticada, a menos que se haya anulado específicamente. Hacerlo puede reducir drásticamente el margen de error.
Autorización (control de acceso roto)
Los problemas de autorización pueden presentarse de diferentes maneras que son muy comunes:
- Referencias directas a objetos inseguras (IDOR)
- Falta el control de acceso a nivel de función (falta AuthZ)
- Escalamiento de privilegios (horizontal o vertical)
Referencias directas a objetos inseguras
Los objetos suelen tener identificadores (ID) únicos que se utilizan como clave para hacer referencia a ellos. Cuando un usuario envía una solicitud para ver un pedido, una cuenta o algo similar, normalmente contiene este ID. Se produce una «referencia directa a objetos insegura» cuando la aplicación no valida si el usuario (o la falta de él) debería poder acceder a ese objeto específico.
Falta el control de acceso a nivel de función
Otra vulnerabilidad muy común es la ausencia de comprobaciones de autorización para una página o un punto final (a diferencia de un objeto).
Según el marco utilizado, es habitual que los desarrolladores tengan que comprobar la autorización en el controlador o anotar el punto final y especificar los requisitos necesarios para llamar al punto final.
Desafortunadamente, estos pasos adicionales también son muy fáciles de olvidar, lo que a menudo explica cómo terminan ocurriendo algunas vulnerabilidades de autorización.
Recomendaciones
Predeterminado: cerrado en lugar de abierto
Tanto en el caso de la autenticación como en el de la autorización, es importante el principio de cerrar en lugar de abrir por defecto.
En función de su idioma o marco, es una buena práctica asegurarse de que la configuración predeterminada para todas las rutas de entrada a su aplicación requiera una sesión autenticada con los roles o permisos más altos posibles. Esto obliga al desarrollador a anular los requisitos de la ruta.
cs
//Asegúrese de que el comportamiento predeterminado es autenticar las solicitudes y comprobar si son de administrador
[Autenticar]
[Autorizar («Administrador»)]
clase pública SecureController: Controller
{
}
clase pública MyController: SecureController
{
//Anula el atributo Authorize heredado para permitir que cualquier usuario acceda a la página
[Autorizar («Usuario»)]
página pública showUserProfile () {
}
//Solo puede acceder un usuario administrador
página pública showAdminPage () {
}
//Anula el atributo Authenticate and Authorize para permitirme
[Permitir anónimo]
página pública showLoginPage () {
}
}
Haga cumplir las verificaciones de autorización en los servicios
Al acceder a los datos, es extremadamente importante asegurarse de que todos los accesos a los datos apliquen las comprobaciones de acceso y autorización pertinentes de manera uniforme. Por lo general, esto se logra mediante el uso de un servicio de dominio.
Más ejemplos
A continuación, presentamos una breve colección de ejemplos que muestran la diferencia entre la autenticación y la autorización seguras e inseguras.
C# - inseguro
Falta la autenticación
clase pública AdminController: Controller
{
//INSEGURO: no comprueba si el usuario ha iniciado sesión antes de mostrar una página de administración
página pública showAdminPage () {
}
}
Falta la autorización