Chrome начнёт блокировать HTTP-ресурсы на HTTPS-страницах и проверять надёжность паролей

Компания Google предупредила об изменении подхода к обработке смешанного контента на страницах, открытых по HTTPS. Ранее при наличии на открытых по HTTPS страницах компонентов, загружаемых с без шифрования (по протоколу http://), выводился специальный индикатор. В будущем решено блокировать загрузку подобных ресурсов по умолчанию. Таким образом, страницы, открытые по «https://», будут гарантированно содержать только ресурсы, загруженные по защищённому каналу связи.

Отмечается, что в настоящее время более 90% сайтов, открываются пользователями Chrome с использованием HTTPS. Наличие вставок, загружаемых без шифрования, создаёт угрозы нарушения безопасности через модификацию незащищённого контента при наличии контроля за каналом связи (например, при подключении через открытые Wi-Fi). Индикатор смешанного контента признан неэффективным и вводящим пользователя в заблуждение, так как он не даёт однозначной оценки безопасности страницы.

В настоящее время наиболее опасные виды смешанного контента, такие как скрипты и iframe, уже блокируются по умолчанию, но изображения, звуковые файлы и видео по-прежнему могут быть загружены по http://. Через подмену изображений атакующий может подставить отслеживающие действия пользователя Cookie, попытаться эксплуатировать уязвимости в обработчиках изображений или совершить подлог, заменив представленную на изображении информацию.

Введение блокировки разделено на несколько этапов. В Chrome 79, намеченном на 10 декабря, появится новая настройка, которая позволит отключить блокировку для конкретных сайтов. Указанная настройка будет применяться для уже блокируемого смешанного контента, такого как скрипты и iframe, и вызываться через меню, выпадающее при клике на символ замка, заменив собой ранее предлагавшийся индикатор для отключения блокировки.

В Chrome 80, который ожидается 4 февраля, будет применена мягкая схема блокировки звуковых и видео файлов, подразумевающая автоматическую замену в ссылках http:// на https://, что позволит сохранить работоспособность, если проблемный ресурс также доступен по HTTPS. Изображения продолжат загружаться без изменений, но в случае загрузки по http:// на станицах https:// для всей страницы начнёт выводится индикатор незащищённого соединения. Для автозамены на https или блокировки изображений разработчики сайтов смогут использовать CSP-свойства upgrade-insecure-requests и block-all-mixed-content. В выпуске Chrome 81, запланированном на 17 марта, при смешанной загрузке изображений будет применена автозамена на http:// на https://.

Кроме того, компания Google объявила об интеграции в один из следующих выпусков браузера Chome нового компонента Password Checkup, ранее развивавшегося в виде внешнего дополнения. Интеграция приведёт к появлению в штатном менеджере паролей Chrome средств для анализа надёжности используемых пользователем паролей. При попытке входа на любой сайт будет выполняться проверка логина и пароля по базе скомпрометированных учётных записей с выводом предупреждения в случае выявления проблем. Проверка осуществляется по базе, охватывающей более 4 миллиардов скомпрометированных аккаунтов, фигурировавших в утечках пользовательских баз. Предупреждение также будет выводиться при попытке использования тривиальных паролей, таких как «abc123» (по статистике Google 23% американцев используют подобные пароли), или при использовании одного и того же пароля на нескольких сайтах.

Для сохранения конфиденциальности при обращении к внешнему API передаётся лишь первые два байта хэша от связки из логина и пароля (для хэширования используется алгоритм Argon2). Полный хэш шифруется ключом, генерируемым на стороне пользователя. Исходные хэши в базе Google также дополнительно шифруются и оставляются для индексации только первые два байта хэша. Конечная сверка хэшей, подпадающих под переданный двухбайтовый префикс, производится на стороне пользователя с использованием криптографической техники «ослепления«, при которой ни одна из сторон не знает содержимое проверяемых данных. Для защиты от определения содержимого базы скомпрометированных учётных записей путем перебора с запросом произвольных префиксов, отдаваемые данные шифруются в привязке к ключу, сгенерированному на основе проверяемой связки логина и пароля.

Источник: opennet.ru