Migration From V4

L'une des améliorations majeures de Google Safe Browsing v5 par rapport à la version v4 (plus précisément, l'API Update v4) concerne 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 retard 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, le client type met entre 20 et 50 minutes pour obtenir 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 lancent des attaques sont actifs pendant moins de 10 minutes. Notre analyse montre qu'environ 25 à 30 % de la protection manquante contre l'hameçonnage est due à la vétusté de ces 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 vers la version 5 sans avoir à réinitialiser ni effacer la base de données locale. Cette section explique comment procéder.

Conversion des mises à jour de listes

Contrairement à la version 4, où les listes sont identifiées par le tuple de type de menace, type de plate-forme et type d'entrée de menace, les listes de la version 5 sont simplement identifiées par leur nom. Cela offre de la flexibilité lorsque plusieurs listes v5 peuvent partager le même type de menace. Les types de plates-formes 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 des listes. Dans la version 5, vous devez passer à la méthode hashLists.batchGet.

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

  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'aucun format spécifique ne soit requis pour fournir l'identification du client dans cet en-tête, nous vous suggérons d'inclure simplement l'ID client et la version du client d'origine, séparés par un espace ou une barre oblique.
  2. Pour chaque objet ListUpdateRequest de la version 4 :
    • Recherchez le nom de la liste v5 correspondante dans les listes disponibles 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 v4, v5 utilise une version simplifiée appelée SizeConstraints. Les champs supplémentaires tels que region doivent être supprimés.

Les modifications suivantes doivent être apportées à 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 une endianness différente. 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 comme little-endian lors du tri, tandis que dans la version 5, ils sont traités comme big-endian. Cela signifie que le client n'a pas besoin de trier les données, 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 ici. Ce tri peut être supprimé.
  4. L'algorithme de décodage Rice devra également être implémenté pour les autres longueurs de hachage.

Convertir les recherches de hachages

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 hashes.search.

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

  1. Structurez le code pour n'envoyer que les préfixes de hachage qui comportent exactement 4 octets.
  2. Supprimez complètement les objets ClientInfo de la version 4. 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'aucun format spécifique ne soit requis pour fournir l'identification du client dans cet en-tête, nous vous suggérons d'inclure simplement l'ID client et la version du client d'origine, 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 ni les champs similaires.

Les modifications suivantes doivent être apportées à la réponse :

  1. Le champ minimum_wait_duration a été supprimé. Le client peut toujours émettre une nouvelle demande en cas de besoin.
  2. L'objet ThreatMatch de la version 4 a été simplifié pour devenir l'objet FullHash.
  3. La mise en cache a été simplifiée en une seule durée de cache. Consultez les procédures ci-dessus pour interagir avec le cache.