A Google bemutatta a Chrome 102 webböngésző kiadását, ezzel egyidejűleg elérhető a Chrome alapjául szolgáló ingyenes Chromium projekt stabil kiadása is. A Chrome böngésző különbözik a Chromiumtól a Google logók használatában, az összeomlás esetén értesítést küldő rendszer meglétében, a másolásvédett videotartalom lejátszására szolgáló modulokban (DRM), a frissítések automatikus telepítésére szolgáló rendszerben, a Sandbox elkülönítés tartós engedélyezésében. , kulcsokat biztosít a Google API-hoz, és RLZ-t küld a keresés során. Azok számára, akiknek több időre van szükségük a frissítéshez, az Extended Stable ág külön támogatott, amelyet 8 hét követ. A Chrome 103 következő kiadása június 21-én jelenik meg.
Főbb változások a Chrome 102-ban:
- A már felszabadult memóriablokkokhoz való hozzáférés okozta sérülékenységek kiaknázásának megakadályozására (használat után szabadon) a szokásos mutatók helyett a MiraclePtr (raw_ptr) típust kezdték használni. A MiraclePtr egy kötést biztosít a mutatók felett, amely további ellenőrzéseket végez a felszabadult memóriaterületekhez való hozzáféréseknél, és összeomlik, ha ilyen hozzáféréseket észlel. Az új védelmi módszer teljesítményre és memóriafogyasztásra gyakorolt hatását elhanyagolhatónak értékelik. A MiraclePtr mechanizmus nem minden folyamatban alkalmazható, különösen nem a renderelési folyamatokban, de jelentősen javíthatja a biztonságot. Például a jelenlegi kiadásban a 32 javított sebezhetőség közül 12-t a használat utáni használat miatti problémák okoztak.
- A letöltésekkel kapcsolatos információkat tartalmazó felület kialakítása megváltozott. A letöltési folyamat adatait tartalmazó alsó sor helyett egy új jelző került a címsoros panelre, rákattintva megjelenik a fájlok letöltésének folyamata és a már letöltött fájlok listája. Az alsó panellel ellentétben a gomb folyamatosan látható a panelen, és lehetővé teszi a letöltési előzmények gyors elérését. Az új felületet jelenleg alapértelmezés szerint csak néhány felhasználó számára kínálják, és mindenre kiterjesztik, ha nem lesz probléma. A régi felület visszaállításához vagy egy új engedélyezéséhez a „chrome://flags#download-bubble” beállítás érhető el.
- Amikor a helyi menün keresztül keres képeket („Kép keresése a Google Lens segítségével” vagy „Keresés a Google Lens segítségével”), az eredmények most nem egy külön oldalon, hanem az eredeti oldal tartalma melletti oldalsávban jelennek meg (a egy ablakban egyszerre láthatja az oldal tartalmát és a keresőmotor elérésének eredményét).
- A beállítások „Adatvédelem és biztonság” részében bekerült az „Adatvédelmi útmutató” rész, amely általános áttekintést nyújt az adatvédelmet befolyásoló főbb beállításokról, az egyes beállítások hatásának részletes magyarázatával. Például a szakaszban meghatározhatja a Google-szolgáltatásokba való adatküldés szabályzatát, kezelheti a szinkronizálást, a cookie-feldolgozást és az előzmények mentését. A funkciót néhány felhasználó számára kínálják, aktiválásához használja a „chrome://flags#privacy-guide” beállítást.
- A keresési előzmények és a megtekintett oldalak strukturálása biztosított. Amikor újra megpróbálja keresni, a címsávban megjelenik a „Folytasd az utazást” tipp, amely lehetővé teszi a keresés folytatását onnan, ahol legutóbb megszakították.
- A Chrome Internetes áruház egy „Extensions Starter Kit” oldalt kínál az ajánlott bővítmények kezdeti választékával.
- Teszt módban engedélyezve van egy CORS (Cross-Origin Resource Sharing) engedélyezési kérés küldése a fő webhelykiszolgálónak az „Access-Control-Request-Private-Network: true” fejléccel, ha az oldal hozzáfér egy erőforráshoz a belső hálózaton ( 192.168.xx , 10.xxx, 172.16.xx) vagy a localhost (128.xxx) címre. A kérésre válaszul végrehajtott művelet megerősítésekor a szervernek vissza kell adnia az „Access-Control-Allow-Private-Network: true” fejlécet. A Chrome 102-es verziójában a megerősítés eredménye még nem befolyásolja a kérés feldolgozását - ha nincs megerősítés, figyelmeztetés jelenik meg a webkonzolon, de magát az alerőforrás-kérést nem blokkolja. A blokkolás engedélyezése a kiszolgáló megerősítésének hiányában a Chrome 105 megjelenéséig nem várható. A korábbi kiadások blokkolásának engedélyezéséhez engedélyezze a „chrome://flags/#private-network-access-respect-preflight-” beállítást. eredmények".
A kiszolgáló általi jogosultságellenőrzést azért vezették be, hogy megerősítsék a védelmet a helyi hálózaton vagy a felhasználó számítógépén (localhost) lévő erőforrásokhoz való hozzáféréssel kapcsolatos támadások ellen a webhely megnyitásakor betöltött szkriptekből. Az ilyen kéréseket a támadók arra használják, hogy CSRF-támadásokat hajtsanak végre útválasztók, hozzáférési pontok, nyomtatók, vállalati webes felületek és más eszközök és szolgáltatások ellen, amelyek csak a helyi hálózatról fogadnak kéréseket. Az ilyen támadások elleni védelem érdekében, ha a belső hálózaton al-erőforrásokhoz férnek hozzá, a böngésző kifejezett engedélykérést küld ezen al-erőforrások betöltésére.
- Amikor a hivatkozásokat inkognitó módban a helyi menün keresztül nyitja meg, bizonyos, az adatvédelmet befolyásoló paraméterek automatikusan eltávolításra kerülnek az URL-ből.
- Módosult a Windows és Android frissítések szállítási stratégiája. Az új és a régi kiadások viselkedésének teljesebb összehasonlítása érdekében az új verzió több buildje is létrejön letöltés céljából.
- A hálózati szegmentációs technológiát stabilizálták, hogy megvédje a felhasználók webhelyek közötti mozgásának nyomon követését az azonosítók tárolásán alapuló olyan területeken, amelyek nem az állandó információ tárolására szolgálnak („szupercookie-k”). Mivel a gyorsítótárazott erőforrások egy közös névtérben vannak tárolva, függetlenül a származási tartománytól, az egyik webhely megállapíthatja, hogy egy másik webhely erőforrásokat tölt-e be, ha ellenőrzi, hogy az erőforrás a gyorsítótárban van-e. A védelem a hálózati szegmentálás (Network Partitioning) használatán alapul, melynek lényege, hogy a megosztott gyorsítótárakba további rekordokat kötnek ahhoz a tartományhoz, ahonnan a főoldal megnyílik, ami korlátozza a gyorsítótár lefedettségét csak a mozgáskövető szkriptek számára. az aktuális webhelyre (az iframe-ből származó szkript nem tudja ellenőrizni, hogy az erőforrást egy másik webhelyről töltötték-e le). Az állapotmegosztás kiterjed a hálózati kapcsolatokra (HTTP/1, HTTP/2, HTTP/3, websocket), a DNS-gyorsítótárra, az ALPN/HTTP2-re, a TLS/HTTP3-adatokra, a konfigurációra, a letöltésekre és az Expect-CT fejlécadatokra.
- Telepített önálló webalkalmazások (PWA, Progressive Web App) esetén az ablak címterületének kialakítása módosítható a Window Controls Overlay komponensekkel, amelyek kiterjesztik a webalkalmazás képernyőterületét a teljes ablakra. A webalkalmazások a teljes ablak megjelenítését és beviteli feldolgozását vezérelhetik, kivéve a szabványos ablakvezérlő gombokkal (bezárás, kicsinyítés, maximalizálás) ellátott overlay blokkot, hogy a webalkalmazásnak a szokásos asztali alkalmazás megjelenését kölcsönözze.
- Az űrlap automatikus kitöltési rendszerében támogatást adtunk a virtuális hitelkártyaszámok generálásához az online áruházak fizetési adatait tartalmazó mezőkben. A virtuális kártya használatával, amelynek száma minden fizetéshez generálódik, lehetővé teszi, hogy ne valós hitelkártyáról adatokat vigyen át, hanem szükséges a szükséges szolgáltatás banki biztosítása. A funkció jelenleg csak az egyesült államokbeli bankok ügyfelei számára érhető el. A funkció beépítésének szabályozásához a „chrome://flags/#autofill-enable-virtual-card” beállítás javasolt.
- A „Capture Handle” mechanizmus alapértelmezés szerint be van kapcsolva, lehetővé téve az információk átvitelét a videót rögzítő alkalmazásokhoz. Az API lehetővé teszi a rögzítésre kerülő alkalmazások és a rögzítést végző alkalmazások közötti interakció megszervezését. Például egy videokonferencia-alkalmazás, amely egy prezentáció közvetítéséhez videót rögzít, lekérheti a prezentáció vezérlőivel kapcsolatos információkat, és megjelenítheti azokat a videoablakban.
- A spekulatív szabályok támogatása alapértelmezés szerint engedélyezve van, rugalmas szintaxist biztosítva annak meghatározásához, hogy a hivatkozással kapcsolatos adatok proaktívan betölthetők-e, mielőtt a felhasználó a hivatkozásra kattintana.
- Stabilizálták az erőforrások Web Bundle formátumú csomagokba való csomagolásának mechanizmusát, ami lehetővé teszi nagyszámú kísérőfájl (CSS-stílusok, JavaScript, képek, iframe-ek) betöltésének hatékonyságának növelését. A Webpack formátumú csomagokkal ellentétben a Web Bundle formátumnak a következő előnyei vannak: nem maga a csomag tárolódik a HTTP-gyorsítótárban, hanem annak összetevői; a JavaScript összeállítása és végrehajtása megkezdődik anélkül, hogy megvárná a csomag teljes letöltését; Lehetőség van további források, például CSS- és képek felvételére, amelyeket a webpackben JavaScript-karakterláncok formájában kell kódolni.
- Lehetőség van PWA-alkalmazások megadására bizonyos MIME-típusok és fájlkiterjesztések kezelőjeként. Miután a jegyzék file_handlers mezőjében megadta az összerendelést, az alkalmazás különleges eseményt kap, amikor a felhasználó megpróbál megnyitni egy, az alkalmazáshoz társított fájlt.
- Új inert attribútum hozzáadva, amely lehetővé teszi a DOM-fa egy részének "inaktívként" való megjelölését. Az ebben az állapotban lévő DOM-csomópontoknál a szövegkijelölés és a mutató lebegtetése kezelők le vannak tiltva, azaz. A mutatóesemények és a felhasználó által kiválasztott CSS-tulajdonságok mindig „nincs” értékre vannak állítva. Ha egy csomópont szerkeszthető, akkor inert módban szerkeszthetetlenné válik.
- Hozzáadtuk a Navigációs API-t, amely lehetővé teszi a webalkalmazások számára, hogy elfogják az ablaknavigációs műveleteket, kezdeményezzenek navigációt és elemezzék az alkalmazással végzett műveletek előzményeit. Az API alternatívát kínál a window.history és window.location tulajdonságokkal szemben, egyoldalas webalkalmazásokhoz optimalizálva.
- A "rejtett" attribútumhoz egy új, "találásig" jelzőt javasoltak, amely az elemet kereshetővé teszi az oldalon, és szövegmaszkkal görgethetővé teszi. Például rejtett szöveget adhat hozzá egy oldalhoz, amelynek tartalma megtalálható a helyi keresésekben.
- A WebHID API-ban, amelyet a HID eszközök (emberi interfész eszközök, billentyűzetek, egerek, gamepadok, érintőpadok) alacsony szintű elérésére terveztek, és a munka megszervezésére anélkül, hogy a rendszerben konkrét illesztőprogramok jelennének meg, az exclusionFilters tulajdonság hozzáadásra került a requestDevice( ) objektum, amely lehetővé teszi bizonyos eszközök kizárását, amikor a böngésző megjeleníti az elérhető eszközök listáját. Például kizárhatja az ismert problémákkal rendelkező eszközazonosítókat.
- Tilos a fizetési űrlap megjelenítése a PaymentRequest.show() meghívásával kifejezett felhasználói művelet nélkül, például a kezelőhöz társított elemre való kattintás nélkül.
- A WebRTC-ben munkamenet létrehozásához használt SDP (Session Description Protocol) protokoll alternatív megvalósításának támogatása megszűnt. A Chrome két SDP-lehetőséget kínált – más böngészőkkel egyesített és Chrome-specifikus. Mostantól már csak a hordozható lehetőség maradt.
- Továbbfejlesztették a webfejlesztők eszközeit. Gombok hozzáadva a Stílusok panelhez a sötét és világos téma használatának szimulálására. Megerősítettük az Előnézet fül védelmét hálózati ellenőrzési módban (a Tartalombiztonsági szabályzat alkalmazása engedélyezve van). A hibakereső végrehajtja a parancsfájl leállítását a töréspontok újratöltéséhez. Javasolták az új „Teljesítménybetekintések” panel előzetes megvalósítását, amely lehetővé teszi az oldalon bizonyos műveletek teljesítményének elemzését.
Az új verzió az újítások és hibajavítások mellett 32 sebezhetőséget szünteti meg. A sebezhetőségek nagy részét az AddressSanitizer, MemorySanitizer, Control Flow Integrity, LibFuzzer és AFL eszközökkel végzett automatizált tesztelés eredményeként azonosították. Az egyik probléma (CVE-2022-1853) egy kritikus veszélyszintet jelent, ami magában foglalja a böngészővédelem minden szintjének megkerülését, és kód futtatását a rendszeren a sandbox környezeten kívül. A sérülékenység részleteit még nem hozták nyilvánosságra, csak annyit tudni, hogy az Indexed DB API implementációjában felszabaduló memóriablokkhoz való hozzáférés (használat utáni szabad használat) okozza.
A jelenlegi kiadás sebezhetőségeinek feltárásáért folyó pénzjutalom program részeként a Google 24 díjat fizetett ki 65600 10000 dollár értékben (egy 7500 7000 dolláros, egy 5000 dolláros, két 3000 dolláros, három 2000 dolláros, négy 1000 dolláros és kettő 500 dolláros, 7 dolláros díjat XNUMX dolláros bónuszok). A XNUMX jutalom nagysága még nincs meghatározva.
Forrás: opennet.ru