Google попередила про зміну підходу до обробки змішаного контенту на сторінках HTTPS
Google попередила про зміну підходу до обробки змішаного контенту на сторінках, відкритих за 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 також додатково шифруються і залишаються для індексації лише перші два байти хешу. Кінцева звірка хешів, що підпадають під переданий двобайтовий префікс, проводиться на стороні користувача з використанням криптографічної техніки "сліплення", при якій жодна зі сторін не знає вміст даних, що перевіряються. Для захисту від визначення вмісту бази скомпрометованих облікових записів шляхом перебору із запитом довільних префіксів, дані, що віддаються, шифруються в прив'язці до ключа, згенерованого на основі перевіреної зв'язки логіна і пароля.
