Migration From V4

Eine wichtige Verbesserung von Google Safe Browsing v5 gegenüber v4 (insbesondere der v4 Update API) ist die Datenaktualität und -abdeckung. Da der Schutz stark von der vom Kunden verwalteten lokalen Datenbank abhängt, sind die Verzögerung und Größe der Aktualisierung der lokalen Datenbank die Hauptursachen für den verpassten Schutz. In Version 4 dauert es in der Regel 20 bis 50 Minuten, bis der Client die aktuellste Version der Bedrohungslisten abgerufen hat. Leider verbreiten sich Phishing-Angriffe schnell: 2021 waren 60% der Websites, über die Angriffe ausgeführt wurden, weniger als 10 Minuten online. Unsere Analyse zeigt, dass etwa 25–30% des fehlenden Phishing-Schutzes auf solche veraltete Daten zurückzuführen sind. Außerdem sind einige Geräte nicht in der Lage, die gesamte Liste der Google Safe Browsing-Bedrohungslisten zu verwalten, die im Laufe der Zeit immer länger wird.

Wenn Sie derzeit die Update API v4 verwenden, können Sie nahtlos von Version 4 auf Version 5 migrieren, ohne die lokale Datenbank zurücksetzen oder löschen zu müssen. In diesem Abschnitt wird beschrieben, wie das geht.

Listenaktualisierungen umwandeln

Im Gegensatz zu Version 4, in der Listen durch den Tupel aus Bedrohungstyp, Plattformtyp und Bedrohungseintragstyp identifiziert werden, werden Listen in Version 5 einfach durch den Namen identifiziert. Dies bietet Flexibilität, wenn mehrere V5-Listen denselben Bedrohungstyp haben. Plattformtypen und Bedrohungseintragstypen wurden in Version 5 entfernt.

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

An der Anfrage sollten die folgenden Änderungen vorgenommen werden:

  1. Entfernen Sie das v4-ClientInfo-Objekt vollständig. Anstatt die Identifikation eines Clients über ein spezielles Feld anzugeben, verwenden Sie einfach den bekannten User-Agent-Header. Es gibt kein vorgeschriebenes Format für die Angabe der Kundenidentifikation in diesem Header. Wir empfehlen, einfach die ursprüngliche Kunden-ID und die Kundenversion durch ein Leerzeichen oder einen Schrägstrich zu trennen.
  2. Für jedes v4-ListUpdateRequest-Objekt: * Suchen Sie in der Tabelle oben 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 würde, kann in Version 5 einfach über das Feld versions gesendet werden.
    • Für die Einschränkungen von Version 4 wird in Version 5 eine vereinfachte Version namens SizeConstraints verwendet. Zusätzliche Felder wie region sollten entfernt werden.

An der Antwort sollten die folgenden Änderungen vorgenommen werden:

  1. Das Enum ResponseType in Version 4 wird einfach durch ein boolesches Feld namens partial_update ersetzt.
  2. Das Feld minimum_wait_duration kann jetzt null sein oder weggelassen werden. Ist dies der Fall, wird der Kunde aufgefordert, sofort eine weitere Anfrage zu stellen. Das passiert nur, wenn der Client in SizeConstraints eine kleinere Einschränkung für die maximale Aktualisierungsgröße als 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 sind. Sowohl in Version 4 als auch in Version 5 werden 32-Bit-Hash-Präfixe lexikografisch sortiert. In Version 4 werden diese Präfixe bei der Sortierung jedoch als Little-Endian behandelt, während sie in Version 5 als Big-Endian behandelt werden. Das bedeutet, dass der Client keine Sortierung vornehmen muss, da die lexikografische Sortierung mit Big-Endian identisch mit der numerischen Sortierung ist. Ein Beispiel dieser Art 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 konvertieren

In Version 4 wird die Methode „fullHashes.find“ verwendet, um vollständige Hashes abzurufen. Die entsprechende Methode in Version 5 ist die hashes.search-Methode.

An der Anfrage sollten die folgenden Änderungen 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 Identifikation eines Clients über ein spezielles Feld anzugeben, verwenden Sie einfach den bekannten User-Agent-Header. Es gibt kein vorgeschriebenes Format für die Angabe der Kundenidentifikation in diesem Header. Wir empfehlen, die ursprüngliche Kunden-ID und die Kundenversion einfach durch ein Leerzeichen oder einen Schrägstrich zu trennen.
  3. Entfernen Sie das Feld client_states. Das ist nicht mehr erforderlich.
  4. Das Feld threat_types und ähnliche Felder sind nicht mehr erforderlich.

An der Antwort sollten die folgenden Änderungen vorgenommen werden:

  1. Das Feld minimum_wait_duration wurde entfernt. Der Kunde kann bei Bedarf jederzeit eine neue Anfrage stellen.
  2. Das ThreatMatch-Objekt der Version 4 wurde in das FullHash-Objekt vereinfacht.
  3. Das Caching wurde auf eine einzige Cachedauer vereinfacht. Weitere Informationen zur Interaktion mit dem Cache findest du oben.