В Zoom Whiteboard нашли уязвимость, позволяющую провести XSS-атаку

В Zoom Whiteboard нашли уязвимость, позволяющую провести XSS-атаку

В Zoom Whiteboard нашли уязвимость, позволяющую провести XSS-атаку

Раскрыты подробности хранимой XSS-уязвимости, работающей и в десктопном, и в веб-приложении Zoom Whiteboard. Соответствующий патч был создан менее чем за месяц и вышел в августе.

Уязвимость обнаружил ИБ-исследователь Юджин Лим (Eugene Lim), известный в Сети под ником spaceraccoon. Причиной появления проблемы является некорректная санация пользовательского ввода; эксплойт сложен в исполнении, однако автору находки удалось обойти штатную проверку и внедрить свой JavaScript-код в страницу по методу межсайтового скриптинга.

Продукт Zoom Whiteboard, предназначенный для коллективной работы в реальном времени, предоставляет пользователям общую виртуальную доску с возможностью добавления и редактирования объектов: текста, фигур, картинок, записок-стикеров. Для работы с веб-страницей необходим браузер или десктопное приложение с поддержкой JavaScript.

За хранение и передачу объектов в Whiteboard отвечает разработанный в Google механизм Protocol Buffers (protobuf). С его помощью производится обновление доски; для трансляции объектов на подключенные клиенты он использует протокол WebSocket.

При получении такого сообщения клиентское приложение преобразует protobuf-объект в соответствующий компонент React и вставляет его в страницу (UI). При этом JavaScript-библиотека React по умолчанию очищает все атрибуты HTML, оставляя лишь разрешенные теги.

Для некоторых объектов очистка производится с помощью кастомных regex-функций, реализация которых, как выяснилось, далека от совершенства. В итоге Лиму удалось найти способ обойти санацию для рассылки произвольного JavaScript и проведения XSS-атаки.

В комментарии для The Daily Swig исследователь пояснил, что задачу в данном случае осложняет использование protobuf-формата. Для успешного эксплойта необходимо перехватить запрос WebSocket и корректно изменить protobuf-сообщение до того, как запрос будет сброшен. Чтобы преодолеть это препятствие, эксперт написал PoC-скрипт, использующий объект Сlipboard для создания и доставки полезной нагрузки — триггера XSS.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

ADB спасёт: установка непроверенных Android-приложений будет возможна

Google снова переписывает правила игры для Android. На прошлой неделе компания объявила, что со следующего года начнёт проверять личность всех разработчиков, распространяющих приложения для Android — не только в Google Play, но и за его пределами. Однако есть лазейка, которая может спасти сайдлоадинг.

Напомним, если автор софта не захочет пройти верификацию, его приложение просто не установится на сертифицированные устройства с Google Mobile Services.

Формально цель понятна: борьба с анонимными злоумышленниками, которые маскируют зловреды под легальные приложения. Но многие энтузиасты увидели в этом другую сторону — попытку превратить Android в закрытую экосистему по образцу iOS. Особенно громко зазвучали опасения за судьбу эмуляторов и нишевых устройств вроде Android-ридеров.

Президент Android-экосистемы Самир Самат попытался успокоить сообщество:

«Сайдлоадинг — фундамент Android, и он никуда не денется».

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

Ожидалось, что контроль возьмёт на себя Google Play Protect — встроенный сервис безопасности, который уже проверяет приложения при установке. Но, как выяснилось, Google готовит отдельный инструмент — Android Developer Verifier. Это новое системное приложение, которое будет определять, связан ли пакет с «подтверждённым» разработчиком. Производителей смартфонов обяжут предустанавливать его на устройства с Android 16 QPR2 и выше.

Почему отдельное приложение, а не расширение функций Play Protect? Версий несколько: от организационных причин до попытки снизить риски взлома GMS. Но у этого подхода есть и минусы: придётся полагаться на OEM-партнёров, которые известны своей медлительностью с обновлениями, а отключить новый Verifier, скорее всего, будет невозможно.

Есть и «лазейка»: в FAQ Google уточняет, что установить непроверенное приложение по-прежнему можно через ADB — инструмент для разработчиков, позволяющий загружать APK с компьютера. Для гиков и девелоперов это спасательный круг, для обычных пользователей — почти непреодолимый барьер.

Новые правила начнут действовать с сентября 2026 года и будут внедряться постепенно. Впереди ещё минимум год, за который Google может изменить детали. Но уже сейчас ясно: Android ждёт серьёзный сдвиг в сторону жёсткого контроля над сторонними приложениями.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

RSS: Новости на портале Anti-Malware.ru