Новая уязвимость в OC Android

Новая уязвимость в OC Android

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

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

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

"1. Обозреватель Android не задает пользователю никаких вопросов при загрузке файла из Интернета; объект payload.html, например, будет сохранен как /sdcard/download/payload.html.
2. С помощью JavaScript можно заставить устройство автоматически запустить этот файл, так что сохраненный payload.html будет отображен в браузере.
3. Открывая сохраненный файл в локальном контексте, обозреватель обработает и исполнит JavaScript-код, причем опять же без отображения каких бы то ни было уведомлений.
4. Когда HTML-файл открыт в локальном контексте, сценарий на JavaScript оказывается вправе читать содержимое файлов на карте памяти и некоторые другие данные.
5. Прочитав информацию из файла, тот же самый сценарий может отправить ее на удаленный сервер".

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

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

Специалист рекомендовал владельцам Android-устройств пользоваться сторонними обозревателями (например, Opera), или же отключить обработку JavaScript в параметрах встроенного браузера. Сама Google предложила другой вариант - попросту отсоединить на время карту памяти и ждать выхода патча.

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

Firefox 148 первым внедрил встроенную защиту от XSS

Mozilla сделала важный шаг в борьбе с одной из самых живучих веб-уязвимостей — XSS (межсайтовый скриптинг). В Firefox 148 компания первой внедрила стандартизированный Sanitizer API, встроенный инструмент для очистки небезопасного HTML прямо на уровне браузера.

XSS десятилетиями остаётся в топе самых распространённых проблем веб-безопасности.

Суть проста: если сайт позволяет злоумышленнику вставить вредоносный HTML или JavaScript через пользовательский контент, атакующий может перехватывать действия пользователя, красть данные и управлять сессией до тех пор, пока уязвимость не будет закрыта. Несмотря на множество защитных механизмов, XSS стабильно держится в числе лидеров рейтингов вроде CWE-79.

Раньше разработчики полагались, например, на Content Security Policy (CSP), но её внедрение часто требовало серьёзной переработки архитектуры и постоянного контроля со стороны специалистов по безопасности. Для небольших проектов это оказывалось слишком сложно.

Sanitizer API призван упростить задачу. Он позволяет очищать небезопасный HTML перед тем, как вставлять его в DOM. Главная цель — заменить рискованное использование свойства innerHTML, которое «слепо» вставляет и исполняет всё, что ему передали.

Вместо этого предлагается метод setHTML(). Если злоумышленник попытается внедрить что-то вроде <img src=x onerror=alert(1)>, новый механизм автоматически удалит опасный атрибут onerror. В итоге пользователь увидит безопасный HTML без выполнения вредоносного кода.

По умолчанию API работает в безопасной конфигурации, но разработчики могут настраивать его под свои задачи — определять, какие теги и атрибуты разрешены, а какие нужно удалять. Для более строгого контроля Sanitizer API можно использовать вместе с Trusted Types, что позволит централизованно управлять вставкой HTML и блокировать небезопасные методы.

Появление Sanitizer API в Firefox 148 фактически открывает новую главу в браузерной защите от XSS. Ожидается, что другие крупные браузеры тоже внедрят этот стандарт.

Если setHTML() действительно начнёт массово вытеснять innerHTML, у разработчиков наконец появится простой и встроенный инструмент против одной из самых старых и упорных уязвимостей интернета.

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