Preocupación de seguridad/privacidad: Correo electrónico expuesto en la URL de redirección de DiscourseConnect Provider

Contribuir Característica
1

Describa el error

Cuando se utiliza Discourse como un Proveedor de DiscourseConnect (Proveedor SSO), la dirección de correo electrónico del usuario se expone en la URL de redirección 302 al relying party (parte que confía). Esto sucede porque el método populate_user_data en lib/second_factor/actions/discourse_connect_provider.rb siempre establece el correo electrónico:

  def populate_user_data(sso)
    sso.name = current_user.name
    sso.username = current_user.username
    sso.email = current_user.email  # <-- Siempre incluido
    sso.external_id = current_user.id.to_s
    # ...
  end

Este correo electrónico se codifica en Base64 y se incluye en la URL de redirección:
https://sitio-destino.com/callback?sso=<payload_base64>&sig=<firma_hmac>

La decodificación del payload base64 revela la dirección de correo electrónico en texto plano.

Impacto

  1. Historial del navegador: El correo electrónico se registra en el historial del navegador
  2. Registros de Nginx: La URL completa se registra en los registros de acceso de nginx
  3. Registros del sitio de destino: El relying party recibe el correo electrónico sin consentimiento explícito del usuario
  4. Expectativa del usuario: Los usuarios normalmente autorizan para demostrar “Soy un usuario legítimo”, no esperan que se comparta su correo electrónico

Comportamiento esperado

Los usuarios deben poder controlar si su correo electrónico se comparte con el relying party. Debería haber una opción de configuración similar a discourse_connect_overrides_groups, discourse_connect_overrides_avatar, etc.

Actualmente no hay una configuración del sitio para deshabilitar este comportamiento. Escribir un plugin para anular este comportamiento es posible pero no es lo ideal.

Pasos para reproducir

  1. Habilitar enable_discourse_connect_provider
  2. Configurar discourse_connect_provider_secrets (ej. *.example.com|secret123)
  3. Hacer que un usuario se autentique a través del Proveedor DiscourseConnect
  4. Comprobar la URL de redirección 302: el correo electrónico es visible en los parámetros de la URL

La URL de redirección se ve así:
https://relying-party.com/sso?sso=bm9uY2U9xxx&sig=xxx

La decodificación del parámetro sso revela:
nonce=xxx&return_sso_url=xxx&email=user@example.com&external_id=123

Entorno

  • Versión de Discourse: (más reciente)
  • Autohospedado

Sugerencias de posibles soluciones

  1. Añadir una configuración del sitio como discourse_connect_provider_includes_email (predeterminado: true para compatibilidad con versiones anteriores) para controlar si el correo electrónico se incluye en la respuesta
  2. O implementar el callback basado en POST en lugar de la redirección GET 302 para evitar el registro de la URL
1 me gusta
2

¿Eso tampoco está cifrado con el secreto compartido?

1 me gusta
3

Hola Falco,

La firma HMAC solo garantiza que la carga útil no ha sido manipulada; no cifra los datos. Base64 es codificación, no cifrado, por lo que cualquiera puede decodificarlo para leer el contenido.

El problema principal es: no queremos exponer información de usuario innecesaria (como el correo electrónico) a “sitios de terceros que utilizan Discourse para el inicio de sesión SSO”. Los usuarios autorizan solo para demostrar “Soy un usuario legítimo”, no esperan que se comparta su correo electrónico.

¿Sería aceptable una configuración del sitio para controlar si se devuelve el correo electrónico?

4

Tengo curiosidad, ¿cuál es este tercero aguas abajo que ha implementado nuestro protocolo SSO personalizado?

Yo diría que es pr-welcome siempre y cuando no sea el valor predeterminado, para no romper los sitios existentes.

5

¡Gracias por los comentarios!

Para darte algo de contexto sobre el caso de uso: nuestro foro es un “foro del campus”, y un estudiante creó un sitio web gratuito para que lo usen otros estudiantes. Quieren usar nuestro foro del campus basado en Discourse para autenticar si un usuario es realmente un estudiante de nuestra escuela, esencialmente probando “Soy un estudiante legítimo aquí”.

En este escenario, el sitio web externo solo necesita saber “este es un usuario válido de nuestro foro del campus”, no necesariamente necesita el correo electrónico del usuario, que es información sensible que no debe compartirse innecesariamente.

Trabajaré en una solicitud de extracción (PR) que agregue una configuración del sitio para controlar este comportamiento, con un valor predeterminado que mantenga la compatibilidad con versiones anteriores para las instalaciones existentes.

4 Me gusta
6

Aquí está el enlace a la PR