Ошибка «Access Denied» при попытке изменить некоторые тексты на сайте

[jordan-violet]

Кроме того, с тех пор как я начал двигаться по этому пути, при попытке редактировать определенные тексты сайта я вижу следующее:

[tobiaseigen]

Отличное замечание, и извините за задержку с ответом! В следующий раз создайте тему с тегом bug, чтобы привлечь к ней внимание быстрее!

Мне удалось воспроизвести это здесь, на meta, и на моем личном сайте, используя URL из вашего скриншота.

/admin/customize/site_texts?q=confirm%20old

[Moin]

@tobiaseigen

/admin/customize/site_texts?q=confirm%20old

Кажется, я не припоминаю, чтобы эта ссылка когда-либо работала без параметра локали

/admin/customize/site_texts?q=confirm%20old&locale=en у меня работает нормально.

И, я думаю, тот факт, что вы не можете настроить текст «подтвердить старый email», является намеренным. Это письмо отправляется только сотрудникам.

@codinghorror

Однако

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

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

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

• этот конкретный шаблон письма никогда не отправляется никому, кроме сотрудников, при смене email, так как должны быть подтверждены как старый, так и новый адреса. Для обычного пользователя требуется подтверждение только нового email. Таким образом, изменение этого шаблона по косметическим или дизайнерским причинам будет видно только сотрудникам, но никогда обычным пользователям, и поэтому не имеет значения.
• риск разрешения администраторам изменять этот шаблон слишком велик, как показывает вышеописанная РЕАЛЬНАЯ история, которая действительно произошла и стала критическим шагом, позволившим злоумышленнику получить доступ ко всей базе данных Discourse.

[tobiaseigen]

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

[RGJ (Richard - Communiteq)]

Похоже, что пользовательский интерфейс не получает пользовательское сообщение?

[Moin]

@Moin

Это письмо отправляется только сотрудникам.

Мне стало известно, что со времени публикации на Codinghorror была добавлена настройка «Требовать подтверждение смены email». Это означает, что сообщение теперь может быть отправлено не только сотрудникам.

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

1. Использовать пароль для настройки двухфакторной аутентификации для этой учётной записи.
2. Создать новую учётную запись.
3. Использовать код 2FA, чтобы предоставить новой учётной записи права администратора.

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

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

Кроме того, Data Explorer теперь всегда установлен и может использоваться для доступа к базе данных.

[zogstrip]

@Moin

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

Действительно, и решение заключается в том, чтобы не показывать их при фильтрации или поиске.

FIX: Filter restricted email template keys from site text search (#36857)

[Moin]

Разве не находить ничего более запутывает, чем видеть сообщение об ошибке, которое должно быть показано? А как насчет того факта, что это больше не отправляется только сотрудникам и больше не требуется для загрузки резервной копии?