Broken Access Control
INTRODUCCIÓN
A continuación se presenta de forma detallada un reporte técnico sobre la Resolución del laboratorio URL-based access control can be circumvented con respecto a la vulnerabilidad Broken Access Control de la plataforma Portswigger. El mismo se establece con un análisis de riesgo con respecto al impacto que esta puede generar. Esto incluye CWE, Criticidad, CVSS Score, CVSS Vector y sus Componentes afectados. Sumado a ello, se especificarán las mitigaciones pertinentes, detalles técnicos del pentest y los links de referencias.
ANÁLISIS DE RIESGO
CWE – 284 | Improper Access Control |
IMPACTO | CRÍTICO |
CVSS BASE SCORE | 8.2 |
CVSS 3.1 VECTOR | AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N |
COMPONENTES AFECTADOS | Cabecera X-Original-URL. |
EXPLICACIÓN | Un usuario no autenticado puede aprovecharse de la mala configuración en la cabecera X-Original-URL para romper el control de acceso del sistema. De esta forma, puede ejecutar tareas como eliminar usuarios del sistema |
RECOMENDACIONES
1) Establecer roles y permisos: Se recomienda llevar a cabo una correcta autenticación de usuarios para acceder a diferentes recursos del sistema. Por ejemplo, el siguiente código en php obliga a un usuario iniciar sesión antes de acceder al listado de e-mails:
if (isset($_SESSION[‘loggedin’]) && $_SESSION[‘isadmin’] == true)) { cargar_emails(); } else { return_to_login(); |
2) Denegar recursos por defecto: A menos que un recurso esté destinado a ser accesible públicamente, se aconseja denegar el acceso de forma predeterminada para evitar posibles «broken access control».
3) Políticas de contraseñas y autenticación: Se recomienda llevar a cabo una correcta política de contraseñas con respecto a la cantidad y tipos de caracteres a establecer. Por ejemplo se podría implementar un mínimo de 8 caracteres los cuales contengan letras MAYÚS, números y caracteres especiales (!”#$%&/), como así también que se cambien cada 30 días (mínimo). A su vez, una buena capa y práctica de seguridad sería implementar 2FA vía código (por ejemplo con Authy o Google Authenticator).
4) Implementar un Acceso Basado en Roles: Se recomienda implementar un sistema de control de acceso basado en roles (RBAC) para asegurar que los usuarios solo tengan acceso a las funciones y recursos que están autorizados a utilizar. Por ejemplo, el siguiente es un código con lenguaje de programación Python usando Flask y Flask-Principal:
from flask import Flask, render_template from flask_principal import Principal, Permission app = Flask(__name__) principal = Principal(app) # Definir roles admin_role = principal.role(‘admin’) user_role = principal.role(‘user’) # Definir permisos asociados con roles admin_permission = Permission(admin_role) user_permission = Permission(user_role) @app.route(‘/admin’) @admin_permission.require(http_exception=403) def admin_dashboard(): return render_template(‘admin_dashboard.html’) @app.route(‘/user’) @user_permission.require(http_exception=403) def user_dashboard(): return render_template(‘user_dashboard.html’) |
5) Validar datos en el servidor: Se recomienda realizar validaciones de acceso en el servidor, incluso si la información del cliente parece válida. Para ello, se pueden establecer cabeceras de seguridad como Content Security Policy (CSP) con los valores default-src ‘self’; script-src ‘self’; object-src ‘none’; frame-src ‘none’; base-uri ‘none’; . Esta política especifica qué recursos como imágenes y scripts, solo pueden cargarse desde el mismo origen que la página principal. Sumado a esto, también se recomienda minimizar el uso de intercambio de recursos entre orígenes (CORS).
6) Controles de seguridad: Siempre se aconseja llevar a cabo, y de forma periódica, una correcta gestión de vulnerabilidades y Hardening en la aplicación web. Como así también, parchear y actualizar los frameworks y sistemas que la aplicación requiera.
DETALLES TÉCNICOS
Una vez dentro de la aplicación web, se pudo observar que la misma cuenta con tres pestañas como se ve en la siguiente captura.
Por tanto, se procedió a interceptar las peticiones que se envían al servidor cuando se accede a dichas secciones para estudiar un poco más en detalle el funcionamiento de la web. Para ello se utilizó la herramienta Burpsuit como se ve a continuación.
Como se observa, no se pudo acceder de forma directa al directorio o panel del usuario admin, cuya respuesta fue un código de estado 403 (prohibido).
Teniendo esto en cuenta se procedió a verificar la seguridad del sitio con respecto al control de acceso. Para ello, se introdujo la cabecera X-Original-URL para verificar si el servidor backend se basa en la misma para las peticiones del lado del cliente.
Cuando se accede a la raíz o home del sitio web, el servidor devuelve un código de estado 200 indicando que la operación se llevó a cabo correctamente. No obstante, cuando se agrega la cabecera X-Original-URL y una página desconocida (example_page), el servidor nos devuelve un código de estado 404 indicando que el recurso no ha sido encontrado. De esta forma se puede comprobar que el control de acceso de la aplicación se puede eludir a través de dicha cabecera.
Teniendo esto en cuenta, se procedió a colocar la cabecera de la siguiente manera: X-Original-URL: /admin para comprobar si de esta forma se puede tener acceso al panel de gestión del usuario administrador.
Como se puede ver en la captura anterior se tuvo un código de estado 200 por parte del servidor y, por consecuencia, acceso al panel del usuario administrador.
Sumado a esto, se puede observar que dicho usuario cuenta con las opciones para eliminar los usuarios Carlos y Wiener. Por tanto, un atacante podría colocar la ruta /?username=user junto con el encabezado X-Original-URL: /admin/delete para eliminar usuarios y, a través de este broken access control, comprometer la integridad informática de los mismos.
REFERENCIAS
https://owasp.org/Top10/A01_2021-Broken_Access_Control/
https://www.cvedetails.com/vulnerability-list/vendor_id-8661/Mitre.html
https://blog.hackmetrix.com/broken-access-control/
