Visión general
Subiendo desde la quinta posición, el 94 % de las aplicaciones se probaron en busca de algún tipo de control de acceso roto con una tasa de incidencia promedio de 3,81 %, y tiene la mayor cantidad de ocurrencias en el conjunto de datos contribuido con más de 318k.
Las Enumeraciones de debilidades comunes (CWE) notables incluidas son CWE-200: Exposición de información confidencial a un actor no autorizado , CWE-201: Inserción de información confidencial en datos enviados y CWE-352: Falsificación de solicitud entre sitios.
Descripción
El control de acceso aplica una política tal que los usuarios no pueden actuar fuera de sus permisos previstos. Las fallas generalmente conducen a la divulgación, modificación o destrucción no autorizada de todos los datos oa la realización de una función comercial fuera de los límites del usuario. Las vulnerabilidades comunes de control de acceso incluyen:
-
Violación del principio de privilegio mínimo o denegación por defecto, donde el acceso solo debe otorgarse para capacidades, roles o usuarios particulares, pero está disponible para cualquiera.
-
Omitir las comprobaciones de control de acceso mediante la modificación de la URL (alteración de parámetros o navegación forzada), el estado interno de la aplicación o la página HTML, o mediante el uso de una herramienta de ataque que modifica las solicitudes de API.
-
Permitir ver o editar la cuenta de otra persona, al proporcionar su identificador único (referencias de objetos directos inseguros)
-
Acceso a la API sin controles de acceso para POST, PUT y DELETE.
-
Elevación de privilegio. Actuar como usuario sin haber iniciado sesión o actuar como administrador cuando se ha iniciado sesión como usuario.
-
Manipulación de metadatos, como la reproducción o manipulación de un token de control de acceso JSON Web Token (JWT), o una cookie o un campo oculto manipulado para elevar los privilegios o abusar de la invalidación de JWT.
-
La configuración incorrecta de CORS permite el acceso a la API desde orígenes no autorizados/no confiables.
-
Forzar la navegación a páginas autenticadas como usuario no autenticado o a páginas privilegiadas como usuario estándar.
Como prevenir
El control de acceso solo es efectivo en el código del lado del servidor confiable o API sin servidor, donde el atacante no puede modificar la verificación de control de acceso o los metadatos.
-
Excepto para los recursos públicos, denegar por defecto.
-
Implemente mecanismos de control de acceso una vez y reutilícelos en toda la aplicación, incluida la minimización del uso compartido de recursos de origen cruzado (CORS).
-
Los controles de acceso al modelo deben imponer la propiedad de los registros en lugar de aceptar que el usuario pueda crear, leer, actualizar o eliminar cualquier registro.
-
Los modelos de dominio deben hacer cumplir los requisitos de límite comercial de aplicaciones únicas.
-
Deshabilite la lista de directorios del servidor web y asegúrese de que los metadatos del archivo (p. ej., .git) y los archivos de copia de seguridad no estén presentes en las raíces web.
-
Registrar fallas de control de acceso, alertar a los administradores cuando sea apropiado (por ejemplo, fallas repetidas).
-
Tasa de límite API y acceso al controlador para minimizar el daño de las herramientas de ataque automatizado.
-
Los identificadores de sesión con estado deben invalidarse en el servidor después de cerrar la sesión. Los tokens JWT sin estado deberían ser de corta duración para minimizar la ventana de oportunidad para un atacante. Para los JWT de mayor duración, se recomienda encarecidamente seguir los estándares de OAuth para revocar el acceso.
Los desarrolladores y el personal de control de calidad deben incluir una unidad de control de acceso funcional y pruebas de integración.
Ejemplos de escenarios de ataque
Escenario n.º 1: la aplicación utiliza datos no verificados en una llamada SQL que accede a la información de la cuenta:
pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( );
Un atacante simplemente modifica el parámetro ‘acct’ del navegador para enviar cualquier número de cuenta que desee. Si no se verifica correctamente, el atacante puede acceder a la cuenta de cualquier usuario.
https://example.com/app/accountInfo?acct=notmyacct
Escenario n.º 2: un atacante simplemente fuerza las búsquedas a las URL de destino. Se requieren derechos de administrador para acceder a la página de administración.
https://example.com/app/getappInfo https://example.com/app/admin_getappInfo
Si un usuario no autenticado puede acceder a cualquiera de las páginas, es una falla. Si alguien que no es administrador puede acceder a la página de administración, esto es una falla.
Referencias
Lista de CWE mapeados
Más información: