Google Chrome
Nagbabala ang Google ng isang pagbabago sa diskarte sa paghawak ng halo-halong nilalaman sa mga pahinang binuksan sa pamamagitan ng HTTPS. Dati, kung mayroong mga bahagi sa mga bukas na pahina na may HTTPS na na-load nang walang pag-encrypt (gamit ang http: // protocol), isang espesyal na prompt ang ipinakita.
Ngayon, para sa mga susunod na bersyon ng browser, napagpasyahan na harangan ang paglo-load ng mga mapagkukunang ito default. Samakatuwid, tiyakin na ang mga pahina na binuksan sa pamamagitan ng "https: //" ay naglalaman lamang ng mga mapagkukunan na na-load sa pamamagitan ng isang ligtas na channel ng komunikasyon.
Napansin na ang mga gumagamit ng Chrome sa kasalukuyan ay nagbubukas ng higit sa 90% ng mga site na gumagamit ng HTTPS. Ang pagkakaroon ng mga pagsingit na na-download nang walang pag-encrypt ay lumilikha ng isang banta ng paglabag sa seguridad sa pamamagitan ng pagbabago ng hindi secure na nilalaman sa pagkakaroon ng kontrol sa channel ng komunikasyon (halimbawa, kapag kumokonekta sa pamamagitan ng bukas na Wi-Fi).
Ang halo-halong tagapagpahiwatig ng nilalaman ay kinikilala bilang hindi epektibo at nakaliligaw, dahil hindi ito nag-aalok ng isang hindi tiyak na pagtatasa ng seguridad ng pahina.
sa kasalukuyan, ang pinaka-mapanganib na uri ng halo-halong nilalaman, tulad ng mga script at iframes, ay na-block na bilang default, ngunit ang mga imahe, tunog file at video ay maaari pa ring ma-download sa pamamagitan ng “http: //”.
Sa pamamagitan ng pagpapalit ng mga imahe, maaaring palitan ng magsasalakay ang mga pagkilos sa pagsubaybay sa cookie, subukang samantalahin ang mga kahinaan sa mga nagpoproseso ng imahe o gumawa ng isang pandaraya, pinapalitan ang impormasyong ipinakita sa imahe.
Ang pagpapakilala ng blockade ay nahahati sa maraming mga yugto. Sa Chrome 79 (na naka-iskedyul para sa Disyembre 10), Lilitaw ang isang bagong setting na hindi magpapagana ng pag-block ng mga tukoy na mga site.
Ang tinukoy na mga setting ay ilalapat sa halo-halong nilalaman na naka-block, tulad ng mga script at iframes at isasaaktibo sa pamamagitan ng menu na lilitaw kapag na-click mo ang simbolo ng lock, pinapalitan ang dating iminungkahing tagapagpahiwatig upang i-deactivate ang pag-block.
Habang para sa Chrome 80 (inaasahan sa Pebrero 4) isang locking scheme ang gagamitin para sa mga file ng audio at video, na nagsasangkot ng awtomatikong kapalit mula sa http: // hanggang https: // na panatilihin itong gumana kung ang mapagkukunan ng problema ay magagamit din sa pamamagitan ng HTTPS.
Ang mga imahe ay magpapatuloy na mag-upload ng hindi nabago, ngunit sa kaso ng pag-download sa pamamagitan ng mga pahina ng http: // sa https: // para sa buong pahina, isang pahiwatig ng isang hindi secure na koneksyon ang sisimulan. Para sa awtomatikong kapalit ng https o pag-block ng mga imahe, magagamit ng mga developer ng site ang na-update-insecure-mga kahilingan-at block-all-content-halo-halong mga katangian ng CSP.
Ang paglulunsad ng Chrome 81, na naka-iskedyul sa Marso 17, gagamit ng AutoCorrect mula sa http: // hanggang https: // para sa mga halo-halong pag-download ng imahe.
Bilang karagdagan, inihayag ng Google pagsasama sa isa sa mga susunod na bersyon ng Chome browser, isang bagong bahagi ng Pag-check up ng Password, dating binuo bilang isang panlabas na plugin.
Ang pagsasama ay hahantong sa hitsura sa buong-tagapamahala ng password Mga tool sa Chrome upang pag-aralan ang pagiging maaasahan ng mga ginamit na password ng gumagamit. Kapag sinubukan mong maglagay ng anumang site, ang username at password ay mapatunayan laban sa database ng mga nakompromisong account na may isang babala sakaling may mga problema.
Isinasagawa ang pagpapatunay sa isang database na sumasaklaw sa higit sa 4 bilyong nakompromisong mga account na ipinakita sa mga pagtagas ng mga database ng gumagamit. Ipapakita rin ang isang babala kapag sinusubukan na gumamit ng mga walang kabuluhang password tulad ng "abc123" (istatistika ng Google 23% ng mga Amerikano ang gumagamit ng mga password na ito), o kapag gumagamit sila ng parehong password sa maraming mga site.
Upang mapanatili ang pagiging kompidensiyal, kapag na-access ang panlabas na API, ang unang dalawang byte lamang ng hash ang inililipat mula sa koneksyon mula sa pag-login at password (ginagamit ang Argon2 algorithm para sa hash). Ang buong hash ay naka-encrypt ng isang key na binuo ng gumagamit.
Ang orihinal na mga hash sa database ng Google ay karagdagan din na naka-encrypt at ang unang dalawang byte lamang ng hash ang mananatili para sa pag-index.
Upang bantayan laban sa pagtukoy ng nilalaman ng nakompromiso na mga database ng mga account sa pamamagitan ng pag-enumerate ng mga random na awas, ang naibalik na data ay naka-encrypt na kaugnay sa nabuong susi batay sa na-verify na link sa pag-login at password.
Fuente: https://security.googleblog.com