Chrome nun havos protekton kontraŭ triaj kuketoj kaj kaŝita identigo

Guglo prezentita venontaj ŝanĝoj al Chrome celantaj plibonigi privatecon. La unua parto de la ŝanĝoj koncernas Kuketon-traktadon kaj subtenon por la SameSite-atributo. Komencante kun la liberigo de Chrome 76, atendita en julio, estos aktivigita la flago “same-site-by-default-cookies”, kiu, se mankas la SameSite-atributo en la kaplinio Set-Cookie, defaŭlte starigos la valoron “SameSite=Lax”, limigante la sendon de Kuketoj por enmetoj de triapartaj retejoj (sed retejoj ankoraŭ povos nuligi la limigon eksplicite fiksante la valoron SameSite=Neniu kiam agordas la Kuketon).

Atributo Sama Loko permesas vin difini situaciojn en kiuj estas permesate sendi Kuketon kiam peto estas ricevita de triaparta retejo. Nuntempe, la retumilo sendas Kuketon al iu ajn peto al retejo por kiu Kuketo estis agordita, eĉ se alia retejo estas komence malfermita, kaj la peto estas farita nerekte per ŝarĝo de bildo aŭ per iframe. Reklamaj retoj uzas ĉi tiun funkcion por spuri uzantmovojn inter retejoj, kaj
atakantoj por la organizo CSRF-atakoj (kiam rimedo kontrolita de la atakanto estas malfermita, peto estas sekrete sendita de ĝiaj paĝoj al alia retejo, sur kiu la nuna uzanto estas aŭtentikigita, kaj la retumilo de la uzanto starigas sesiajn Kuketojn por tia peto). Aliflanke, la kapablo sendi Kuketojn al triapartaj retejoj estas uzata por enmeti widgets en paĝojn, ekzemple, por integriĝo kun YuoTube aŭ Facebook.

Uzante la SameSit-atributon, vi povas kontroli Kuketon-konduton kaj permesi Kuketojn esti senditaj nur responde al petoj iniciatitaj de la retejo de kiu la Kuketo estis origine ricevita. SameSite povas preni tri valorojn "Strict", "Lax" kaj "Neniu". En "Strika" reĝimo, Kuketoj ne estas senditaj por ajna speco de transretejaj petoj, inkluzive de ĉiuj envenantaj ligiloj de eksteraj retejoj. En "Malstreĉa" reĝimo, pli malstreĉaj restriktoj estas aplikataj kaj Kuketo-transsendo estas blokita nur por transretejaj subpetoj, kiel bildpeto aŭ ŝargado de enhavo per iframe. La diferenco inter "Stricta" kaj "Lakso" estas blokado de Kuketoj kiam sekvas ligilon.

Inter aliaj venontaj ŝanĝoj, estas ankaŭ planite apliki striktan limigon, kiu malpermesas la prilaboradon de triaj Kuketoj por petoj sen HTTPS (kun la atributo SameSite=Nenio, Kuketoj nur povas esti agordita en Sekura reĝimo). Krome, estas planite fari laboron por protekti kontraŭ la uzo de kaŝita identigo ("foliila fingrospurado"), inkluzive de metodoj por generi identigilojn bazitajn sur nerektaj datumoj, kiel ekzemple ekrano-rezolucio, listo de subtenataj MIME-tipoj, kap-specifaj opcioj (HTTP / 2 и HTTPS), analizo de establita kromaĵojn kaj tiparojn, havebleco de certaj Retaj APIoj specifaj por vidkartoj Karakterizaĵoj bildigo uzante WebGL kaj Canvas, manipulado kun CSS, analizo de la trajtoj de labori kun muso и klavaro.

Ankaŭ en Chrome estos aldonitaj protekto kontraŭ misuzo asociita kun malfacileco reveni al la origina paĝo post moviĝado al alia retejo. Ni parolas pri la praktiko malordigi la navigan historion per serio de aŭtomataj alidirektiloj aŭ artefarite aldoni fikciajn enskribojn al la foliumhistorio (per pushState), rezulte de kiu la uzanto ne povas uzi la butonon "Reen" por reveni al la navigado. originala paĝo post hazarda transiro aŭ devigita plusendo al la retejo de skamantoj aŭ sabotistoj. Por protekti kontraŭ tiaj manipuladoj, Chrome en la Reen butontraktilo preterlasos rekordojn asociitajn kun aŭtomata plusendado kaj manipulado de la foliumhistorio, lasante nur paĝojn kiuj estas malfermitaj pro eksplicitaj uzant-agoj.

fonto: opennet.ru