Сегодня я обнаружил тревожную уязвимость: администратор может читать личные сообщения пользователей, не покидая панель управления.
Кроме того, администратор может скрыть вход в учётную запись пользователя, обходя пароль и двухфакторную аутентификацию (2FA), чтобы читать зашифрованные сообщения (Discourse Encrypt).
Я подозреваю, что я не единственный, кто ужасается объёму прав администратора, и позиция разработчиков Discourse остаётся неизменной — приватность пользователей ничего не стоит.
Хочу спросить: возможно, кто-то уже нашёл решение этой проблемы, чтобы сделать возможности администратора более прозрачными и уведомлять пользователя о том, что администратор авторизовался в его аккаунте или прочитал его личные сообщения?
Нет, эту запись в логах могут просматривать только администраторы и модераторы.
Я хочу уведомлять пользователей, если администратор или модератор входит в их аккаунт или читает личные сообщения.
Отправлять уведомления через системного бота в личные сообщения или отображать эти действия в профиле пользователя. Например, создать меню «Логи» в настройках аккаунта, где пользователи смогут просматривать такие действия (вход в аккаунт/чтение ЛС администраторами или модераторами).
Если память мне не изменяет, функция доступности личных сообщений (PM) доступна только администраторам. Модераторы не могут открывать сообщения других пользователей. Таким образом, простой ответ: права администратора следует предоставлять только тем, кто непосредственно обслуживает и управляет самим экземпляром Discourse. С технической точки зрения лица, управляющие вашим экземпляром, могут получить доступ к личным сообщениям напрямую из базы данных, не создавая записей в журналах. Как администратор сайта и сервера, на котором он размещён, вы можете в конечном итоге предотвратить получение администраторами такого уровня доступа только одним способом: зашифровать содержимое с помощью ключа, которого у них нет.
Для уровня безопасности, который вы ищете, вам в основном понадобится следующее:
Я ещё не использовал этот инструмент, но, насколько я понимаю, он генерирует и хранит ключи на стороне клиента таким образом, что они не будут доступны через функцию имперсонации. Ключ по-прежнему хранится локально, и имперсонация не должна предоставлять к нему доступ (насколько мне известно). Это действительно единственный способ защитить данные непосредственно в базе данных.
Меня очень раздражает, что «открытый исходный код» Discourse сильно ограничивает возможности администратора. Он крайне ограничен в тонких настройках этого форума, я не могу:
отключить активацию по электронной почте
удалить стандартные значки
изменить CSP nginx на более безопасный для onebox (iplogger)
очистить все логи и статистику
устанавливать плагины через панель администратора
устанавливать без Docker с доменом (не localhost)
просматривать, кто онлайн, без плагина (лмфао)
устанавливать Discourse на сервере с локалью не из США
задавать имя пользователя и пароль для моей базы данных при установке форума
Но Discourse — очень хороший продукт для слежки за пользователями и сбора большего количества информации об их активности.
На самом деле, нет. Вы не можете читать зашифрованные сообщения других пользователей, если у вас нет их ключа для расшифровки. Шифрование/расшифровка происходит на стороне клиента, а не на сервере, и зашифрованные сообщения хранятся на сервере в зашифрованном виде.
Возможность администраторов читать личные сообщения — это часто обсуждаемый вопрос, и он не будет изменён. Если вас беспокоят конфиденциальность и безопасность, строго ограничьте круг лиц, имеющих доступ администратора, и входите в систему под учётной записью администратора только тогда, когда вам нужно изменить настройки сайта или скачать резервную копию.
Похоже, вы довольно недовольны Discourse. Это программное обеспечение с открытым исходным кодом, поэтому вы можете использовать другое решение.
Вы уверены, что смотрели на зашифрованные сообщения? Пользователь должен фактически настроить это и начать использовать для отправки/получения сообщений. Существующие сообщения, созданные до этого, не будут зашифрованы, и они также могут по-прежнему отправлять незашифрованные сообщения.
Жаль это слышать, но желаю вам всего наилучшего и удачи!
Кажется, вы смотрите на незашифрованные сообщения. Чтобы расшифровать их, администратору пришлось бы знать пароль пользователя, но пароли хранятся в виде хешей PBKDF2, что делает процесс перебора хешей очень затратным и длительным. У плагина для зашифрованных личных сообщений есть функция срока действия, если вам нужна дополнительная приватность. В любом случае, даже если в интерфейсе администратора не будет опции чтения личных сообщений, они всё равно будут храниться в базе данных в открытом виде, если не используется плагин шифрования.
Открытый исходный код не означает приватность; похоже, вы путаете термины.
