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 gesamte Liste der Google Safe Browsing-Bedrohungen zu verwalten, die im Laufe der Zeit immer länger wird.

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 Version 4, in der Listen durch das Tupel aus Bedrohungstyp, Plattformtyp und Bedrohungseintragstyp identifiziert werden, werden Listen in Version 5 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 jedoch, 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 mit dem Feld state in Version 4 an den Server gesendet wurde, kann in Version 5 einfach mit dem 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. Die Logik zum Decodieren von Rice-Golomb-codierten Hashes erfordert zwei Hauptanpassungen:
    • Byte-Reihenfolge und Sortierung:In Version 4 wurden die zurückgegebenen Hashes als Little-Endian-Werte sortiert. In Version 5 werden sie als Big-Endian-Werte behandelt. Da die lexikografische Sortierung von Bytestrings der numerischen Sortierung von Big-Endian-Werten entspricht, müssen Clients keinen speziellen Sortierschritt mehr ausführen. Die benutzerdefinierte Little-Endian-Sortierung, wie in der Chromium v4-Implementierung, kann entfernt werden, wenn sie zuvor implementiert wurde.
    • Variable Hash-Längen:Der Decodierungsalgorithmus muss aktualisiert werden, um verschiedene Hash-Längen zu unterstützen, die im Feld HashList.compressed_additions zurückgegeben werden können. Das ist nicht nur die in Version 4 verwendete Hash-Länge von vier Byte. Die Länge der in der Antwort zurückgegebenen Hashes kann anhand des von hashLists.list zurückgegebenen HashList.metadata.hash_length bestimmt werden. Alternativ gibt die Benennung der angeforderten Hash-Liste auch die erwarteten Hash-Größen an, die von der Liste zurückgegeben werden. Weitere Informationen zu den Hash-Listen finden Sie auf der Seite Lokale Datenbank.

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 jedoch, 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 zum Interagieren mit dem Cache finden Sie oben.