Migration From V4

Un miglioramento significativo di Google Safe Browsing v5 rispetto alla v4 (in particolare, l'API Update v4) è la freschezza e la copertura dei dati. Poiché la protezione dipende in gran parte dal database locale gestito dal client, il ritardo e le dimensioni dell'aggiornamento del database locale sono i principali fattori che contribuiscono alla mancata protezione. Nella versione 4, il client tipico impiega dai 20 ai 50 minuti per ottenere la versione più aggiornata degli elenchi di minacce. Purtroppo, gli attacchi di phishing si diffondono rapidamente: a partire dal 2021, il 60% dei siti che sferrano attacchi è attivo per meno di 10 minuti. La nostra analisi mostra che circa il 25-30% della protezione anti-phishing mancante è dovuto a questo tipo di dati obsoleti. Inoltre, alcuni dispositivi non sono attrezzati per gestire l'intera gamma di elenchi di minacce di Google Navigazione sicura, che continua a crescere nel tempo.

Se al momento utilizzi l'API Update v4, esiste un percorso di migrazione semplice dalla versione 4 alla versione 5 senza dover reimpostare o cancellare il database locale. Questa sezione descrive come farlo.

Aggiornamenti degli elenchi di conversione

A differenza di V4, in cui gli elenchi sono identificati dalla tupla di tipo di minaccia, tipo di piattaforma e tipo di voce di minaccia, in V5 gli elenchi sono identificati semplicemente per nome. Ciò offre flessibilità quando più elenchi v5 potrebbero condividere lo stesso tipo di minaccia. I tipi di piattaforma e i tipi di voci relative alle minacce vengono rimossi nella versione 5.

Nella versione 4, si utilizza il metodo threatListUpdates.fetch per scaricare gli elenchi. Nella versione 5, si passa al metodo hashLists.batchGet.

Devono essere apportate le seguenti modifiche alla richiesta:

  1. Rimuovi completamente l'oggetto ClientInfo v4. Anziché fornire l'identificazione di un client utilizzando un campo dedicato, utilizza semplicemente l'intestazione User-Agent. Sebbene non esista un formato prescritto per fornire l'identificazione del client in questa intestazione, ti suggeriamo di includere semplicemente l'ID client e la versione del client originali separati da uno spazio o da una barra.
  2. Per ogni oggetto ListUpdateRequest v4:
    • Cerca il nome dell'elenco v5 corrispondente in elenchi disponibili e forniscilo nella richiesta v5.
    • Rimuovi i campi non necessari, ad esempio threat_entry_type o platform_type.
    • Il campo state nella versione 4 è direttamente compatibile con il campo versions della versione 5. La stessa stringa di byte che verrebbe inviata al server utilizzando il campo state nella versione 4 può essere inviata semplicemente nella versione 5 utilizzando il campo versions.
    • Per i vincoli della versione 4, la versione 5 utilizza una versione semplificata chiamata SizeConstraints. I campi aggiuntivi, come region, devono essere eliminati.

Alla risposta devono essere apportate le seguenti modifiche:

  1. L'enum ResponseType della v4 viene semplicemente sostituito da un campo booleano denominato partial_update.
  2. Il campo minimum_wait_duration ora può essere zero o omesso. In caso affermativo, al client viene chiesto di effettuare immediatamente un'altra richiesta. Ciò si verifica solo quando il client specifica in SizeConstraints un vincolo più piccolo per le dimensioni massime dell'aggiornamento rispetto alle dimensioni massime del database.
  3. L'algoritmo di decodifica Rice per numeri interi a 32 bit dovrà essere modificato. La differenza è che i dati codificati sono codificati con un endianness diverso. Sia nella versione 4 che nella versione 5, i prefissi hash a 32 bit sono ordinati lessicograficamente. Tuttavia, nella versione 4, questi prefissi vengono trattati come little endian durante l'ordinamento, mentre nella versione 5 vengono trattati come big endian. Ciò significa che il client non deve eseguire alcun ordinamento, poiché l'ordinamento lessicografico è identico all'ordinamento numerico con big endian. Un esempio di questo tipo nell'implementazione di v4 di Chromium è disponibile qui. Questo tipo di ordinamento può essere rimosso.
  4. L'algoritmo di decodifica Rice dovrà essere implementato anche per altre lunghezze hash.

Ricerca di hash di conversione

Nella versione 4, si utilizzava il metodo fullHashes.find per ottenere gli hash completi. Il metodo equivalente nella versione 5 è hashes.search.

Devono essere apportate le seguenti modifiche alla richiesta:

  1. Struttura il codice in modo da inviare solo prefissi hash di esattamente 4 byte di lunghezza.
  2. Rimuovi completamente gli oggetti ClientInfo v4. Anziché fornire l'identificazione di un client utilizzando un campo dedicato, utilizza semplicemente l'intestazione User-Agent. Sebbene non esista un formato prescritto per fornire l'identificazione del client in questa intestazione, ti suggeriamo di includere semplicemente l'ID client e la versione del client originali separati da uno spazio o da una barra.
  3. Rimuovi il campo client_states. Non è più necessario.
  4. Non è più necessario includere threat_types e campi simili.

Alla risposta devono essere apportate le seguenti modifiche:

  1. Il campo minimum_wait_duration è stato rimosso. Il cliente può sempre inviare una nuova richiesta in base alle necessità.
  2. L'oggetto ThreatMatch v4 è stato semplificato nell'oggetto FullHash.
  3. La memorizzazione nella cache è stata semplificata in un'unica durata della cache. Consulta le procedure riportate sopra per interagire con la cache.