セキュリティ/プライバシーに関する懸念：DiscourseConnect ProviderのリダイレクトURLでメールアドレスが漏洩

貢献 特徴
1

バグの説明

Discourse を DiscourseConnect プロバイダー (SSO プロバイダー)として使用すると、ユーザーのメールアドレスがリライングパーティへの 302 リダイレクト URL で公開されます。これは、lib/second_factor/actions/discourse_connect_provider.rb の populate_user_data メソッドが常にメールを設定するためです。

  def populate_user_data(sso)
    sso.name = current_user.name
    sso.username = current_user.username
    sso.email = current_user.email  # <-- 常に含まれる
    sso.external_id = current_user.id.to_s
    # ...
  end

このメールアドレスは Base64 でエンコードされ、リダイレクト URL に含まれます。
https://target-site.com/callback?sso=<base64_payload>&sig=<hmac_signature>

Base64 ペイロードをデコードすると、メールアドレスがプレーンテキストで表示されます。

影響

  1. ブラウザの履歴: メールアドレスがブラウザの履歴に記録される
  2. Nginx ログ: 完全な URL が nginx アクセスログに記録される
  3. リライングパーティのログ: リライングパーティが明示的なユーザーの同意なしにメールアドレスを受け取る
  4. ユーザーの期待: ユーザーは通常、「自分が正当なユーザーであることを証明する」ことに同意するのであり、メールアドレスが共有されることを期待していません。

期待される動作

ユーザーは、メールアドレスをリライングパーティと共有するかどうかを制御できる必要があります。discourse_connect_overrides_groups や discourse_connect_overrides_avatar などと同様の設定オプションが必要です。

現在、この動作を無効にするためのサイト設定はありません。動作を上書きするためにプラグインを作成することは可能ですが、理想的ではありません。

再現手順

  1. enable_discourse_connect_provider を有効にする
  2. discourse_connect_provider_secrets を設定する (例: *.example.com|secret123)
  3. ユーザーが DiscourseConnect Provider 経由で認証する
  4. 302 リダイレクト URL を確認する - メールアドレスが URL パラメータに表示されている

リダイレクト URL は次のようになります。
https://relying-party.com/sso?sso=nonce=xxx&sig=xxx

sso パラメータをデコードすると、次のように表示されます。
nonce=xxx&return_sso_url=xxx&email=user@example.com&external_id=123

環境

  • Discourse バージョン: (最新)
  • セルフホスト型

考えられる修正案

  1. レスポンスにメールを含めるかどうかを制御するためのサイト設定 (後方互換性のためにデフォルトは true) として discourse_connect_provider_includes_email を追加する
  2. または、URL のロギングを避けるために GET 302 リダイレクトの代わりに POST ベースのコールバックを実装する
「いいね！」 1
2

それも共有シークレットで暗号化されているのではありませんか？

「いいね！」 1
3

こんにちは、Falco様

HMAC署名はペイロードが改ざんされていないことを保証するだけで、データを暗号化するものではありません。Base64はエンコーディングであり暗号化ではないため、誰でもデコードして内容を読み取ることができます。

根本的な問題は、「DiscourseをSSOログインに使用するサードパーティサイト」に不必要なユーザー情報（メールアドレスなど）を公開したくないということです。ユーザーは「私は正当なユーザーである」ことを証明するためにのみ承認し、メールアドレスが共有されることを期待していません。

メールアドレスを返すかどうかを制御するサイト設定は受け入れ可能でしょうか？

4

カスタムSSOプロトコルを実装した、この下流のサードパーティとは何なのか興味があります。

既存のサイトを壊さないように、デフォルトでなければ pr-welcome だと思います。

5

フィードバックありがとうございます！

ユースケースの背景を説明しますと、私たちのフォーラムは「キャンパスフォーラム」であり、ある学生が他の学生が利用できるように無料のウェブサイトを構築しました。彼らは、ユーザーが実際に私たちの学校の学生であることを認証するために、私たちのDiscourseベースのキャンパスフォーラムを利用したいと考えています。つまり、「私はここにいる正当な学生です」と証明したいのです。

このシナリオでは、外部ウェブサイトが必要とするのは「これは私たちのキャンパスフォーラムからの有効なユーザーである」ということだけであり、不必要に共有すべき機密情報であるユーザーのメールアドレスを必ずしも必要としません。

既存のインストールとの後方互換性を維持するデフォルト設定で、この動作を制御するためのサイト設定を追加するPRに取り組む予定です。

「いいね！」 2