Memorizzazione nella cache

Questo documento si applica ai seguenti metodi:

• API Lookup: uris.search
• API Update: hashes.search

Informazioni sulla memorizzazione nella cache

Per ridurre l'utilizzo della larghezza di banda dei client e proteggere Google dai picchi di traffico, i client sia dell'API Lookup che dell'API Update devono creare e gestire una cache locale dei dati sulle minacce. L'API Lookup utilizza la cache per ridurre il numero di richieste uris.search che i client inviano a Google. Per l'API Update, la cache viene utilizzata per ridurre il numero di richieste hashes.search che i client inviano a Google. Di seguito è descritto il protocollo di memorizzazione nella cache per ogni API.

API Lookup

I client dell'API Lookup devono memorizzare nella cache ogni elemento ThreatUrl restituito fino al tempo definito nel campo expireTime. I client devono quindi consultare la cache prima di inviare una successiva richiesta uris.search al server. Se la voce della cache per un elemento ThreatUrl restituito in precedenza non è ancora scaduta, il client deve presumere che l'elemento non sia ancora sicuro. La memorizzazione nella cache di ThreatUrl elementi può ridurre il numero di richieste API effettuate dal client.

API Update

Per ridurre il numero complessivo di richieste hashes.search inviate a Google utilizzando l'API Update, i client devono mantenere una cache locale. L'API stabilisce due tipi di memorizzazione nella cache, positiva e negativa.

Memorizzazione nella cache positiva

Per impedire ai client di chiedere ripetutamente informazioni sullo stato di un particolare hash completo non sicuro, ogni ThreatHash restituito contiene un tempo di cache positivo (definito dal campo expireTime). Finora, l'hash completo può essere considerato non sicuro.

Memorizzazione nella cache negativa

Per impedire ai client di chiedere ripetutamente informazioni sullo stato di un particolare hash completo sicuro, la risposta definisce una durata della cache negativa per il prefisso richiesto (definito dal campo negativeExpireTime). Fino a questa data, tutti gli hash completi con il prefisso richiesto devono essere considerati sicuri per i tipi di minaccia richiesti, ad eccezione di quelli restituiti dal server come non sicuri. Questa memorizzazione nella cache è particolarmente importante in quanto previene il sovraccarico di traffico che potrebbe essere causato da un conflitto tra prefisso hash con un URL sicuro che riceve molto traffico.

Consultazione della cache

Quando il client vuole controllare lo stato di un URL, calcola prima il suo hash completo. Se nel database locale è presente il prefisso dell'hash completo, il client deve consultare la cache prima di inviare una richiesta hashes.search al server.

Per prima cosa, i clienti dovrebbero controllare se la cache ha avuto un successo positivo. Se esiste una voce positiva della cache non scaduta per l'hash completo di interesse, questa voce dovrebbe essere considerata non sicura. Se la voce positiva della cache è scaduta, il client deve inviare una richiesta hashes.search per il prefisso locale associato. In base al protocollo, se il server restituisce l'hash completo non è sicuro, altrimenti è considerato sicuro.

Se non esistono voci positive della cache per l'hash completo, il client deve verificare se è presente un successo negativo della cache. Se esiste una voce di cache negativa non scaduta per il prefisso locale associato, l'hash completo è considerato sicuro. Se la voce negativa della cache è scaduta o non esiste, il client deve inviare una richiesta hashes.search per il prefisso locale associato e interpretare la risposta come di consueto.

Aggiornamento della cache

La cache del client deve essere aggiornata ogni volta che viene ricevuta una risposta hashes.search. È necessario creare o aggiornare una voce positiva della cache per l'hash completo in base al campo expireTime. Anche la durata negativa della cache del prefisso hash deve essere creata o aggiornata in base al campo negativeExpireTime della risposta.

Se una richiesta hashes.search successiva non restituisce un hash completo attualmente memorizzato nella cache, il client non è tenuto a rimuovere la voce positiva della cache. In pratica, questo non è un motivo di preoccupazione, poiché le durate positive della cache sono in genere brevi (alcuni minuti) per consentire una rapida correzione dei falsi positivi.

Scenario di esempio

Nell'esempio seguente, supponiamo che h(url) sia il prefisso hash dell'URL e che H(url) sia l'hash completo dell'URL. Ciò significa che h(url) = SHA256(url).substr(4), H(url) = SHA256(url).

Supponiamo che un client con una cache vuota visiti example.com/ e veda che h(example.com/) si trova nel database locale. Il client richiede gli hash completi per il prefisso hash h(example.com/) e riceve l'hash completo H(example.com/) insieme a un tempo di scadenza della cache positivo di 5 minuti a partire da ora e un tempo di scadenza della cache negativa di un'ora a partire da ora.

La durata positiva della cache di 5 minuti indica al client per quanto tempo l'hash a lunghezza completa H(example.com/) deve essere considerato non sicuro senza inviare un'altra richiesta hashes.search. Dopo 5 minuti, il client deve inviare un'altra richiesta hashes.search per quel prefisso h(example.com/) se il client visita di nuovo example.com/. Il client deve reimpostare il tempo di scadenza della cache negativa del prefisso hash in base alla nuova risposta.

La durata negativa della cache di un'ora indica al client per quanto tempo tutti gli altri hash completi oltre a H(example.com/) che condividono lo stesso prefisso di h(example.com/) devono essere considerati sicuri. Per la durata di 1 ora, ogni URL ad esempio h(URL) = h(example.com/) deve essere considerato sicuro e, pertanto, non restituisce una richiesta hashes.search (supponendo che H(URL) != H(example.com/)).

Se la risposta fullHashes contiene zero corrispondenze ed è impostata una scadenza della cache negativa, il client non deve inviare richieste hashes.search per nessuno dei prefissi richiesti per il tempo di cache negativo specificato.

Se la risposta hashes.search contiene una o più corrispondenze, viene comunque impostato un tempo di scadenza della cache negativa per l'intera risposta. In questo caso, la data di scadenza della cache di un singolo hash completo indica per quanto tempo il client deve presumere che il particolare hash completo non sia sicuro. Una volta trascorsa la durata della cache di ThreatHash, il client deve aggiornare l'hash completo inviando una richiesta hashes.search per quel prefisso hash se l'URL richiesto corrisponde all'hash completo esistente nella cache. In questo caso, la durata negativa della cache non viene applicata. La durata negativa della cache della risposta si applica solo agli hash completi che non erano presenti nella risposta hashes.search. Per gli hash completi che non sono presenti nella risposta, il client deve astenersi dall'inviare richieste hashes.search fino a quando non sarà trascorsa la durata della cache negativa.