Chrome ще започне да блокира HTTP ресурси на HTTPS страници и да проверява надеждността на паролите.

Компания Google предупреди за промяната на подхода към обработка на смесено съдържание на страници, отворени по HTTPS. По-рано, при наличие на компоненти, зареждащи се без шифроване (по протокола http://), на отворените по HTTPS страници се появяваше специален индикатор. В бъдеще решено е да се блокира зареждането на подобни ресурси по подразбиране. Така страниците, отворени по '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 обяви интегрира в едно от следващите издания на браузъра Chrome нов компонент Password Checkup, който по-рано се развиваше във формата като външно допълнение. Интеграцията ще доведе до появата в стандартния мениджър на пароли в Chrome на средства за анализ на надеждността на използваните от потребителя пароли. При опит за влизане в който и да е сайт ще се извършва проверка на логина и паролата по база данни с компрометирани акаунти с издаване на предупреждение в случай на проблем. Проверката се извършва по база данни, която обхваща повече от 4 милиарда компрометирани акаунта, фигурирали в изтичания на потребителски данни. Предупреждение ще се показва и при опит за използване на тривиални пароли, като „abc123“ (според статистика Google, 23% от американците използват подобни пароли), или при използване на същата парола на няколко сайта.

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

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

Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри 🔥 Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри | ProHoster