Browserens tidszone kontra IP-placering: sammenligning af et risksignal
Browserens zone og en zone udledt af IP måler forskellige ting. Sammenlign, hvad hver af dem kan bevise, før en uoverensstemmelse bliver en VPN-dom i din risikomodel.
En browser rapporterer Europe/London, mens en IP-database placerer anmodningen i America/New_York. Det er en uoverensstemmelse mellem to observationer, og den er værd at registrere. Det er ikke bevis for, at den besøgende bruger VPN, og netop det at behandle det som bevis er, hvor de fleste implementeringer fejler. Sammenligningen nedenfor holder de to værdier og deres fejlmåder adskilt.
To observationer med forskellige ejere
Browserværdien er en indstilling: den zone, som styresystemet eller brugeren valgte til datoformatering. Databaseværdien er et skøn knyttet til et IP-netværk, produceret af en udbyder, der kortlægger adresseblokke til steder. Ingen af dem er en bekræftet erklæring om, hvor den besøgende står, og ingen af dem ved, hvilken netværksvej anmodningen tog.
Fordi ejerne er forskellige, kan de to værdier afvige af grunde, der intet har med privatlivsværktøjer at gøre. En rejsende, der beholder hjemmezonen, en firmabærbare låst til hovedkontorets tid, en satellitforbindelse med regional udgang eller en forældet række i databasen giver alle en uoverensstemmelse.
Hvordan hver værdi faktisk produceres
En browser kan læse sin udledte zone med new Intl.DateTimeFormat().resolvedOptions().timeZone, som returnerer en IANA-identifikator udledt af formateringsindstillingerne. Den anmoder ikke om tilladelse til placering og konsulterer ikke GPS. På serveren skal du fastslå klientadressen ud fra din betroede proxy-konfiguration og derefter slå den op hos en godkendt udbyder. En videresendelsesheader, som den besøgende leverer, er ikke automatisk den adresse.
Gem de to observationer i separate felter sammen med observationstiden og opslagsresultatet. At navngive det udledte felt vpnDetected, når beregningen kun er en zonesammenligning, bager en konklusion ind i en måling og gør senere gennemgang sværere.
Hvad overensstemmelse og uoverensstemmelse hver især beviser
| Observation | Hvad det efterlader uafklaret |
|---|---|
| Forskellige rapporterede zoner | Rejser, en bevaret indstilling, en virksomhedsgateway, en proxy eller en databasefejl kan alle frembringe det. |
| Den samme rapporterede zone | En VPN-udgang kan ligge i brugerens zone, så overensstemmelse fastslår ikke en direkte forbindelse. |
| En værdi mangler eller er ugyldig | Sammenligningen er utilgængelig, hvilket hverken er overensstemmelse eller uoverensstemmelse. |
Asymmetrien betyder mere, end tabellen antyder. En uoverensstemmelse har mange uskyldige forklaringer, mens en overensstemmelse har mindst én skyldig, så ingen af retningerne understøtter en kategorisk regel. Udbyderens egne nøjagtighedsnoter beskriver begrænset præcision og manglende data og påpeger, at en anonymiseringstjeneste kan afsløre sin servers placering i stedet for brugerens.
Derfor hører signalet hjemme i en risikoscore med en registreret årsag og en udtrykkelig ukendt tilstand, ikke i en boolesk værdi, der styrer adgang.
UTC-forskydninger er ikke en genvej
At sammenligne forskydninger i stedet for zoneidentifikatorer reparerer ikke slutningen. To forskellige zoner kan dele en forskydning i en del af året, og den samme zone kan skifte forskydning ved en sommertidsgrænse. Hvis en funktion virkelig har brug for en forskydning til planlægning, skal du beregne den for det konkrete øjeblik i stedet for at gemme ét tal og genbruge det som identitetsbevis.
Strengsammenligning har sin egen fælde: to stavemåder af samme zone eller et gammelt alias vil afvige som tekst, mens de beskriver den samme indstilling. Validér identifikatorerne, og sammenlign via platformens håndtering af tidszoner i stedet for at matche rå strenge.
Bloker eller scor: vælg reaktionen bevidst
Til visning af tid skal du spørge den besøgende, hvilken zone de foretrækker, og stoppe der. Til et applikationsrisikosystem skal du behandle en uoverensstemmelse som ét svagt kontekstuelt signal sammen med beviser, der passer til den faktiske trusselsmodel, og lade et mislykket opslag give en ukendt værdi i stedet for en tavs registrering. Blokering alene på sammenligningen gør et målehul til en anklage mod brugeren.
Hvis en afgørelse med konsekvenser kræver stærkere sikkerhed, skal du bruge et verifikations- eller godkendelsestrin, der er designet til det. En tidszoneheuristik kan ikke levere den sikkerhed, og en detektor, der tæller manglende beviser som succes, kan se effektiv ud, mens den besvarer et andet spørgsmål end det, du stillede.