Egy HTTPS-oldal, amely HTTP-n keresztül tölt szkripteket, két kérést indít két különböző védelmi szinttel, és a lakat csak az elsőt írja le. Az alagút ezen nem változtat, mert a hordozót védi, nem az erőforrás saját sémáját. A böngésző már mondja is, melyik kérés hiúsult meg, ha a címsor helyett a konzolt olvasod. Három ellenőrzés visz el egy félig működő oldaltól egy valódi javításig.

A kérést olvasd, ne a címsort

Az HTTPS-en át letöltött dokumentum hivatkozhat szkriptre, stíluslapra, betűtípusra vagy keretre sima HTTP-n keresztül. Ez a hivatkozás külön kérés, és pont erről panaszkodik a böngésző. A fő dokumentum védelme nem terjed vissza rá, és a két folyamot szállító alagút egyik sémát sem változtatja meg. Az oldal ezért egyszerre lehet valóban biztonságos és valóban törött.

Az erőforrás puszta beágyazott fájlnak nevezése nem teszi ártalmatlanná a lecserélését.

Ha a nem biztonságos szkripttartalmat útközben módosítani, majd futtatni lehet, az megváltoztathatja az oldal viselkedését, ami nagyobb probléma egy kozmetikai hibánál. A képek kisebb, de valódi kockázatot hordoznak, ha útközben módosítják őket. A lakat semmiről nem hazudik. Szűkebb kérdésre válaszol, mint amit feltettél neki.

Tudd, mely erőforrásokat blokkolják és melyeket frissítik fel

A böngészők nem kezelnek minden erőforrástípust egyformán. a vegyes tartalomról szóló útmutató elválasztja a HTTPS-re felminősített kéréseket a teljesen blokkolt kérésektől: a szkriptek, stíluslapok és programozott kérések a blokkolt oldalon vannak, míg a képek és médiák helyette felminősülhetnek vagy megjelölhetők.

Ez a különbség magyarázza a zavaros jelentéseket. Egy blokkolt szkripttel rendelkező oldal teljesen elveszít egy funkciót, míg egy felminősített képpel rendelkező oldal jól néz ki, és csendben megváltoztatta a kérését. A dokumentált kategóriáknak is vannak kivételei, ezért ne feltételezd, hogy egy adott típusú URL mind sikeresen felminősül. Azt olvasd, amit a konzol az adott kérésről mond, ahelyett hogy a fájlkiterjesztésből következtetnél.

Egy blokkolt widget nem bizonyíték arra, hogy az alagút meghibásodott. Az a bizonyíték, hogy a böngésző elvégezte a dolgát.

Javítsd a hivatkozást a forrásánál

Egy webhely tulajdonosának a javítás ott van, ahol a nem biztonságos URL-t írták: egy sablonban, egy stíluslapban, egy URL-eket összeállító szkriptben vagy egy harmadik féltől származó komponensben. A látható oldalcím megváltoztatása mindezt érintetlenül hagyja. Keresd meg a forrásban a gazdagépet, és javíts minden hivatkozást, ne csak azt az egyet, amelyet a konzol véletlenül megnevezett.

Utána erősítsd meg, hogy az erőforrást valóban HTTPS-en, érvényes identitással szolgálják ki, mert a séma cseréje nem tud elővarázsolni egy szolgáltatást, amelyet soha nem tettek közzé ott.

grep -rn "http://assets.example" ./templates
curl -sSI https://assets.example/widget.js | head -n 1

Kövesd az átirányításokat is, mert egy HTTPS-sel kezdődő hivatkozás mégis landolhat sima szöveges kézbesítési útvonalon. Ha egy függőségnek egyszerűen nincs biztonságos kézbesítése, távolítsd el vagy cseréld le a szokásos változási folyamaton keresztül, ahelyett hogy megkerülő megoldást szállítanál. A felhasználó számára hagyd bekapcsolva a böngésző védelmeit, és jelentsd a webhely tulajdonosának az erőforrás URL-jét, típusát és a konzol üzenetét. Soha ne terjessz olyan utasításokat, amelyek arra kérik a személyzetet, hogy engedélyezzenek nem biztonságos tartalmat egy oldalhoz, mert az a kivétel túléli az őt kiváltó incidenst.

Teszteld újra az oldalt úgy, ahogy a felhasználók hozzáérnek

Gyakorold azokat a műveleteket, amelyek igény szerint töltenek erőforrásokat, ne csak az első dokumentumot. Az oldalak gombnyomás után további kódot, adatokat és letöltéseket hoznak, és ezek a kérések gyakran a nem biztonságosak. Erősítsd meg a konkrét kéréseket és a látható viselkedést, miközben a védelem még be van kapcsolva. Egy lazított böngészőprofillal induló teszt nem mutathatja meg, mit lát egy hétköznapi felhasználó.

Az alagútnak továbbra is megvan a maga dolga, és az a dolga a hálózati hozzáférés, nem az oldal integritása.

Amint a forgalom elhagyja az alagút végpontját, minden fennmaradó HTTP-lekérés semmit sem nyert a hordozótól. Javítsd az erőforrás útvonalát, és tartsd meg a böngészőn belüli kikényszerítést. Egy újabb szállítási réteg javításként való kezelése egy nem biztonságos függőségre az, ahogy egy csapat végül egy ügyfélszolgálati szkriptnél köt ki, amely kikapcsolja a helyesen működő vezérlést.

Kapcsolódó cikkek