OWASP Top Ten 2017 (es)

A5:2017-Pérdida de Control de Acceso

 Languages: en de [es]
Agente de amenaza / Vector de ataque Debilidades de seguridad Impacto
Específico
de la Apl.		 Explotabilidad: 2 Prevalencia: 2 Detectabilidad: 2 Técnico: 3 ¿Negocio?
La explotación del control de acceso es una habilidad esencial de los atacantes. Las herramientas SAST y DAST pueden detectar la ausencia de controles de acceso pero, en el caso de estar presentes, no pueden verificar si son correctos. Es detectable utilizando medios manuales o de forma automática en algunos marcos de trabajo que carecen de controles de acceso.
Las debilidades del control de acceso son comunes debido a la falta de detección automática y a la falta de pruebas funcionales efectivas por parte de los desarrolladores de aplicaciones.
La detección de fallas en el control de acceso no suele ser cubierto por pruebas automatizadas, ni estáticas ni dinámicas.
El impacto técnico incluye atacantes anónimos actuando como usuarios o administradores; usuarios que utilizan funciones privilegiadas o crean, acceden, actualizan o eliminan cualquier registro.
El impacto al negocio depende de las necesidades de la aplicación y de los datos.
¿La aplicación es vulnerable?
Las restricciones de control de acceso implican que los usuarios no puedan actuar fuera de los permisos previstos. Típicamente, las fallas conducen a la divulgación, modificación o destrucción de información no autorizada, o a la ejecución una función de negocio fuera de los límites del usuario.
Las vulnerabilidades comunes de control de acceso incluyen:
* Sobrepasar las comprobaciones de control de acceso modificando la URL, el estado interno de la aplicación o HTML, utilizando una herramienta de ataque o una conexión vía API.
* Permitir que la clave primaria se cambie a la de otro usuario, pudiendo ver o editar la cuenta de otra persona.
* Elevación de privilegios. Actuar como un usuario sin iniciar sesión, o actuar como un administrador habiendo iniciado sesión como usuario estándar.
* Manipulación de metadatos, como reproducir un token de control de acceso JWT (JSON Web Token), manipular una cookie o un campo oculto para elevar los privilegios, o abusar de la invalidación de tokens JWT.
* La configuración incorrecta de CORS permite el acceso no autorizado a una API.
* Forzar la navegación a páginas autenticadas como un usuario no autenticado o a páginas privilegiadas como usuario estándar. Acceder a una API sin control de acceso mediante el uso de verbos POST, PUT y DELETE.
Cómo se previene
El control de acceso sólo es efectivo si es aplicado del lado del servidor o en una API sin servidor, donde el atacante no puede modificar la verificación de control de acceso o los metadatos.
* Con la excepción de los recursos públicos, la política debe ser denegar de forma predeterminada.
* Implemente los mecanismos de control de acceso una vez y reutilícelo en toda la aplicación, esto incluye minimizar el control de acceso HTTP (CORS).
* Los controles de acceso al modelo deben imponer la propiedad (del dueño) de los registros, en lugar de aceptar que el usuario puede crear, leer, actualizar o eliminar cualquier registro.
* Los modelos de dominio deben hacer cumplir los requisitos exclusivos de los límites de negocio de las aplicaciones.
* Deshabilite el listado de directorios del servidor web y asegúrese que los metadatos/fuentes de archivos (por ejemplo de GIT) y copia de seguridad no estén presentes en las carpetas públicas.
* Registre en bitácoras errores de control de acceso y alerte a los administradores cuando corresponda (por ej. fallas reiteradas).
* Limite la tasa de acceso a las APIs para minimizar el daño de herramientas de ataque automatizadas.
* Los tokens JWT deben ser invalidados luego de la finalización de la sesión por parte del usuario.
* Los desarrolladores y el personal de QA deben incluir pruebas de control de acceso en sus pruebas unitarias y de integración.
Ejemplos de escenarios de ataque
Escenario #1: La aplicación utiliza datos no validados en una llamada SQL para acceder a información de una cuenta:
pstmt.setString(1, request.getParameter("acct"));
 ResultSet results = pstmt.executeQuery( );
 Un atacante simplemente puede modificar el parámetro ‘acct’ en el navegador y enviar el número de cuenta que desee. Si no se verifica correctamente, el atacante puede acceder a la cuenta de cualquier usuario:
http://example.com/app/accountInfo?acct=notmyacct
 Escenario #2: Un atacante fuerza las búsquedas en las URL. Los privilegios de administrador son necesarios para acceder a la página de administración:
http://example.com/app/getappInfo
 http://example.com/app/admin_getappInfo
 Si un usuario no autenticado puede acceder a cualquier página o, si un usuario no-administrador puede acceder a la página de administración, esto es una falla.
Referencias