Preoccupazione per la sicurezza/privacy: Email esposta nell'URL di reindirizzamento del provider DiscourseConnect

Contribuisci Funzionalità
1

Descrivi il bug

Quando si utilizza Discourse come DiscourseConnect Provider (SSO Provider), l’indirizzo email dell’utente viene esposto nell’URL di reindirizzamento 302 verso il relying party. Ciò accade perché il metodo populate_user_data in lib/second_factor/actions/discourse_connect_provider.rb imposta sempre l’email:

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

Questa email viene quindi codificata in Base64 e inclusa nell’URL di reindirizzamento:
https://target-site.com/callback?sso=<base64_payload>&sig=<hmac_signature>

La decodifica del payload base64 rivela l’indirizzo email in testo semplice.

Impatto

  1. Cronologia del browser: l’email viene registrata nella cronologia del browser
  2. Log di Nginx: l’URL completo viene registrato nei log di accesso di nginx
  3. Log del sito di destinazione: il relying party riceve l’email senza esplicito consenso dell’utente
  4. Aspettativa dell’utente: gli utenti di solito autorizzano per dimostrare “Sono un utente legittimo”, non si aspettano che la loro email venga condivisa

Comportamento previsto

Gli utenti dovrebbero essere in grado di controllare se la loro email viene condivisa con il relying party. Dovrebbe esserci un’opzione di configurazione simile a discourse_connect_overrides_groups, discourse_connect_overrides_avatar, ecc.

Attualmente non esiste un’impostazione del sito per disabilitare questo comportamento. Scrivere un plugin per sovrascrivere questo comportamento è possibile ma non ideale.

Passaggi per la riproduzione

  1. Abilitare enable_discourse_connect_provider
  2. Configurare discourse_connect_provider_secrets (es. *.example.com|secret123)
  3. Far autenticare un utente tramite DiscourseConnect Provider
  4. Controllare l’URL di reindirizzamento 302 - l’email è visibile nei parametri dell’URL

L’URL di reindirizzamento appare come:
https://relying-party.com/sso?sso=nonce=xxx&sig=xxx

La decodifica del parametro sso rivela:
nonce=xxx&return_sso_url=xxx&email=user@example.com&external_id=123

Ambiente

  • Versione di Discourse: (latest)
  • Self-hosted

Possibili suggerimenti per la correzione

  1. Aggiungere un’impostazione del sito come discourse_connect_provider_includes_email (default: true per retrocompatibilità) per controllare se l’email è inclusa nella risposta
  2. Oppure implementare il callback basato su POST invece del reindirizzamento GET 302 per evitare la registrazione dell’URL
1 Mi Piace
2

Non è anche questo crittografato con il segreto condiviso?

1 Mi Piace
3

Ciao Falco,

La firma HMAC assicura solo che il payload non sia stato manomesso, non crittografa i dati. Base64 è codifica, non crittografia, quindi chiunque può decodificarlo per leggere il contenuto.

Il problema principale è: non vogliamo esporre informazioni utente non necessarie (come l’email) a “siti di terze parti che utilizzano Discourse per l’accesso SSO”. Gli utenti autorizzano solo per dimostrare “Sono un utente legittimo”, non si aspettano che la loro email venga condivisa.

Una impostazione del sito per controllare se l’email viene restituita sarebbe accettabile?

4

Sono curioso, qual è questa terza parte a valle che ha implementato il nostro protocollo SSO personalizzato?

Direi che è pr-welcome purché non sia l’impostazione predefinita, in modo da non rompere i siti esistenti.

5

Grazie per il feedback!

Per darti un po’ di contesto sul caso d’uso: il nostro forum è un “forum del campus” e uno studente ha creato un sito web gratuito da far usare agli altri studenti. Vogliono usare il nostro forum del campus basato su Discourse per autenticare se un utente è effettivamente uno studente della nostra scuola, dimostrando essenzialmente “sono uno studente legittimo qui”.

In questo scenario, il sito web esterno ha solo bisogno di sapere “questo è un utente valido dal nostro forum del campus”, non ha necessariamente bisogno dell’email dell’utente, che è un’informazione sensibile che non dovrebbe essere condivisa inutilmente.

Lavorerò su una Pull Request (PR) che aggiunga un’impostazione del sito per controllare questo comportamento, con un valore predefinito che mantenga la retrocompatibilità per le installazioni esistenti.

2 Mi Piace