Böngésző időzóna kontra IP-hely: egy kockázati jelzés összehasonlítása

Egy böngésző Europe/London értéket jelent, miközben egy IP-adatbázis a kérést America/New_York területére helyezi. Ez két megfigyelés közötti eltérés, és érdemes rögzíteni. Nem bizonyítja, hogy a látogató VPN-t használ, és éppen a bizonyítékként kezelése az a pont, ahol a legtöbb megvalósítás hibázik. Az alábbi összehasonlítás külön tartja a két értéket és azok hibaformáit.

Két megfigyelés különböző tulajdonossal

A böngésző értéke beállítás: az a zóna, amelyet az operációs rendszer vagy a felhasználó a dátumok formázásához választott. Az adatbázisérték egy IP-hálózathoz kötött becslés, amelyet olyan szolgáltató állít elő, aki címtartományokat rendel helyekhez. Egyik sem hitelesített állítás arról, hol áll a látogató, és egyik sem tudja, melyik hálózati útvonalat járta be a kérés.

Mivel a tulajdonosok különböznek, a két érték olyan okokból is eltérhet, amelyeknek semmi közük az adatvédelmi eszközökhöz. Az otthoni zónát megtartó utazó, a központ idejéhez rögzített céges laptop, regionális kimenettel rendelkező műholdas kapcsolat vagy egy elavult adatbázissor mind eltérést eredményez.

Hogyan keletkezik valójában az egyes értékek

A böngésző a feloldott zónáját ezzel olvashatja ki: new Intl.DateTimeFormat().resolvedOptions().timeZone, amely a formázó beállításaiból származtatott IANA-azonosítót ad vissza. Nem kér helyengedélyt és nem kérdez GPS-t. A kiszolgálón a megbízható proxykonfigurációból állapítsa meg az ügyfél címét, majd keresse meg egy jóváhagyott szolgáltatónál. A látogató által biztosított továbbítási fejléc nem automatikusan ez a cím.

Tárolja a két megfigyelést külön mezőkben a megfigyelés idejével és a keresés eredményével együtt. A származtatott mező vpnDetected elnevezése, amikor a számítás csak zóna-összehasonlítás, következtetést süt bele egy mérésbe, és megnehezíti a későbbi felülvizsgálatot.

Mit bizonyít az egyezés és az eltérés

Az aszimmetria fontosabb, mint a táblázat sejteti. Az eltérésnek sok ártatlan magyarázata van, míg az egyezésnek legalább egy bűnös, ezért egyik irány sem támaszt kategorikus szabályt. A szolgáltató saját pontossági megjegyzései korlátozott pontosságot és hiányzó adatokat írnak le, és rámutatnak, hogy egy anonimizáló szolgáltatás a felhasználó helyett a saját kiszolgálója helyét fedheti fel.

Ezért a jelzés a rögzített indokkal és kifejezett ismeretlen állapottal rendelkező kockázati pontszámba tartozik, nem egy hozzáférést szabályozó logikai értékbe.

Az UTC-eltolások nem jelentenek rövidebb utat

Az eltolások összehasonlítása a zónaazonosítók helyett nem javítja a következtetést. Két különböző zóna osztozhat egy eltoláson az év egy részében, és ugyanaz a zóna megváltoztathatja az eltolást a nyári időszámítás határán. Ha egy funkciónak valóban eltolásra van szüksége az ütemezéshez, számítsa ki az adott pillanatra, ahelyett hogy egy számot tárolna, és újra felhasználná személyazonossági bizonyítékként.

A karakterlánc-összehasonlításnak megvan a maga csapdája: ugyanazon zóna két írásmódja vagy egy régi álnév szövegként eltér, miközben ugyanazt a beállítást írja le. Ellenőrizze az azonosítókat, és a platform időzóna-kezelésén keresztül hasonlítson össze, ne nyers karakterláncokat egyeztessen.

Blokkolás vagy pontozás: válassza meg tudatosan a választ

Idő megjelenítéséhez kérdezze meg a látogatót, melyik zónát részesíti előnyben, és álljon meg ott. Egy alkalmazás kockázati rendszerében kezelje az eltérést egyetlen gyenge kontextuális jelzésként a valós fenyegetésmodellhez illő bizonyítékok mellett, és hagyja, hogy egy sikertelen keresés ismeretlent adjon néma észlelés helyett. A pusztán az összehasonlításra alapozott blokkolás mérési rést változtat a felhasználó elleni váddá.

Ha egy következményekkel járó döntés erősebb biztosítékot igényel, használjon erre tervezett ellenőrzési vagy hitelesítési lépést. Egy időzóna-heurisztika nem tudja megadni ezt a biztosítékot, és az a detektor, amely hiányzó bizonyítékot számol sikernek, hatékonynak tűnhet, miközben más kérdésre válaszol, mint amelyet feltett.