Migration From V4

Un miglioramento significativo di Google Safe Browsing v5 rispetto alla v4 (in particolare, dell'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 della versione 4, in cui gli elenchi vengono identificati dalla tupla di tipo di minaccia, tipo di piattaforma e tipo di voce di minaccia, nella versione 5 gli elenchi vengono 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 v4 ClientInfo. 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 negli elenchi disponibili e fornisci questo nome 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. La logica per la decodifica degli hash codificati con Rice-Golomb richiede due aggiustamenti principali:
    • Endianness e ordinamento:nella versione 4, gli hash restituiti sono stati ordinati come valori little-endian. Nella versione 5, vengono trattati come valori big-endian. Poiché l'ordinamento lessicografico delle stringhe di byte equivale all'ordinamento numerico dei valori big-endian, i client non devono più eseguire un passaggio di ordinamento speciale. L'ordinamento little-endian personalizzato, come quello nell'implementazione di Chromium v4, può essere rimosso se implementato in precedenza.
    • Lunghezze hash variabili:l'algoritmo di decodifica deve essere aggiornato per supportare varie lunghezze hash che potrebbero essere restituite nel campo HashList.compressed_additions, non solo la lunghezza hash di quattro byte utilizzata nella versione 4. La lunghezza degli hash restituiti nella risposta può essere determinata in base a HashList.metadata.hash_length restituito da hashLists.list. In alternativa, la denominazione dell'elenco di hash richiesto indica anche le dimensioni degli hash previste restituite dall'elenco. Per ulteriori dettagli sugli elenchi di hash, consulta la pagina Database locale.

Ricerche 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.