Приглашения, созданные сотрудниками, обходят требование must_approve_users

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

У нас возникла серьёзная проблема с безопасностью в системе приглашений. Похоже, её легко воспроизвести. Наш сайт работает в режиме «только по приглашениям». Кроме того, в настройках у нас включена опция «требовать одобрения пользователей».

Один из сотрудников выдал приглашение с максимальным количеством использований больше одного, то есть оно не было привязано к конкретному адресу электронной почты (пример ниже).

2022-05-26 16_24_30-Profile - Wall-E - Helionauts
2022-05-26 16_24_30-Profile - Wall-E - Helionauts1184×961 47.7 KB

Ссылка на это приглашение начала распространяться, и люди могли регистрироваться по ней. Однако мы ожидали, что при включённой опции «требовать одобрения пользователей» сотрудники должны будут одобрять каждого, кто использует такие «непривязанные к email» приглашения. Вместо этого все они автоматически получали доступ, независимо от того, у кого оказалась ссылка. Таким образом, ссылку может использовать любой желающий, и мы не можем контролировать, кто именно вступает через неё. Мы должны иметь возможность проводить «проверку фона», используя комбинацию адреса электронной почты, имени и других обязательных полей, которые мы добавили и которые требуют одобрения после нашей проверки.

Это создало серьёзную проблему: человек из строго запрещённой иностранной организации получил эту ссылку и зарегистрировался. Мне пришлось немедленно удалить эту учётную запись. Для нас это серьёзная уязвимость.

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

Есть ли способ, чтобы сотрудники могли одобрять пользователей, использующих ссылку приглашения, которая не была ограничена адресом электронной почты? Это казалось бы логичным способом включения опции «требовать одобрения пользователей» на сайте, работающем только по приглашениям.

2022-05-26 16_19_31-Admin - Helionauts
2022-05-26 16_19_31-Admin - Helionauts1264×135 11.8 KB

5 лайков
Why do I need to still approve users that I have invited?
Allow users invited by staff to skip approval
2022: The Year in Review
Allow users invited by staff to skip approval
2

Мне удалось воспроизвести проблему: при создании массовой ссылки для приглашения пользователи, регистрирующиеся по этой ссылке, автоматически получают иммунитет от настройки «требовать одобрения пользователей».

6 лайков
3

Есть ли интерес к исправлению этой проблемы? Если вопрос не будет решён, в конечном итоге эта проблема приведёт к остановке нашего проекта на платформе Discourse в нашей организации.

2 лайка
4

Я не уверен, что это ошибка.

Изучив предыдущие темы о глобальных кодах приглашения и приглашениях для обхода одобрения, можно предположить, что это сделано намеренно. Однако кто-то из команды должен прокомментировать это.

Вы видели что-то в документации, что заставило вас подумать, что приглашения, не привязанные к электронной почте, добавляют шаг одобрения, @Wall-E?

4 лайка
5

Главное здесь то, что сотрудник выслал приглашение. Discourse рассматривает это как неявное одобрение пользователей, которые воспользовались этим приглашением.

Если приглашение было создано не сотрудником, то пользователь, его использовавший, будет добавлен в очередь на одобрение сотрудниками.

5 лайков
7

Так, если для создания приглашения используется учётная запись не-сотрудника, то регистрации, прошедшие через это приглашение, будут помещены в очередь на проверку? Если это так, то такое поведение вполне допустимо, и @Wall-E вы можете использовать тестовую обычную учётную запись для генерации приглашения в качестве обходного решения.

3 лайка
9

Я считаю, что для пользователей со статусом модератора хотя бы должно быть предупреждение, и было бы замечательно, если бы они могли сами выбирать, как обращаться с новыми участниками. Использование второго, «обычного» аккаунта — это некрасивое решение, которое лишь обходит проблему.

7 лайков
10

Прочитав эту тему и предыдущие обсуждения, я вижу, что текущая работа системы «спроектирована так», но не отражает новые изменения в системе приглашений. Теперь создавать ссылки для приглашения, которыми могут воспользоваться незнакомые люди, стало гораздо проще. Кроме того, теперь сотрудники могут создавать ссылки, которые позволяют добавлять приглашённых в группы с доступом к защищённым разделам сайта, что представляет серьёзную угрозу безопасности.

@Wall-E Меня интересует, как именно ваши ссылки для приглашения попадают в руки людей, которым не должен быть предоставлен доступ к вашему сайту. Скорее всего, сотрудники вашего сайта знают, что следует быть осторожными и не создавать ссылки для приглашения, которые могут использовать любые люди, а также не распространять их публично или в местах, где их смогут использовать не те люди. В какой-то мере проблема, с которой вы столкнулись, связана с обучением сотрудников. Если ваш ответ содержит конфиденциальную информацию, вы можете отправить его мне в личные сообщения.

Если в настоящее время существуют скомпрометированные ссылки для приглашения, вы можете удалить их и создать новые, а в будущем более тщательно подходить к их распространению. Как администратор, вы всегда можете перейти на страницу приглашений для пользователя и посмотреть, кто воспользовался своими приглашениями. Если вы не доверяете некоторым сотрудникам, вы можете понизить их уровень прав до TL4, который предоставляет права, близкие к правам модератора.

Я вижу три возможных пути решения:

  1. Ничего не менять. Система приглашений работает в соответствии с проектом, сотрудникам просто нужно быть осторожнее со своими ссылками для приглашения. Если мы выберем этот путь, предлагаю изменить описание настройки администратора «must approve users» (требуется утверждение пользователей), чтобы было абсолютно ясно, что ссылки для приглашения, созданные администраторами, обходят эту настройку.

Сотрудники должны утверждать все новые учётные записи пользователей, прежде чем им будет разрешён доступ к сайту. Примечание: приглашения, созданные сотрудниками, обходят эту настройку и не требуют утверждения.

Запрос на внесение этого изменения доступен здесь: clarify that invites by staff bypass user approval by tobiaseigen · Pull Request #16966 · discourse/discourse · GitHub

  1. Сделать то же, что и в пункте 1, но также добавить дополнительный шаг подтверждения «Вы уверены?» при создании администратором ссылки для приглашения, которая позволяет сразу получить доступ к сайту. Только на сайтах, где требуется утверждение.

  2. Изменить поведение так, чтобы ссылки для приглашения, созданные администраторами, соблюдали настройку «требуется утверждение», как и приглашения от неадминистраторов.

Я согласен с автором оригинального поста (OP), что текущее поведение вводит в заблуждение и может привести к проблемам на сайтах, где требуется утверждение. Сайты с включённой этой настройкой особенно осторожны и нуждаются в этом дополнительном параноидальном уровне контроля над тем, кто может получить доступ.

Поэтому моя рекомендация — выбрать третий вариант: сделать так, чтобы все ссылки для приглашения работали одинаково и соблюдали настройку «must approve users».

Однако я не считаю это ошибкой. Система работает в соответствии с проектом. Переклассифицирую как запрос на новую функцию.

5 лайков
11

Я тоже очень поддерживаю вариант 3. Я создаю сообщество, где люди могут глубже размышлять о эмоциях, и, на мой взгляд, добавление дополнительного уровня проверки для анонимных пригласительных ссылок (поскольку они не привязаны к адресу электронной почты или личности) позволит мне чувствовать себя спокойнее, зная, что присоединятся только те, кого я хочу видеть.

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

Поэтому я также поддерживаю идею сделать так, чтобы анонимные пригласительные ссылки учитывали настройку «необходимо утвердить пользователей».

Также я считаю, что если произойдёт вариант #3, то система приглашений сможет функционировать почти как система заявок для форумов только по приглашениям. Сейчас я не уверен, как я мог бы предложить людям подать заявку на вступление без использования отдельной Google-формы или чего-то подобного. Это могло бы упростить процесс: пользовательские поля могли бы служить формой заявки — именно это, как мне кажется, пытается сделать @Wall-E.

1 лайк
12

Это не о том, что я обсуждаю. Я говорю о том, что параметр must_approve_users не имеет эффекта в инстансе только по приглашениям. Включение этой настройки должно давать другой результат, чем её выключение. Если это не так, то следует документально подтвердить, что данное поведение не применяется к инстансам только по приглашениям. Если я упустил это в документации, то это действительно наша ответственность как сотрудников. Но если этого нет, то эта функция вводит в заблуждение и должна либо быть исправлена, либо, как минимум, задокументирована, так как она ввела в заблуждение весь наш персонал.

13

Смотрите ответ от @david выше:

14

Абсолютно верно. Я мог упустить это в документации. Если бы это было задокументировано, то моя ответственность была бы в том, чтобы ввести в заблуждение моих сотрудников, и предупреждение не помешает, потому что люди/сотрудники могут забыть.

15

Да, я это видел. Принято к сведению.

Я процитирую тех, кто имеет полномочия закрыть нас из-за этого аспекта, который в нашей организации считается проблемой безопасности: «Если эта система может позволить кому-то из несанкционированной организации получить доступ, вы должны исходить из того, что в конечном итоге это произойдёт, независимо от вашей бдительности». Именно это и произошло. Эта «функция» (я бы сказал, отсутствие функции, так как параметр «must_approve_user» просто не имеет эффекта в случае приглашений только по ссылке) была включена, мы выдали неограниченное приглашение именно тем людям, которых хотели пригласить, и, очевидно, один из этих людей поделился ссылкой на это неограниченное приглашение с другой организацией.

На этом я также отвечаю @tobiaseigen:

У нас проводятся встречи, конференции, иногда с сотнями людей из авторизованных организаций, которым разрешено присоединяться к нашему форуму. Но некоторые из них иногда представляют другие организации, которым не разрешено присоединяться к нашему форуму (из-за общих политик, которые не находятся под нашим контролем).

Эта ссылка на приглашение «вырвалась на свободу», даже несмотря на бдительность сотрудников, так как мы не можем контролировать, что будут делать «неявно авторизованные» люди с этой ссылкой; по определению, эта ссылка «неограниченная», поэтому они могут переслать её кому угодно. Я не могу винить своих сотрудников за это, так как если вы говорите, что это «по замыслу» и подразумевает неявное одобрение, это означает, что эта неограниченная ссылка на приглашение может оказаться где угодно, и в конечном итоге так и произойдёт. Именно об этом говорили руководители нашего IT-отдела, и на то были веские причины. Мы знали об этом, поэтому включили параметр must_approve_users, чтобы он действовал как тот самый слой безопасности, для которого, как мы думали, он и предназначен.

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

Я полностью поддерживаю вариант 3, как и наш исследовательский центр, и сотрудники моего форума. До дальнейшего уведомления сотрудникам запрещено использовать неограниченные приглашения. Это создаёт дополнительную нагрузку, так как теперь им приходится добавлять все индивидуальные адреса электронной почты людей, которых мы хотим пригласить (а на конференции это более сотни участников…). Делать это на каждой встрече, мероприятии и т. д. создаст значительное сопротивление нашему росту, и я предвижу, что некоторые сотрудники уйдут из-за увеличившейся рабочей нагрузки (большинство из них — волонтёры, и все они перегружены своими другими обязанностями).

2 лайка
16

Можно ли предположить, что если будет реализован вариант 3, появится возможность воспроизвести текущее поведение?

Тренировочный сайт, который мы быстро собрали, было бы гораздо сложнее реализовать без возможности обхода утверждений для групп, приглашённых массово.

1 лайк
17

Не забудьте, что здесь также возможен массовый приглашение. Если ваше мероприятие генерирует CSV-файл с участниками, вы можете использовать его для прямого приглашения всех.

Если нет, вы также можете поделиться ссылкой на веб-форму для заполнения CSV-файла и предварительной проверки пользователей перед отправкой массового приглашения.

18

К сожалению, на наших типичных мероприятиях у нас нет доступа к такой информации. Списки контактов организаторами конференций/встреч рассматриваются как ПДн (персональные данные). Даже если бы у нас был доступ, у нас просто нет ресурсов для использования этой функции. Нам пришлось бы обращаться к контактному лицу, которое всегда перегружено (даже если нам разрешено иметь доступ к этой информации). В результате процесс становится крайне трудоемким: к тому моменту, когда мы получаем ссылки для приглашений, мероприятие уже завершено, и импульс утрачен (как нашим сотрудником, так и потенциальными приглашаемыми).

1 лайк
19

Принято. Это может стать обходным решением. Однако это создаст дополнительную нагрузку на наших сотрудников, у которых и так не хватает времени на обработку этого дополнительного шага. Поэтому такой вариант не идеален.

1 лайк
20

Я вижу, что это вызвало у вас и вашего сообщества некоторые проблемы, и мне очень жаль!

Теперь, когда вы знаете, как это работает, вы и ваши коллеги-администраторы и модераторы сможете с осторожностью использовать систему приглашений!

Вопрос о том, является ли это функцией или ошибкой, касается приоритетов — мы стараемся быстро исправлять ошибки, особенно если они связаны с безопасностью! Однако в данном случае функциональность остаётся такой же, как и на протяжении многих лет, и это сделано намеренно. Я считаю, что это нужно изменить, но это не тот случай, когда всё нужно бросить и исправить прямо сейчас.

Мы дадим немного времени, чтобы другие могли высказать своё мнение, чтобы мы могли определить направление, в котором хотим двигаться.

2 лайка
21

В зависимости от того, как «guardian» участвует в различных элементах этого процесса, изменения могут оказаться гораздо более сложными, но есть ещё один вариант, который также зависит от пункта 3:

  1. Добавить булево свойство к самим приглашениям для обхода одобрения пользователя. По умолчанию это свойство будет выключено и будет доступно в интерфейсе создания приглашения только тогда, когда включена настройка must_approve_users.

Редактирование: На самом деле, ещё раз посмотрев на код, на который ссылался Дэвид, я полагаю, что «guardian» вообще не участвует в решении вопроса о необходимости одобрения приглашённого пользователя. Похоже, что эту часть можно реализовать простым заменой invite.invited_by.staff? на что-то вроде invite.bypass_approval?.

1 лайк
Allow users invited by staff to skip approval
22

Я полностью понимаю ваши ограничения в плане приоритизации. Думаю, наш экземпляр находится в необычной ситуации, поскольку все экземпляры Discourse, которые мне известны, принадлежат организациям, не имеющим столь строгих политик безопасности, которые обязательны для нас. Например, ограничение «только по приглашениям» было наложено нашей организацией — наш экземпляр не мог бы существовать с возможностью самостоятельной регистрации. При самостоятельной регистрации всё было бы проще, и нам не приходилось бы использовать неограниченные приглашения, которые могут «распространяться».

2 лайка