Обнаружено 5 критических уязвимостей в инструменте

5 critical vulnerabilities found in google s threadit collaboration tool

Изучите пять ключевых уязвимостей безопасности в приложении Threadit от Google, включая XSS, кликджекинг, обход списков контроля доступа (ACL) и утечки информации с подробным анализом.

Обнаружено 5 критических уязвимостей в инструменте для совместной работы Threadit от Google

Threadit — это веб-платформа, разработанная экспериментальным подразделением Google, Area 120, которая позволяла пользователям создавать и легко делиться короткими видеосообщениями. Запущенный в марте 2021 года и закрытый в декабре 2022 года, инструмент был направлен на улучшение командного сотрудничества с помощью коротких видеоклипов.

Баннер Threadit
Рекламный баннер Threadit

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

Содержание

  1. DOM-основанный XSS в сочетании с кликджекингом
  2. Удаление владельца публикации из списков контроля доступа (ACL)
  3. Кликджекинг для удаления учетных записей пользователей
  4. Несанкционированный доступ к спискам просмотров публичных публикаций
  5. Раскрытие информации о вошедших пользователях

DOM-основанный XSS в сочетании с кликджекингом

Межсайтовый скриптинг (XSS) — распространённая уязвимость клиентской стороны, при которой вредоносные скрипты внедряются в доверенные сайты. Интерфейс Threadit позволял внедрять ссылки без строгой проверки. Злоумышленник мог использовать это, изменяя параметр URL для запуска выполнения JavaScript в DOM, что представляет собой форму DOM-основанного XSS.

Шаги эксплуатации

  • Создайте новую публикацию в Threadit с призывом к действию (CTA) в виде ссылки.
  • Перехватите и измените PATCH-запрос, внедрив URI с префиксом javascript: в поле URL ссылки.
  • Опубликуйте пост, который теперь содержит вредоносную ссылку.
  • Когда пользователь нажимает на CTA-ссылку, в зависимости от браузера скрипт может выполниться.

Примечательно, что браузеры на базе Chromium блокируют URI javascript: при открытии в новых вкладках (из-за использования атрибута target="_blank"), в то время как Firefox допускает их выполнение. Для обхода этого ограничения и обеспечения эксплуатации в разных браузерах злоумышленники могут манипулировать взаимодействиями пользователя, например, заставляя ссылки открываться в той же вкладке.

Добавление усиления через кликджекинг

В Threadit отсутствовал HTTP-заголовок X-Frame-Options, что позволило внедрять страницы в фреймы или iframe на сторонних сайтах. Это приводило к эффективным атакам типа кликджекинг, когда прозрачный iframe накладывался поверх вредоносной ссылки, на которую пользователи нажимали, не подозревая об этом. Злоумышленники использовали CSS и JavaScript для точного позиционирования интерактивных элементов iframe под курсором мыши.

Меры предотвращения:

  • Строгое проверять и валидировать URL; разрешать только схемы http:// или https:// для ссылок.
  • Устанавливать заголовки X-Frame-Options: DENY или Content-Security-Policy: frame-ancestors 'none', чтобы предотвратить встраивание страниц.
  • Добавлять rel="noopener" для ссылок, чтобы смягчить атаки через API window.opener.

Хронология обработки уязвимости:

Дата Событие
2021-05-02 Уязвимость сообщена
2021-05-03 Назначен приоритет: P2
2021-05-04 Принято командой разработчиков
2021-05-06 Ошибка исправлена и выдано вознаграждение

Удаление владельца публикации из списков контроля доступа (ACL)

Списки контроля доступа управляют правами пользователей на просмотр и изменение содержимого. В Threadit критическая ошибка позволяла авторизованным зрителям — не только владельцу — неправомерно изменять записи в ACL, включая удаление прав владения владельца публикации.

Как работала уязвимость

  • Пользователи с правом просмотра могли добавлять новых зрителей по их email-адресам.
  • Затем эти пользователи могли удалять только что добавленных зрителей.
  • Используя эту логику, злоумышленник мог понизить роль владельца с ROLE_OWNER до ROLE_READ.
  • После понижения злоумышленник мог полностью удалить владельца, лишив его доступа к контенту.
Сообщение с предупреждением при отзыве доступа
Предупреждение, показываемое владельцу после потери доступа

Последствия для безопасности

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

Рекомендуемые исправления

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

Хронология инцидента:

Дата Событие
2021-07-08 Уязвимость обнаружена и сообщена
2021-07-09 Подтверждена как риск злоупотребления
2021-07-20 Исправлено и выдано вознаграждение

Атака кликджекинга, приводящая к удалению учетной записи

Страница профиля пользователя Threadit предусматривала функцию удаления аккаунта. В сочетании с ранее описанной уязвимостью встраивания через iframe (отсутствие защитных заголовков) злоумышленники могли провести сложную атаку кликджекинг для тайного удаления учетных записей пользователей.

Методика атаки

  • Встраивают страницу профиля в скрытый iframe на сайте, контролируемом атакующим.
  • С помощью CSS и JavaScript перемещают iframe, выравнивая кнопку Удалить аккаунт под точкой клика пользователя.
  • Отслеживают клики пользователя; после каждого клика программно переключают iframe к следующему элементу интерфейса для нажатия.
  • Последовательные клики на сайте жертвы приводят к тому, что iframe «кликает» через диалоговые окна подтверждения, в итоге удаляя аккаунт пользователя.
Видеодемонстрация процесса атаки кликджекинг

Стратегии смягчения

  • Устанавливать строгие HTTP-заголовки для предотвращения фрейминга, такие как X-Frame-Options: DENY или директивы CSP frame-ancestors.
  • Внедрять дополнительные CSRF-токены и подтверждения пользовательских действий для критических операций.
  • Использовать элементы UI, которые труднее автоматизировать, например CAPTCHA или биометрическую аутентификацию.

Важные даты:

Дата Событие
2021-07-08 Уязвимость сообщена и признана
2021-07-20 Исправлено и выплачено вознаграждение

Несанкционированный доступ к спискам просмотров публичных публикаций

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

Подробности

  • Интерфейс приложения скрывает иконку “зрители” для анонимных посетителей, что намекает на ограниченный доступ.
  • Несмотря на это ограничение интерфейса, неавторизованные GET-запросы на /message/{messageId} возвращали полный список зрителей.
  • Это приводило к непреднамеренной утечке конфиденциальных данных пользователей в публичный доступ.
Список зрителей
Список зрителей, отображаемый авторизованным пользователям

Риски для безопасности

Эта уязвимость раскрывала персональные данные, нарушая принципы конфиденциальности и потенциально нарушая законодательство, например GDPR.

Рекомендации по устранению

  • Обеспечить контроль доступа на сервере для списков просмотров, ограничив их видимость только авторизованными пользователями.
  • Провести аудит API, чтобы предотвратить раскрытие информации через неаутентифицированные эндпоинты.
  • Регулярное проведение тестов на проникновение для выявления подобных утечек данных.

Хронология уязвимости:

Дата Событие
2021-07-07 Сообщено
2021-08-10 Выдано вознаграждение; рассмотрено частичное исправление

Раскрытие информации о вошедших пользователях через встраивание iframe

Дополнительная проблема, связанная с встраиванием iframe, позволяла злоумышленникам определить email-адреса и данные профиля посещающих пользователей посредством скрытого поста Threadit, встроенного на их собственных сайтах.

Механика утечки

  • Если пользователь вошёл в Threadit и посещает сайт атакующего, где спрятан iframe с постом Threadit, его сессия автоматически регистрируется в списке зрителей этого поста.
  • Злоумышленники затем могут отправлять API-запросы для получения этого списка зрителей и извлечения данных вошедшего пользователя.

Эта форма межсайтовой утечки информации эксплуатирует недостаточные междоменные ограничения и неправильное использование информации о сессиях.

Последствия и смягчение

Хотя команда Threadit обозначила это как «задуманное поведение», данная угроза подчёркивает важность использования frame-опций для блокировки несанкционированного встраивания.

  • Внедрение заголовка X-Frame-Options: DENY предотвращает встраивание, смягчая таким образом риски скрытых атак.
  • При дальнейшем проектировании следует учитывать вопросы конфиденциальности, связанные с автоматической регистрацией и раскрытием данных зрителей.
  • Пользователям рекомендуется быть осторожными с посещаемыми сайтами во время авторизации, чтобы избежать непреднамеренной утечки данных.

Ключевые даты:

Дата Событие
2021-07-03 Проблема сообщена
2021-07-05 Закрыта с пометкой “не исправлять”

Дополнительные заметки: Уязвимость XSS в расширении Threadit для Chrome

Помимо веб-приложения, расширение Threadit для Chrome интегрировало функциональность Threadit с платформами, такими как Gmail. Расширение также было уязвимо к DOM-основанной атаке XSS через postMessage, что позволяло выполнять скрипты внутри Gmail при установленном расширении.

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

Дальнейший анализ проблем безопасности расширения будет представлен в последующей статье.


Заключение

Исследование Threadit от Google выявляет множество значительных уязвимостей, включая DOM XSS, кликджекинг, неправильное управление ACL и утечки приватных данных. Эти выводы подчёркивают сложность и критическую важность надежных методов веб-безопасности, особенно в платформах для совместной работы и коммуникации, которые обрабатывают чувствительные данные пользователей.

Внедрение базовых механизмов веб-безопасности, таких как строгая проверка входных данных, корректное управление доступом, политика frame-ancestors и надежная авторизация API, является обязательным для защиты пользователей от описанных векторов атак.

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