Sicherheits-/Datenschutzbedenken: E-Mail in DiscourseConnect Provider Weiterleitungs-URL offengelegt

Beitragen Merkmal
1

Bug beschreiben

Wenn Discourse als DiscourseConnect-Anbieter (SSO-Anbieter) verwendet wird, wird die E-Mail-Adresse des Benutzers in der 302-Weiterleitungs-URL an die vertrauende Partei offengelegt. Dies geschieht, weil die Methode populate_user_data in lib/second_factor/actions/discourse_connect_provider.rb immer die E-Mail-Adresse setzt:

  def populate_user_data(sso)
    sso.name = current_user.name
    sso.username = current_user.username
    sso.email = current_user.email  # <-- Wird immer eingeschlossen
    sso.external_id = current_user.id.to_s
    # ...
  end

Diese E-Mail wird dann Base64-kodiert und in die Weiterleitungs-URL aufgenommen:
https://zielseite.com/callback?sso=<base64_payload>&sig=<hmac_signature>

Beim Dekodieren der Base64-Nutzlast wird die E-Mail-Adresse im Klartext sichtbar.

Auswirkungen

  1. Browserverlauf: E-Mail wird im Browserverlauf gespeichert
  2. Nginx-Protokolle: Die vollständige URL wird in den Nginx-Zugriffsprotokollen protokolliert
  3. Protokolle der Zielseite: Die vertrauende Partei erhält die E-Mail ohne ausdrückliche Zustimmung des Benutzers
  4. Erwartung des Benutzers: Benutzer stimmen normalerweise zu, um zu beweisen, „dass ich ein legitimer Benutzer bin“ – sie erwarten nicht, dass ihre E-Mail-Adresse weitergegeben wird

Erwartetes Verhalten

Benutzer sollten kontrollieren können, ob ihre E-Mail-Adresse an die vertrauende Partei weitergegeben wird. Es sollte eine Konfigurationsoption geben, ähnlich wie bei discourse_connect_overrides_groups, discourse_connect_overrides_avatar usw.

Derzeit gibt es keine Site-Einstellung, um dieses Verhalten zu deaktivieren. Das Schreiben eines Plugins zur Umgehung dieses Verhaltens ist möglich, aber nicht ideal.

Reproduktionsschritte

  1. enable_discourse_connect_provider aktivieren
  2. discourse_connect_provider_secrets konfigurieren (z. B. *.example.com|secret123)
  3. Einen Benutzer über den DiscourseConnect-Anbieter authentifizieren lassen
  4. Die 302-Weiterleitungs-URL überprüfen – die E-Mail ist in den URL-Parametern sichtbar

Die Weiterleitungs-URL sieht ungefähr so aus:
https://vertrauende-partei.com/sso?sso=bm9uY2U9xxx&sig=xxx

Beim Dekodieren des sso-Parameters wird Folgendes angezeigt:
nonce=xxx&return_sso_url=xxx&email=user@example.com&external_id=123

Umgebung

  • Discourse-Version: (neueste)
  • Selbst gehostet

Mögliche Korrekturvorschläge

  1. Eine Site-Einstellung wie discourse_connect_provider_includes_email hinzufügen (Standard: true zur Abwärtskompatibilität), um zu steuern, ob die E-Mail in der Antwort enthalten ist
  2. Oder einen POST-basierten Rückruf anstelle einer GET-302-Weiterleitung implementieren, um die Protokollierung der URL zu vermeiden
1 „Gefällt mir“
2

Ist das nicht auch mit dem gemeinsamen Geheimnis verschlüsselt?

1 „Gefällt mir“
3

Hallo Falco,

Die HMAC-Signatur stellt nur sicher, dass die Nutzdaten nicht manipuliert wurden – sie verschlüsselt die Daten nicht. Base64 ist eine Kodierung, keine Verschlüsselung, sodass jeder sie dekodieren kann, um den Inhalt zu lesen.

Das Kernproblem ist: Wir möchten unnötige Benutzerinformationen (wie E-Mail) nicht an „Drittanbieter-Websites, die Discourse für die SSO-Anmeldung verwenden“ weitergeben. Benutzer autorisieren nur, um zu beweisen, „ich bin ein legitimer Benutzer“ – sie erwarten nicht, dass ihre E-Mail-Adresse weitergegeben wird.

Wäre eine Website-Einstellung zur Steuerung, ob die E-Mail-Adresse zurückgegeben wird, akzeptabel?

4

Ich bin neugierig, welcher Downstream-Drittanbieter unser benutzerdefiniertes SSO-Protokoll implementiert hat?

Ich würde sagen, das ist pr-welcome, solange es nicht die Standardeinstellung ist, damit wir bestehende Websites nicht beeinträchtigen.

5

Vielen Dank für das Feedback!

Um Ihnen etwas Kontext zum Anwendungsfall zu geben: Unser Forum ist ein „Campus-Forum“, und ein Student hat eine kostenlose Website für andere Studenten erstellt. Sie möchten unser auf Discourse basierendes Campus-Forum nutzen, um zu authentifizieren, ob ein Benutzer tatsächlich ein Student unserer Schule ist – im Grunde um zu beweisen: „Ich bin ein legitimer Student hier.“

In diesem Szenario muss die externe Website nur wissen: „Dies ist ein gültiger Benutzer aus unserem Campus-Forum“ – sie benötigt nicht unbedingt die E-Mail-Adresse des Benutzers, was sensible Informationen sind, die nicht unnötig weitergegeben werden sollten.

Ich werde an einem PR arbeiten, der eine Site-Einstellung hinzufügt, um dieses Verhalten zu steuern, mit einem Standardwert, der die Abwärtskompatibilität für bestehende Installationen gewährleistet.

2 „Gefällt mir“