Contao: Control de acceso incorrecto en el voter de acceso a tablas

Debido a un fallo de almacenamiento en caché en el security voter que gestiona el acceso a nivel de tabla en el backend de Data Container (DCA) de Contao, un usuario del backend con pocos privilegios (no administrador) puede obtener acceso no autorizado de lectura, creación, actualización y eliminación a tablas de la base de datos fuera de los permisos de sus módulos asignados. Esto abarca tablas que contienen datos personales confidenciales, como los registros de miembros del frontend y direcciones de correo electrónico de suscriptores al boletín.

Detalles de la vulnerabilidad

El backend de Contao está estructurado en módulos (por ejemplo, «Noticias», «Miembros»). Cada usuario del backend pertenece a un grupo que define con qué módulos, y por ende con qué tablas de base de datos, tiene permitido trabajar. Antes de permitir manipular una tabla, Contao debe comprobar si el grupo del usuario incluye el acceso a dicha tabla.

Para no repetir esta comprobación de forma continua, Contao almacena la respuesta durante el resto de la solicitud HTTP. Sin embargo, guarda este resultado bajo una clave errónea: en lugar de registrar si el usuario tiene permiso para acceder a una tabla concreta, solo almacena que el usuario tiene acceso a un recurso sin asociarlo a la tabla específica correspondiente.

Por tanto, si una solicitud comprueba primero una tabla a la que el usuario SÍ tiene acceso y luego evalúa una segunda tabla diferente para la que NO dispone de permisos, Contao reutiliza la primera respuesta. Como consecuencia, el usuario accede a una tabla para la que su grupo nunca recibió autorización.

Detalles técnicos

El backend de Contao aplica el control de acceso por tabla mediante una cadena de Symfony security voters. El componente implicado es TableAccessVoter::hasAccessToModule(), en core-bundle/src/Security/Voter/DataContainer/TableAccessVoter.php:

    private array $canAccessTable = [];
    private array $canReadAccessTable = [];
 
    private function hasAccessToModule(TokenInterface $token, ...): bool
    {
        $tokenHash = hash('xxh128', serialize($token));
 
        if (isset($this->canAccessTable[$tokenHash]) || (...)) {
            return $this->canAccessTable[$tokenHash] ?? $this->canReadAccessTable[$tokenHash];
        }
 
        $table = $subject->getDataSource();
 
        foreach ($GLOBALS['BE_MOD'] as $modules) {
            ...
            return $this->canAccessTable[$tokenHash] = true;  // or false
        }
    }

La clave de caché, $tokenHash, se genera únicamente a partir del token de seguridad del usuario actual y no incluye la tabla que se está evaluando. Como TableAccessVoter es un servicio compartido estándar de Symfony, esta caché se mantiene activa durante toda la solicitud HTTP. De este modo, la primera tabla comprobada para un usuario determina el resultado almacenado para cualquier otra tabla evaluada posteriormente en esa misma solicitud, sea o no correcta dicha respuesta para la segunda tabla.

La situación se agrava por la presencia de DefaultDataContainerVoter, un voter permisivo de respaldo con baja prioridad que concede acceso a cualquier permiso relacionado con tablas a menos que otro voter lo deniegue explícitamente. Cuando TableAccessVoter devuelve una respuesta neutral («sin opinión») debido a la caché obsoleta, este voter de respaldo transforma ese resultado en una concesión total de acceso.

La mayoría de las tablas de bases de datos en Contao no disponen de una segunda comprobación específica. Solo tl_content, tl_favorites, tl_form, tl_form_field, tl_module, tl_image_size(_item), tl_job, tl_layout, tl_page, tl_preview_link, tl_undo y tl_user cuentan con ella. Tablas como tl_member (datos de miembros), tl_newsletter_recipients (correos de suscriptores), tl_news, tl_calendar_events, tl_faq y tl_comments dependen exclusivamente de la comprobación defectuosa descrita.

Créditos

Esta vulnerabilidad de seguridad fue descubierta por Sven Jäger de SySS GmbH.