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

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

В даний час більше 90% сайтів відкриваються користувачами Chrome з використанням HTTPS. Наявність вставок, що завантажуються без шифрування, створює загрози порушення безпеки через модифікацію незахищеного контенту за наявності контролю за каналом зв'язку (наприклад, при підключенні через відкриті Wi-Fi). Індикатор змішаного контенту визнаний неефективним і вводить в оману, оскільки він не дає однозначної оцінки безпеки сторінки.

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

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

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

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

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

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

Для збереження конфіденційності при зверненні до зовнішнього API передається лише перші два байти хешу від зв'язки з логіну та пароля (для хешування використовується алгоритм Аргон2). Повний хеш шифрується ключем, що генерується на стороні користувача. Вихідні хеші в базі Google також додатково шифруються і залишаються для індексації лише перші два байти хешу. Кінцева звірка хешів, що підпадають під переданий двобайтовий префікс, проводиться на стороні користувача з використанням криптографічної техніки.засліплення«, за якої жодна зі сторін не знає вміст даних, що перевіряються. Для захисту від визначення вмісту бази скомпрометованих облікових записів шляхом перебору із запитом довільних префіксів дані шифруються в прив'язці до ключа, згенерованого на основі перевіреної зв'язки логіну і пароля.

Джерело: opennet.ru

Додати коментар або відгук