Migration From V4

L'une des améliorations significatives de la version 5 de Google Safe Browsing par rapport à la version 4 (et plus particulièrement de l'API Update v4) est la fraîcheur et la couverture des données. Étant donné que la protection dépend fortement de la base de données locale gérée par le client, le délai et la taille de la mise à jour de la base de données locale sont les principaux facteurs de la protection manquée. Dans la version 4, il faut généralement entre 20 et 50 minutes pour qu'un client obtienne la version la plus récente des listes de menaces. Malheureusement, les attaques par hameçonnage se propagent rapidement: en 2021, 60% des sites qui diffusent des attaques ne sont en ligne que moins de 10 minutes. Notre analyse montre que 25 à 30% des cas de protection contre l'hameçonnage manquantes sont dus à cette obsolescence des données. De plus, certains appareils ne sont pas équipés pour gérer l'intégralité des listes de menaces de la navigation sécurisée Google, qui ne cessent de s'allonger au fil du temps.

Si vous utilisez actuellement l'API Update v4, vous pouvez migrer facilement de la version 4 vers la version 5 sans avoir à réinitialiser ni effacer la base de données locale. Cette section explique comment procéder.

Convertir les mises à jour de la liste

Contrairement à la version 4, où les listes sont identifiées par le tuple de type de menace, de type de plate-forme et de type d'entrée de menace, dans la version 5, les listes sont simplement identifiées par nom. Cela offre une flexibilité lorsque plusieurs listes v5 peuvent partager le même type de menace. Les types de plate-forme et les types d'entrées de menaces sont supprimés dans la version 5.

Dans la version 4, la méthode threatListUpdates.fetch permet de télécharger les listes. Dans la version 5, vous devez passer à la méthode hashLists.batchGet.

Les modifications suivantes doivent être apportées à la requête:

  1. Supprimez complètement l'objet ClientInfo v4. Au lieu de fournir l'identification d'un client à l'aide d'un champ dédié, utilisez simplement l'en-tête User-Agent bien connu. Bien qu'il n'existe pas de format prescrit pour fournir l'identification du client dans cet en-tête, nous vous suggérons simplement d'inclure l'ID client d'origine et la version du client séparés par un espace ou une barre oblique.
  2. Pour chaque objet ListUpdateRequest v4: * Recherchez le nom de la liste v5 correspondant dans le tableau ci-dessus et indiquez-le dans la requête v5.
    • Supprimez les champs inutiles, tels que threat_entry_type ou platform_type.
    • Le champ state de la version 4 est directement compatible avec le champ versions de la version 5. La même chaîne d'octets qui serait envoyée au serveur à l'aide du champ state dans la version 4 peut simplement être envoyée dans la version 5 à l'aide du champ versions.
    • Pour les contraintes de la version 4, la version 5 utilise une version simplifiée appelée SizeConstraints. Les champs supplémentaires tels que region doivent être supprimés.

Vous devez apporter les modifications suivantes à la réponse:

  1. L'énumération ResponseType de la version 4 est simplement remplacée par un champ booléen nommé partial_update.
  2. Le champ minimum_wait_duration peut désormais être nul ou omis. Si c'est le cas, le client est invité à envoyer immédiatement une autre requête. Cela ne se produit que lorsque le client spécifie dans SizeConstraints une contrainte de taille de mise à jour maximale inférieure à la taille maximale de la base de données.
  3. L'algorithme de décodage Rice pour les entiers 32 bits devra être ajusté. La différence réside dans le fait que les données encodées sont encodées avec un ordre d'octets différent. Dans les versions 4 et 5, les préfixes de hachage 32 bits sont triés de manière lexicographique. Toutefois, dans la version 4, ces préfixes sont traités en mode little-endian lors du tri, tandis que dans la version 5, ils sont traités en mode big-endian. Cela signifie que le client n'a pas besoin de procéder à un tri, car le tri lexicographique est identique au tri numérique avec big endian. Vous trouverez un exemple de ce type dans l'implémentation Chromium de la version 4 sur cette page. Ce tri peut être supprimé.
  4. L'algorithme de décodage Rice doit également être implémenté pour d'autres longueurs de hachage.

Convertir les recherches par hachage

Dans la version 4, vous devez utiliser la méthode fullHashes.find pour obtenir les hachages complets. La méthode équivalente dans la version 5 est la méthode hashes.search.

Les modifications suivantes doivent être apportées à la requête:

  1. Structurez le code pour n'envoyer que des préfixes de hachage de 4 octets exactement.
  2. Supprimez complètement les objets ClientInfo v4. Au lieu de fournir l'identification d'un client à l'aide d'un champ dédié, utilisez simplement l'en-tête User-Agent bien connu. Bien qu'il n'existe pas de format prescrit pour fournir l'identification du client dans cet en-tête, nous vous suggérons simplement d'inclure l'ID client d'origine et la version du client séparés par un espace ou une barre oblique.
  3. Supprimez le champ client_states. qui n'était plus nécessaire.
  4. Il n'est plus nécessaire d'inclure threat_types et des champs similaires.

Vous devez apporter les modifications suivantes à la réponse:

  1. Le champ minimum_wait_duration a été supprimé. Le client peut toujours envoyer une nouvelle requête si nécessaire.
  2. L'objet ThreatMatch v4 a été simplifié en objet FullHash.
  3. La mise en cache a été simplifiée en une seule durée de cache. Pour interagir avec le cache, consultez les procédures ci-dessus.