Google Chrome 84: защита от вредоносных уведомлений и загрузок по HTTP

Google Chrome 84: защита от вредоносных уведомлений и загрузок по HTTP

Google Chrome 84: защита от вредоносных уведомлений и загрузок по HTTP

Разработчики Google выпустили очередную версию браузера — Chrome 84. Основное внимание в новом релизе уделили вопросу безопасности пользователей, а также внедрили несколько новых API для сторонних девелоперов.

Что касается новых функций — к сожалению, их не так много в Chrome 84. Тем не менее Google улучшила защиту от навязчивых мошеннических уведомлений, от скачивания смешанного контента и избавила пользователей от небезопасных TLS-протоколов.

Например, корпорация наконец отказалась от TLS 1.0 и 1.1. Напомним, что ещё в 2018 году Microsoft, Google, Apple и Mozilla договорились прекратить поддержку этих небезопасных версий протокола в своих продуктах.

Изначально Google планировала убрать TLS 1.0 и 1.1 с выходом Chrome 81. Однако всем известная пандемия COVID-19 поменяла планы интернет-гиганта, поскольку на тот момент важно было обеспечить пользователям бесперебойный доступ к сайтам организаций сферы здравоохранения.

Но время TLS 1.0 и 1.1 подошло к концу с выходом Chrome 84. Теперь при попытке зайти на сайт, использующий эти версии протокола, пользователь увидит предупреждение: «Ваше соединение недостаточно защищено».

 

Корпоративные клиенты могут включить поддержку TLS 1.0 и 1.1 вручную, однако такая возможность просуществует до января 2021 года.

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

В 2019 году число этого спама выросло на 69%. Как правило, юзера бомбят рекламой сайтов для взрослых, фейковыми конкурсами и нежелательными расширениями для браузера.

 

Chrome 84 будет выводить соответствующее предупреждение, если зафиксирует эксплуатацию уведомлений со стороны сайта.

Также разработчики поработали над блокировкой загрузки смешанного контента. Речь идёт о файлах, которые передаются на компьютер пользователя по небезопасному протоколу HTTP, хотя сам сайт работает по HTTPS.

 

Обновить версию интернет-обозревателя можно для систем Windows, macOS и Linux, для этого достаточно в настройках Chrome пройти в раздел «Помощь» и нажать на пункт «О Google Chrome».

Новая атака на кеш Nginx позволяет красть данные и ломать сайты

Исследователь YesWeHack Алекс Брумен описал вектор кибератаки Cache Key Injection. В случае её эксплуатации последствия для потенциальной жертвы опасные: обход контроля доступа, раскрытие закрытых страниц, отказ в обслуживании и при определённых условиях.

Как объясняет исследователь YesWeHack, проблема возникает не в Nginx по умолчанию, а в конфигурациях, где администраторы просто склеивают несколько значений переменной длины без разделителей. Например:

$scheme$host$request_uri$http_accept

Разных запроса два, а итоговая строка может получиться одна. Так, запрос к /h с заголовком Accept: ome*/* создаёт тот же ключ, что и обычное обращение к /home с Accept: */*.

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

 

Ещё веселее становится с закрытыми разделами. В лабораторном примере страница /admin была доступна только с localhost, но злоумышленник мог обратиться к /ad и перенести оставшуюся часть имени в соседний компонент ключа. Nginx видел разрешённый путь, однако доставал из кеша содержимое админ-панели.

При совпадении нескольких условий техника позволяет столкнуть HTTP- и HTTPS-запросы и записать в кеш страницу со ссылкой на атакующий JavaScript, превратив ошибку конфигурации в stored XSS. Даже Cloudflare не всегда спасёт: заголовок Authorization может провести запрос мимо его кеша прямо к уязвимому кешу Nginx.

 

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

$scheme|$host|$request_uri|$http_accept

Также следует проверять Host, перенаправлять HTTP на HTTPS и не кешировать аутентифицированные запросы.

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