Кампанія 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 перадаецца толькі першыя два байта хэша ад звязкі з лагіна і пароля (для хэшавання выкарыстоўваецца алгарытм ). Поўны хэш шыфруецца ключом, які генеруецца на баку карыстальніка. Зыходныя хэшы ў базе Google таксама дадаткова шыфруюцца і пакідаюцца для індэксацыі толькі першыя два байта хэша. Канчатковая зверка хэшаў, якія падпадаюць пад перададзены двухбайтавы прэфікс, вырабляецца на баку карыстальніка з выкарыстаннем крыптаграфічнай тэхнікі.«, пры якой ніводны з бакоў не ведае змесціва правяраных дадзеных. Для абароны ад вызначэння змесціва базы скампраметаваных уліковых запісаў шляхам перабору з запытам адвольных прэфіксаў, якія аддаюцца дадзеныя шыфруюцца ў прывязцы да ключа, згенераванаму на аснове правяранага звязка лагіна і пароля.
Крыніца: opennet.ru