Google за промяна на подхода за обработка на смесено съдържание на страници, отворени чрез HTTPS. Преди това, ако имаше компоненти на страници, отворени чрез HTTPS, които бяха заредени от без криптиране (чрез http:// протокола), се показваше специален индикатор. В бъдеще беше решено да се блокира зареждането на такива ресурси по подразбиране. По този начин страниците, отворени чрез „https://“, ще бъдат гарантирани, че съдържат само ресурси, изтеглени чрез защитен комуникационен канал.
Отбелязва се, че в момента повече от 90% от сайтовете се отварят от потребители на Chrome чрез HTTPS. Наличието на вложки, заредени без криптиране, създава заплахи за сигурността чрез модифициране на незащитено съдържание, ако има контрол върху комуникационния канал (например при свързване чрез отворен Wi-Fi). Установено е, че индикаторът за смесено съдържание е неефективен и подвеждащ за потребителя, тъй като не дава ясна оценка за сигурността на страницата.
Понастоящем най-опасните видове смесено съдържание, като скриптове и iframe, вече са блокирани по подразбиране, но изображения, аудио файлове и видеоклипове все още могат да бъдат изтеглени чрез http://. Чрез подправяне на изображения нападателят може да замени бисквитки за проследяване на потребители, да се опита да използва уязвимости в процесорите за обработка на изображения или да извърши фалшификация, като замени информацията, предоставена в изображението.
Въвеждането на блокировката е разделено на няколко етапа. Chrome 79, планиран за 10 декември, ще включва нова настройка, която ще ви позволи да деактивирате блокирането за конкретни сайтове. Тази настройка ще бъде приложена към смесено съдържание, което вече е блокирано, като скриптове и вградени рамки, и ще бъде извикана от падащото меню, когато щракнете върху символа за заключване, заменяйки предложения преди това индикатор за деактивиране на блокирането.
Chrome 80, който се очаква на 4 февруари, ще използва мека схема за блокиране на аудио и видео файлове, което предполага автоматична замяна на връзките http:// с https://, което ще запази функционалността, ако проблемният ресурс е достъпен и през HTTPS . Изображенията ще продължат да се зареждат без промени, но ако се изтеглят през http://, страниците https:// ще показват индикатор за несигурна връзка за цялата страница. За да променят автоматично към https или да блокират изображения, разработчиците на сайтове ще могат да използват свойствата на CSP upgrade-insecure-requests и block-all-mixed-content. Chrome 81, планиран за 17 март, автоматично ще коригира http:// на https:// за смесени качвания на изображения.
Освен това Google относно интегрирането в едно от следващите издания на браузъра Chome на новия компонент за проверка на паролата, по-рано във формата . Интегрирането ще доведе до появата в обикновения мениджър на пароли на Chrome на инструменти за анализиране на надеждността на паролите, използвани от потребителя. Когато се опитате да влезете в който и да е сайт, вашето потребителско име и парола ще бъдат проверени спрямо база данни с компрометирани акаунти, като се покаже предупреждение, ако бъдат открити проблеми. Проверката се извършва срещу база данни, обхващаща повече от 4 милиарда компрометирани акаунта, появили се в изтекли потребителски бази данни. Предупреждение също ще се покаже, ако се опитате да използвате тривиални пароли като "abc123" (от Google 23% от американците използват подобни пароли) или когато използват една и съща парола на множество сайтове.
За да се запази поверителността, при достъп до външен API се предават само първите два байта от хеша на потребителското име и паролата (използва се алгоритъмът за хеширане ). Пълният хеш е криптиран с ключ, генериран от страна на потребителя. Оригиналните хешове в базата данни на Google също са допълнително криптирани и само първите два байта от хеша са оставени за индексиране. Окончателната проверка на хешовете, които попадат под предадения двубайтов префикс, се извършва от страна на потребителя с помощта на криптографска технология ““, в който нито една от страните не знае съдържанието на проверяваните данни. За да се защити съдържанието на база данни от компрометирани акаунти, което се определя чрез груба сила с искане за произволни префикси, предаваните данни се криптират във връзка с ключ, генериран въз основа на проверена комбинация от потребителско име и парола.
Източник: opennet.ru