Mit den Safe Browsing APIs können Ihre Clientanwendungen URL-Prüfungen in Echtzeit oder listenbasiert anhand der von Google ständig aktualisierten Listen unsicherer Webressourcen durchführen. Beispiele für unsichere Webressourcen sind Social-Engineering-Websites (Phishing- und betrügerische Websites) sowie Websites, die Malware oder unerwünschte Software hosten. Alle URLs auf einer Safe Browsing-Liste gelten als unsicher.
Um festzustellen, ob eine URL auf einer der Safe Browsing-Listen steht, können Clients entweder urls.search oder hashes.search verwenden.
Das ist neu
Datenaktualität
Bisher haben Safe Browsing-Clients regelmäßig Bedrohungslisten heruntergeladen, die zum Abgleich mit potenziellen Bedrohungen verwendet werden. Da sowohl das Bedrohungsvolumen als auch die Geschwindigkeit im Laufe der Zeit zugenommen haben, sind diese lokalen Bedrohungslisten gegen moderne Bedrohungen weniger effektiv geworden.
Um diese Lücke zu schließen, führen wir die Möglichkeit ein, Protokolle auf check-by-default umzustellen, anstatt des bisher in V4 verfügbaren allow-by-default-Protokolls. Dazu wird die Möglichkeit eingeführt, eine Liste wahrscheinlicher harmloser Websites herunterzuladen, die als „Globaler Cache“ bezeichnet wird. Wenn eine URL nicht im globalen Cache gefunden wird, sollte der Client eine Prüfung mit der API durchführen, um festzustellen, ob die URL eine Bedrohung darstellt.
Durch die Möglichkeit, standardmäßig Prüfungen durchzuführen, und die Verbesserung der Datenaktualität im Dienst wird ein schnellerer Schutz vor neuen Bedrohungen in nahezu Echtzeit ermöglicht.
IP-Datenschutz
Die Safe Browsing API verwendet die IP-Adressen nur für grundlegende Netzwerkanforderungen und zum Schutz vor DoS-Angriffen.
Wir haben eine Begleit-API namens Safe Browsing Oblivious HTTP Gateway API eingeführt, um zusätzliche Datenschutzgarantien zu ermöglichen. Dabei wird Oblivious HTTP verwendet, um die IP-Adressen von Endnutzern vor Google zu verbergen. Dabei wird eine verschlüsselte Version der Nutzeranfrage an einen unabhängigen Dritten gesendet, der sie dann an Google weiterleitet. Der Drittanbieter hat also nur Zugriff auf die IP-Adressen und Google nur auf den Inhalt der Anfrage. Der Drittanbieter betreibt ein Oblivious HTTP-Relay (z. B. diesen Dienst von Fastly) und Google betreibt das Oblivious HTTP-Gateway. Dies ist eine optionale Companion-API. Wenn Sie die Funktion in Verbindung mit Google Safe Browsing verwenden, werden die IP-Adressen der Endnutzer nicht mehr an Google gesendet.
Weitere Informationen finden Sie in der Dokumentation zur Safe Browsing Oblivious HTTP Gateway API.
Suchmethoden
Sehen wir uns die verschiedenen Methoden an, mit denen URLs in Echtzeit geprüft werden können.
urls.search
Ermöglicht es Clientanwendungen, URLs an den Safe Browsing-Dienst zu senden, um zu prüfen, ob mit den URLs Bedrohungen verbunden sind.
Vorteile
- Einfache URL-Prüfungen: Sie senden eine Anfrage mit den tatsächlichen URLs und der Server antwortet mit den URLs und den zugehörigen Bedrohungen (falls vorhanden).
Nachteile
- Keine URL-Vertraulichkeit: Die Anfrage enthält die zu prüfenden Roh-URLs.
Wenn die Vor- und Nachteile für Ihre Anforderungen infrage kommen, sollten Sie urls.search verwenden, da es einfach zu bedienen ist.
Lesen Sie sich die Nutzungsbedingungen für die Verwendung der Methode durch, da sie sich von hashes.search unterscheiden.
hashes.search
Ermöglicht es Clientanwendungen, zu prüfen, ob in einer Reihe von URLs bekannte Bedrohungen vorhanden sind, ohne die tatsächlichen URLs an den Dienst weiterzugeben. Dazu wird nur das Hash-Präfix der URL angegeben. Die Antwort enthält vollständige Hashes bekannter Bedrohungen mit dem Shard-Hash-Präfix.
Vorteile
- Vertraulichkeit von URLs: In der Anfrage ist nur ein 4‑Byte-Hash-Präfix der gehashten URL enthalten.
- Kompatibilität: Da der Client die URL-Kanonisierung und das Hashing übernimmt, lässt sich diese Methode nahtlos in Modi integrieren, die eine lokale Datenbank verwenden, z. B. der Echtzeitmodus und der Modus mit lokaler Liste.
Nachteile
- Komplexe URL-Prüfungen: Sie müssen wissen, wie Sie URLs kanonisieren, Suffix-/Präfixausdrücke erstellen und SHA256-Hashes berechnen, um Anfragen an diese Methode zu stellen und Vergleiche mit den lokalen Kopien der Listen mit unsicheren Websites oder des globalen Cache durchzuführen.
Wenn Sie die Vertraulichkeit von URLs priorisieren müssen und den Echtzeitmodus oder den Modus „Lokale Liste“ verwenden möchten, ist hashes.search die empfohlene Methode.
Die HashList-Methoden
Mit diesen Methoden können Clients verschlüsselte Versionen der Listen mit unsicheren Ressourcen und des globalen Cache herunterladen und speichern. Clients können anhand dieser Informationen entscheiden, ob sie eine Echtzeitsuche der betreffenden URLs durchführen sollen.
Diese Methoden sind für den Betrieb des Echtzeitmodus und des Modus „Lokale Liste“ unerlässlich.
Weitere Informationen zur Verwendung dieser Methoden finden Sie auf der Seite Lokale Datenbank.
Beispiele für Anforderungen
In diesem Abschnitt werden einige Beispiele für die direkte Verwendung der HTTP API für den Zugriff auf Safe Browsing dokumentiert. Im Allgemeinen wird empfohlen, ein generiertes Sprach-Binding zu verwenden, da die Codierung und Decodierung automatisch und auf bequeme Weise erfolgt. Weitere Informationen finden Sie in der Dokumentation für diese Bindung.
Beispiel für eine HTTP-Anfrage mit urls.search:
GET https://safebrowsing.googleapis.com/v5alpha1/urls:search?key=INSERT_YOUR_API_KEY_HERE&urls=testsafebrowsing.appspot.com/
Beispiel für eine HTTP-Anfrage mit hashes.search:
GET https://safebrowsing.googleapis.com/v5/hashes:search?key=INSERT_YOUR_API_KEY_HERE&hashPrefixes=WwuJdQ
Beispiel für eine HTTP-Anfrage mit hashLists.batchGet:
GET https://safebrowsing.googleapis.com/v5/hashLists:batchGet?key=INSERT_YOUR_API_KEY_HERE&names=se&names=mw-4b
Alle Antworttexte sind als Protokollzwischenspeicher formatierte Nutzlasten, die Sie decodieren können.