Вопрос безопасности/конфиденциальности: Email раскрыт в URL перенаправления провайдера DiscourseConnect

Внести вклад Функция
1

Описание ошибки

При использовании Discourse в качестве поставщика DiscourseConnect (поставщика SSO) адрес электронной почты пользователя раскрывается в URL-адресе перенаправления 302 для доверяющей стороны. Это происходит из-за того, что метод populate_user_data в файле lib/second_factor/actions/discourse_connect_provider.rb всегда устанавливает значение поля email:

  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

Затем этот email кодируется в 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.
  4. Проверьте URL-адрес перенаправления 302 — адрес электронной почты виден в параметрах URL.

URL-адрес перенаправления выглядит следующим образом:
https://relying-party.com/sso?sso=bm9uY2U9xxx&sig=xxx

Декодирование параметра sso раскрывает:
nonce=xxx&return_sso_url=xxx&email=user@example.com&external_id=123

Окружение

  • Версия Discourse: (последняя)
  • Размещение на собственном сервере

Предложения по возможному исправлению

  1. Добавить настройку сайта, например discourse_connect_provider_includes_email (по умолчанию: true для обратной совместимости), чтобы контролировать, включается ли адрес электронной почты в ответ.
  2. Или реализовать обратный вызов на основе POST вместо перенаправления 302 через GET, чтобы избежать записи URL в логи.
1 лайк
2

Разве это тоже не зашифровано с использованием общего секрета?

1 лайк
3

Привет, Фалько,

HMAC-подпись гарантирует лишь то, что полезная нагрузка не была изменена — она не шифрует данные. Base64 — это кодирование, а не шифрование, поэтому любой может декодировать его и прочитать содержимое.

Суть проблемы в следующем: мы не хотим раскрывать ненужную информацию о пользователях (например, электронную почту) «сторонним сайтам, использующим Discourse для входа через SSO». Пользователи авторизуются только для того, чтобы подтвердить: «Я легитимный пользователь». Они не ожидают, что их электронная почта будет передана.

Подойдёт ли нам настройка сайта, позволяющая контролировать, возвращается ли электронная почта?

4

Мне интересно, кто этот сторонний сервис, который реализовал наш пользовательский протокол SSO?

Я считаю, что это pr-welcome, при условии, что это не будет включено по умолчанию, чтобы мы не сломали существующие сайты.

5

Спасибо за обратную связь!

Чтобы дать вам контекст: наш форум является «кампусным форумом», и один из студентов создал бесплатный веб-сайт для использования другими студентами. Они хотят использовать наш форум на базе Discourse для подтверждения того, что пользователь действительно является студентом нашей школы — по сути, доказывая: «Я легитимный студент здесь».

В этом сценарии внешнему веб-сайту нужно лишь знать, что «это валидный пользователь нашего кампусного форума». Им не обязательно нужен email пользователя, так как это конфиденциальная информация, которой не следует делиться без необходимости.

Я займусь созданием PR, который добавит настройку сайта для управления этим поведением, с значением по умолчанию, обеспечивающим обратную совместимость для существующих установок.

3 лайка