Google a HTTPS-en keresztül megnyitott oldalak vegyes tartalom feldolgozásának megközelítésének megváltoztatásáról. Korábban, ha a HTTPS-en keresztül megnyitott oldalakon voltak olyan összetevők, amelyekről titkosítás nélkül (http:// protokollon keresztül) lettek betöltve, akkor egy speciális jelzés jelent meg. A jövőben úgy döntöttek, hogy alapértelmezés szerint blokkolják az ilyen erőforrások betöltését. Így a „https://” használatával megnyitott oldalak garantáltan csak biztonságos kommunikációs csatornán keresztül letöltött forrásokat tartalmaznak.
Megjegyzendő, hogy jelenleg a webhelyek több mint 90%-át a Chrome-felhasználók nyitják meg HTTPS használatával. A titkosítás nélkül betöltött betétek jelenléte biztonsági fenyegetést jelent a nem védett tartalom módosítása révén, ha a kommunikációs csatorna ellenőrzése alatt áll (például nyitott Wi-Fi-n keresztüli csatlakozáskor). A vegyes tartalom jelző hatástalannak és a felhasználó számára félrevezetőnek bizonyult, mivel nem ad egyértelmű értékelést az oldal biztonságáról.
Jelenleg a legveszélyesebb kevert tartalomtípusok, például a szkriptek és az iframe-ek már alapértelmezés szerint le vannak tiltva, de a képek, hangfájlok és videók továbbra is letölthetők a http:// oldalról. A képhamisítás révén a támadó helyettesítheti a felhasználókövető cookie-kat, megpróbálhatja kihasználni a képfeldolgozók sebezhetőségeit, vagy hamisítást követhet el a képen található információk cseréjével.
A blokkolás bevezetése több szakaszra oszlik. A december 79-re tervezett Chrome 10 új beállítást tartalmaz, amely lehetővé teszi bizonyos webhelyek blokkolásának letiltását. Ez a beállítás a már blokkolt vegyes tartalomra, például szkriptekre és iframe-ekre vonatkozik, és a menüből jelenik meg, amely a lakat szimbólumra kattintáskor legördülő menüben jelenik meg, helyettesítve a korábban javasolt blokkolási jelzőt.
A február 80-én várható Chrome 4 lágy blokkolási sémát fog használni az audio- és videofájlokhoz, ami azt jelenti, hogy a http:// hivatkozások automatikusan https://-re cserélődnek, ami megőrzi a funkcionalitást, ha a problémás erőforrás HTTPS-en keresztül is elérhető. . A képek továbbra is változtatás nélkül töltődnek be, de ha http:// keresztül töltik le, a https:// oldalak a nem biztonságos kapcsolat jelzését jelzik az egész oldalon. Az automatikus https-re váltáshoz vagy a képek blokkolásához a webhelyfejlesztők használhatják a CSP-tulajdonságok frissítése-insecure-requests és block-all-mixed-content. A március 81-re tervezett Chrome 17 automatikusan javítja a http://-t https://-re vegyes képfeltöltés esetén.
Ezen kívül a Google az új Jelszóellenőrzés komponens korábban a Chome böngésző egyik következő kiadásába történő integrációjáról a formában . Az integráció eredményeként a szokásos Chrome jelszókezelőben megjelennek a felhasználó által használt jelszavak megbízhatóságát elemző eszközök. Amikor megpróbál bejelentkezni bármely webhelyre, bejelentkezési nevét és jelszavát a rendszer ellenőrzi a feltört fiókok adatbázisában, és figyelmeztetést jelenít meg, ha problémákat észlel. Az ellenőrzést egy több mint 4 milliárd feltört fiókot lefedő adatbázison hajtják végre, amelyek kiszivárgott felhasználói adatbázisokban jelentek meg. Figyelmeztetés akkor is megjelenik, ha triviális jelszavakat próbál használni, például "abc123" (by A Google az amerikaiak 23%-a használ hasonló jelszavakat), vagy amikor ugyanazt a jelszót használja több webhelyen.
A titkosság megőrzése érdekében külső API-hoz való hozzáféréskor csak a bejelentkezési név és a jelszó kivonatának első két bájtja kerül továbbításra (a hash algoritmust használjuk ). A teljes hash-t a felhasználó oldalán generált kulccsal titkosítják. A Google adatbázisban lévő eredeti hash-ek szintén titkosítva vannak, és a hash-ből csak az első két bájt marad az indexeléshez. A továbbított kétbájtos előtag alá eső hash-ek végső ellenőrzése a felhasználó oldalán kriptográfiai technológia segítségével történik.“, amelyben egyik fél sem ismeri az ellenőrzött adatok tartalmát. A feltört fiókokat tartalmazó adatbázis tartalmának brutális erőszakkal történő, tetszőleges előtagok kérésével történő meghatározása elleni védelem érdekében a továbbított adatokat a bejelentkezés és a jelszó ellenőrzött kombinációja alapján generált kulccsal titkosítják.
Forrás: opennet.ru