El control de acceso roto
Subiendo desde la quinta posición, el 94% de las aplicaciones fueron evaluadas por 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 318,000. Las Enumeraciones de Debilidades Comunes (CWEs) notables incluyen CWE-200: Exposición de Información Sensible a un Actor No Autorizado, CWE-201: Inserción de Información Sensible en Datos Enviados, y CWE-352: Falsificación de Solicitudes Entre Sitios.
Descripción
El control de acceso impone políticas de manera que los usuarios no puedan actuar fuera de sus permisos previstos. Las fallas típicamente llevan a la divulgación no autorizada de información, modificación o destrucción de todos los datos, o la realización de una función comercial fuera de los límites del usuario. Las vulnerabilidades comunes en el control de acceso incluyen:
- Violación del principio de menor privilegio o denegación por defecto, donde el acceso solo debería concederse para capacidades, roles o usuarios específicos, pero está disponible para cualquiera.
- Evasión de controles de acceso al modificar la URL (manipulació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 solicitudes API.
- Permitir la visualización o edición de la cuenta de otra persona al proporcionar su identificador único (referencias inseguras a objetos directos).
- Acceso a la API con controles de acceso faltantes para POST, PUT y DELETE.
- Elevación de privilegios. Actuar como un usuario sin estar autenticado o actuar como un administrador cuando se está conectado como usuario.
- Manipulación de metadatos, como reproducir o manipular un token de control de acceso JSON Web Token (JWT), o una cookie o campo oculto manipulado para elevar privilegios o abusar de la invalidación de JWT.
- Configuración incorrecta de CORS permite el acceso a la API desde orígenes no autorizados/no confiables.
- Navegación forzada a páginas autenticadas como un usuario no autenticado o a páginas privilegiadas como un usuario estándar.
Cómo prevenir un control de acceso roto
El control de acceso solo es efectivo en código del lado del servidor de confianza o API sin servidor, donde el atacante no puede modificar el control de acceso o los metadatos.
- Excepto para recursos públicos, denegar por defecto.
- Implementar mecanismos de control de acceso una vez y reutilizarlos a lo largo de la aplicación, minimizando el uso de Cross-Origin Resource Sharing (CORS).
- Los controles de acceso deben imponer la propiedad de los registros en lugar de aceptar que el usuario pueda crear, leer, actualizar o eliminar cualquier registro.
- Los requisitos únicos de límites comerciales de la aplicación deben ser impuestos por modelos de dominio.
- Deshabilitar la lista de directorios del servidor web y asegurar que los metadatos de archivos (por ejemplo, .git) y archivos de respaldo no estén presentes dentro de las raíces web.
- Registrar fallos de control de acceso y alertar a los administradores cuando sea apropiado (por ejemplo, fallos repetidos).
- Limitar el acceso a la API y al controlador para minimizar el daño de las herramientas de ataque automatizadas.
- Los identificadores de sesión con estado deben ser invalidados en el servidor después del cierre de sesión. Los tokens JWT sin estado deben ser de corta duración para minimizar la ventana de oportunidad para un atacante. Para JWTs de mayor duración, se recomienda encarecidamente seguir los estándares OAuth para revocar el acceso.
Developers and QA staff should include functional access control unit and integration tests.
Ejemplos de Escenarios de Ataque
Escenario #1: La aplicación utiliza datos no verificados en una llamada SQL que accede a información de cuenta:
pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery();
Un atacante simplemente modifica el parámetro 'acct' del navegador para enviar el 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 #2: Un atacante simplemente navega forzadamente a URLs objetivo. 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 estas páginas, es un defecto. Si un usuario no administrador puede acceder a la página de administración, esto también es un defecto.