Уязвимость подмены URL обнаружена во многих браузерах

Уязвимость подмены URL обнаружена во многих браузерах

Уязвимость подмены URL обнаружена во многих браузерах

Chrome, Firefox и другие браузеры имеют уязвимости, связанные с подменой URL в адресной строке. Некоторые из вендоров по-прежнему работают над решением проблемы. Уязвимость обнаружил пакистанский исследователь Rafay Baloch.

Проблема проявляется на Chrome для Android, в частности, связана с тем, как пишутся арабский текст и иврит – справа налево. Если URL-адрес атакующего начинается с IP-адреса и содержит арабский символ, путь и хост меняются местами.

Например, URL 127.0.0.1/ا/http: //example.com превращается в http: //example.com/‭ا/127.0.0.1 так как содержит символ “ا”, арабскую букву. Метод работает и с другими арабскими буквами.

«Часть IP-адреса может быть легко спрятана для мобильных браузеров, если URL длинный (google.com/fakepath/fakepath/fakepath/... /127.0.0.1) - объясняет Baloch в своем блоге - Для того, чтобы сделать атаку более реалистичной, злоумышленник может использовать символ Юникода в виде замка, якобы присутствует SSL».

Похожая уязвимость была найдена и в Firefox для Android (CVE-2016-5267). В случае с Firefox, URL не должен начинаться с IP-адреса, единственным условием является наличие арабских символов. Например, http: //عربي.امارات/google.com/test/test/test становится google.com/test/test/test/عربي.امارات.

Google знает об этой проблеме уже более года. Baloch сказал, что проинформировал Google о проблеме в мае и компания откликнулась в конце июня. Mozilla исправили уязвимость в Firefox для Android 2-го августа.

Baloch также утверждает, что другие браузеры тоже уязвимы, в том числе десктопные. В случае Firefox и Chrome, уязвимость влияет только на мобильные версии.

Подпишитесь на новости

Claude Code удалил 116 ГБ и сообщил, что файлы выглядят нормально

Пользователь Windows сообщил, что Claude Code при уборке временных файлов удалил около 116 ГБ данных из его домашней директории. Затем агент заверил, что остановил команду и все выглядит целым. По описанию инцидента, удаление продолжалось еще примерно 50 минут.

В отчете на GitHub пользователь рассказывает, что работал над анализом для соревнования Kaggle.

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

Целью стала домашняя директория, указанная коротким именем Windows формата 8.3. Автор предполагает, что защитная проверка могла не распознать такой вариант пути. Точный механизм отказа защиты и режим разрешений остаются неизвестными.

Через 120 секунд задача автоматически перешла в фон. Агент запросил остановку и получил сообщение об успехе, однако, судя по описанным изменениям файловой системы, удаление продолжалось. Вероятное объяснение — дочерний процесс пережил остановку задачи.

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

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

Особенно неприятна в этой истории уверенность агента. Наличие папки еще не означает наличие файлов.

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