Migration From V4

Eine wichtige Verbesserung von Google Safe Browsing v5 gegenüber v4 (insbesondere der v4 Update API) ist die Aktualität und Abdeckung der Daten. Da der Schutz stark von der vom Client verwalteten lokalen Datenbank abhängt, sind die Verzögerung und die Größe der Aktualisierung der lokalen Datenbank die Hauptursache für den fehlenden Schutz. In Version 4 dauert es in der Regel 20 bis 50 Minuten, bis der Client die aktuelle Version der Bedrohungslisten abruft. Leider breiten sich Phishing-Angriffe schnell aus: 2021 waren 60% der Websites, die Angriffe ausführen, weniger als 10 Minuten lang aktiv. Unsere Analyse zeigt, dass etwa 25–30% des fehlenden Phishingschutzes auf solche veralteten Daten zurückzuführen sind. Außerdem sind einige Geräte nicht in der Lage, die gesamten Google Safe Browsing-Bedrohungslisten zu verwalten, die im Laufe der Zeit immer größer werden.

Wenn Sie derzeit die v4 Update API verwenden, gibt es einen nahtlosen Migrationspfad von v4 zu v5, ohne dass die lokale Datenbank zurückgesetzt oder gelöscht werden muss. In diesem Abschnitt wird beschrieben, wie Sie das tun.

Aktualisierungen bei der Umstellung von Listen

Im Gegensatz zu V4, wo Listen durch das Tupel aus Bedrohungstyp, Plattformtyp und Bedrohungseintragstyp identifiziert werden, werden Listen in V5 einfach durch den Namen identifiziert. Das bietet Flexibilität, wenn mehrere v5-Listen denselben Bedrohungstyp verwenden. Plattformtypen und Typen von Bedrohungseinträgen werden in Version 5 entfernt.

In Version 4 wurde die Methode threatListUpdates.fetch zum Herunterladen von Listen verwendet. In Version 5 würde man zur hashLists.batchGet-Methode wechseln.

Die folgenden Änderungen sollten an der Anfrage vorgenommen werden:

  1. Entfernen Sie das v4 ClientInfo-Objekt vollständig. Anstatt die Identifizierung eines Clients über ein separates Feld anzugeben, verwenden Sie einfach den bekannten User-Agent-Header. Es gibt kein vorgeschriebenes Format für die Angabe der Client-ID in diesem Header. Wir empfehlen, einfach die ursprüngliche Client-ID und Client-Version durch ein Leerzeichen oder einen Schrägstrich getrennt anzugeben.
  2. Für jedes v4-ListUpdateRequest-Objekt:
    • Suchen Sie in den verfügbaren Listen nach dem entsprechenden v5-Listennamen und geben Sie diesen Namen in der v5-Anfrage an.
    • Entfernen Sie nicht benötigte Felder wie threat_entry_type oder platform_type.
    • Das Feld state in Version 4 ist direkt mit dem Feld versions in Version 5 kompatibel. Derselbe Byte-String, der in Version 4 über das Feld state an den Server gesendet wurde, kann in Version 5 einfach über das Feld versions gesendet werden.
    • Für die v4-Einschränkungen wird in v5 eine vereinfachte Version namens SizeConstraints verwendet. Zusätzliche Felder wie region sollten entfernt werden.

Die folgenden Änderungen sollten an der Antwort vorgenommen werden:

  1. Das v4-Enum ResponseType wird einfach durch ein boolesches Feld mit dem Namen partial_update ersetzt.
  2. Das Feld minimum_wait_duration kann jetzt null sein oder weggelassen werden. Ist dies der Fall, wird der Client aufgefordert, sofort eine weitere Anfrage zu stellen. Dies geschieht nur, wenn der Client in SizeConstraints eine kleinere Einschränkung für die maximale Aktualisierungsgröße als für die maximale Datenbankgröße angibt.
  3. Der Rice-Decodierungsalgorithmus für 32‑Bit-Ganzzahlen muss angepasst werden. Der Unterschied besteht darin, dass die codierten Daten mit einer anderen Endianness codiert werden. Sowohl in Version 4 als auch in Version 5 werden 32-Bit-Hash-Präfixe lexikografisch sortiert. In Version 4 werden diese Präfixe beim Sortieren als Little-Endian behandelt, in Version 5 als Big-Endian. Das bedeutet, dass der Client keine Sortierung vornehmen muss, da die lexikografische Sortierung mit Big-Endian-Sortierung identisch ist. Ein Beispiel für diese Art von Sortierung in der Chromium-Implementierung von Version 4 finden Sie hier. Diese Sortierung kann entfernt werden.
  4. Der Rice-Decodierungsalgorithmus muss auch für andere Hash-Längen implementiert werden.

Hash-Suchanfragen mit Conversion

In Version 4 würde man die fullHashes.find-Methode verwenden, um vollständige Hashes abzurufen. Die entsprechende Methode in Version 5 ist hashes.search.

Die folgenden Änderungen sollten an der Anfrage vorgenommen werden:

  1. Strukturieren Sie den Code so, dass nur Hash-Präfixe mit einer Länge von genau 4 Byte gesendet werden.
  2. Entfernen Sie die v4-ClientInfo-Objekte vollständig. Anstatt die Identifizierung eines Clients über ein separates Feld anzugeben, verwenden Sie einfach den bekannten User-Agent-Header. Es gibt kein vorgeschriebenes Format für die Angabe der Client-ID in diesem Header. Wir empfehlen, einfach die ursprüngliche Client-ID und Client-Version durch ein Leerzeichen oder einen Schrägstrich getrennt anzugeben.
  3. Entfernen Sie das Feld client_states. Das ist nicht mehr erforderlich.
  4. Es ist nicht mehr erforderlich, threat_types und ähnliche Felder anzugeben.

Die folgenden Änderungen sollten an der Antwort vorgenommen werden:

  1. Das Feld minimum_wait_duration wurde entfernt. Der Client kann bei Bedarf jederzeit eine neue Anfrage senden.
  2. Das v4-Objekt ThreatMatch wurde in das FullHash-Objekt vereinfacht.
  3. Das Caching wurde auf eine einzige Cache-Dauer vereinfacht. Informationen zur Interaktion mit dem Cache finden Sie oben.