Chrome HTTP baliabideak blokeatzen hasiko da HTTPS orrietan eta pasahitzen sendotasuna egiaztatzen

Google ohartarazi HTTPS bidez irekitako orrialdeetan eduki mistoa prozesatzeko ikuspegia aldatzeari buruz. Aurretik, HTTPS bidez irekitako orrialdeetan enkriptaziorik gabe kargatzen ziren osagaiak bazeuden (http:// protokoloaren bidez), adierazle berezi bat bistaratzen zen. Etorkizunean, baliabide horien karga lehenespenez blokeatzea erabaki da. Horrela, β€œhttps://” bidez irekitako orrialdeek komunikazio kanal seguru baten bidez deskargatutako baliabideak soilik edukiko dituztela bermatuko da.

Kontuan izan da gaur egun guneen % 90 baino gehiago HTTPS erabiliz Chrome erabiltzaileek irekitzen dituztela. Zifratu gabe kargatutako txertaketak egoteak segurtasun mehatxuak sortzen ditu babesik gabeko edukia aldatzearen bidez, komunikazio-kanalaren gaineko kontrola badago (adibidez, Wi-Fi irekiaren bidez konektatzean). Eduki mistoaren adierazlea eraginkorra eta engainagarria dela ikusi da erabiltzailearentzat, ez baitu orriaren segurtasunaren balorazio argirik ematen.

Gaur egun, eduki misto mota arriskutsuenak, hala nola scriptak eta iframeak, lehenespenez blokeatuta daude dagoeneko, baina irudiak, audio fitxategiak eta bideoak http://-ren bidez deskargatu daitezke oraindik. Irudiaren faltsutzearen bidez, erasotzaileak erabiltzaileen jarraipeneko cookieak ordezkatu ditzake, irudi-prozesadoreetako ahuleziak ustiatzen saiatu edo faltsutzea egin dezake irudian emandako informazioa ordezkatuz.

Blokeoaren sarrera hainbat fasetan banatzen da. Abenduaren 79ean aurreikusita dagoen Chrome 10-k ezarpen berri bat izango du, gune jakin batzuen blokeoa desgaitzeko aukera emango duena. Ezarpen hau dagoeneko blokeatuta dagoen eduki mistoari aplikatuko zaio, hala nola scriptei eta iframeei, eta blokeoaren ikurra sakatzean goitibeherako menuaren bidez deituko da, blokeoa desgaitzeko aldez aurretik proposatutako adierazlea ordezkatuz.

Chrome HTTP baliabideak blokeatzen hasiko da HTTPS orrietan eta pasahitzen sendotasuna egiaztatzen

Otsailaren 80an espero den Chrome 4-k audio- eta bideo-fitxategietarako blokeo-eskema leun bat erabiliko du, http:// estekak https://-rekin automatikoki ordezkatuta, eta horrek funtzionaltasuna gordeko du baliabide arazotsua HTTPS bidez ere eskuragarri badago. . Irudiak aldaketarik gabe kargatzen jarraituko du, baina http://-ren bidez deskargatzen badira, https:// orrialdeek konexio seguruaren adierazlea erakutsiko dute orri osorako. https-ra automatikoki aldatzeko edo irudiak blokeatzeko, gunearen garatzaileek CSP propietateak eguneratzeko-seguru-eskaera-eskaerak eta blokeatu-dena-eduki mistoak erabili ahal izango dituzte. Martxoaren 81rako aurreikusita dagoen Chrome 17-ek http://-tik https://-ra automatikoki zuzenduko du irudi mistoak kargatzeko.

Chrome HTTP baliabideak blokeatzen hasiko da HTTPS orrietan eta pasahitzen sendotasuna egiaztatzen

Horrez gain, Google iragarri Pasahitza egiaztatzeko osagai berriaren Chome arakatzailearen hurrengo bertsioetako batean integratzeari buruz, aurretik garatzen inprimakian kanpoko gehikuntza. Integrazioak Chrome ohiko pasahitzen kudeatzailean erabiltzaileak erabiltzen dituen pasahitzen fidagarritasuna aztertzeko tresnak agertzea ekarriko du. Edozein gunetan saioa hasten saiatzen zarenean, zure saio-hasiera eta pasahitza arriskuan dauden kontuen datu-base batekin egiaztatuko dira, arazoak hautematen badira abisu bat agertuko delarik. Egiaztapena filtrazioko erabiltzaileen datu-baseetan agertutako arriskuan dauden 4 milioi kontu baino gehiago biltzen dituen datu-base baten aurka egiten da. "abc123" bezalako pasahitz hutsalak erabiltzen saiatzen bazara ere abisu bat agertuko da estatistikak Google-k amerikarren %23k antzeko pasahitzak erabiltzen ditu), edo pasahitz bera hainbat gunetan erabiltzen duenean.

Konfidentzialtasuna mantentzeko, kanpoko API batera sartzean, saio-hasieraren eta pasahitzaren lehen bi byteak soilik transmititzen dira (hashing algoritmoa erabiltzen da. Argona2). Hash osoa erabiltzailearen aldean sortutako gako batekin zifratzen da. Google datu-baseko jatorrizko hashak ere enkriptatuta daude eta hasharen lehen bi byteak bakarrik geratzen dira indexatzeko. Igorritako bi byteko aurrizkiaren menpe dauden hashen azken egiaztapena erabiltzailearen aldetik egiten da teknologia kriptografikoa erabiliz ".itsutasunaβ€œ, zeinetan bi aldeek ez dute ezagutzen egiaztatzen ari diren datuen edukia. Aurrizki arbitrarioen eskaerarekin indar gordinaren bidez konprometitutako kontuen datu-base baten edukia babesteko, transmititutako datuak saio-hasiera eta pasahitzaren konbinazio egiaztatu batean oinarrituta sortutako gako batekin enkriptatzen dira.

Iturria: opennet.ru

Gehitu iruzkin berria