URLs and Hashing

Dieser Abschnitt enthält detaillierte Spezifikationen dazu, wie Clients URLs prüfen.

URL-Kanonisierung

Bevor URLs geprüft werden, muss der Client eine Kanonisierung dieser URL durchführen.

Zu Anfang wird davon ausgegangen, dass der Client die URL geparst und gemäß RFC 2396 gültig gemacht hat. Wenn die URL einen internationalisierten Domainnamen (IDN) verwendet, sollte der Client die URL in die ASCII-Point-Code-Darstellung konvertieren. Die URL muss eine Pfadkomponente enthalten. Das heißt, sie muss nach der Domain mindestens einen Schrägstrich (http://google.com/ anstelle von http://google.com) haben.

Entfernen Sie zuerst die Tabulatorzeichen (0x09), CR (0x0d) und LF (0x0a) aus der URL. Entfernen Sie für diese Zeichen keine Escape-Sequenzen (z.B. %0a).

Zweitens: Wenn die URL in einem Fragment endet, entfernen Sie das Fragment. Kürzen Sie beispielsweise http://google.com/#frag auf http://google.com/.

Drittens: Entfernen Sie Prozent-Escape-Zeichen solange aus der URL, bis keine Prozent-Escape-Zeichen mehr vorhanden sind. Dies kann dazu führen, dass die URL ungültig wird.

So kanonisieren Sie den Hostnamen:

Extrahieren Sie den Hostnamen aus der URL und führen Sie dann folgende Schritte aus:

  1. Entfernen Sie alle vor- und nachgestellten Punkte.
  2. Ersetzen Sie aufeinanderfolgende Punkte durch einen einzelnen Punkt.
  3. Wenn der Hostname als IPv4-Adresse geparst werden kann, normalisieren Sie ihn auf vier durch Kommas getrennte Dezimalwerte. Der Client sollte mit jeder zulässigen IP-Adresskodierung umgehen, einschließlich oktal, hex und weniger als vier Komponenten.
  4. Wenn der Hostname als IPv6-Adresse in Klammern geparst werden kann, normalisieren Sie ihn, indem Sie unnötige führende Nullen in den Komponenten entfernen und Nullkomponenten mithilfe der Syntax mit doppeltem Doppelpunkt zusammenfassen. Beispiel: [2001:0db8:0000::1] sollte in [2001:db8::1] umgewandelt werden. Wenn der Hostname einen der beiden folgenden speziellen IPv6-Adresstypen hat, wandeln Sie ihn in IPv4 um:
    • Eine IPv4-adressierte IPv6-Adresse wie [::ffff:1.2.3.4], die in 1.2.3.4 umgewandelt werden soll;
    • Eine NAT64-Adresse mit dem bekannten Präfix 64:ff9b::/96, z. B. [64:ff9b::1.2.3.4], die in 1.2.3.4 umgewandelt werden soll.
  5. Verwenden Sie Kleinbuchstaben für den gesamten String.

So kanonisieren Sie den Pfad:

  1. Lösen Sie die Sequenzen /../ und /./ im Pfad auf, indem Sie /./ durch / ersetzen und /../ zusammen mit der vorherigen Pfadkomponente entfernen.
  2. Ersetzen Sie aufeinanderfolgende Schrägstriche durch einen Schrägstrich.

Wenden Sie diese Pfadkanonisierung nicht auf die Suchparameter an.

Setzen Sie in der URL alle Zeichen mit dem Escape-Zeichen in Prozent um, die so aussehen: <= ASCII 32, >= 127, # oder %. Die Escape-Zeichen müssen aus Großbuchstaben bestehen.

Host-Suffix-Pfad-Präfix-Ausdrücke

Nachdem die URL kanonisiert wurde, müssen Sie als Nächstes die Suffix-/Präfixausdrücke erstellen. Jeder Suffix-/Präfixausdruck besteht aus einem Hostsuffix (oder vollständigem Host) und einem Pfadpräfix (oder vollständigem Pfad).

Der Client bildet bis zu 30 verschiedene Kombinationen aus Hostsuffix und Pfadpräfix. Diese Kombinationen verwenden nur die Host- und Pfadkomponenten der URL. Schema, Nutzername, Passwort und Port werden verworfen. Wenn die URL Suchparameter enthält, enthält mindestens eine Kombination den vollständigen Pfad und die Suchparameter.

Für den Host versucht der Client höchstens fünf verschiedene Strings. Diese sind:

  • Wenn der Hostname kein IPv4- oder IPv6-Literal ist, bis zu vier Hostnamen, die mit der eTLD+1-Domain beginnen und nacheinander führende Komponenten hinzufügen. Die Bestimmung der eTLD+1 sollte auf der öffentlichen Suffixliste basieren. a.b.example.com würde beispielsweise zur eTLD+1-Domain example.com und zum Host mit einer zusätzlichen Hostkomponente b.example.com führen.
  • Der genaue Hostname in der URL. Im vorherigen Beispiel würde a.b.example.com überprüft.

Für den Pfad versucht der Client höchstens sechs verschiedene Strings. Sie sind:

  • Der genaue Pfad der URL, einschließlich der Suchparameter.
  • Der genaue Pfad der URL ohne Abfrageparameter.
  • Die vier Pfade, die durch den Start am Stamm (/) und das aufeinanderfolgende Anhängen von Pfadkomponenten entstehen, einschließlich eines abschließenden Schrägstrichs.

Die folgenden Beispiele veranschaulichen das Überprüfungsverhalten:

Für die URL http://a.b.com/1/2.html?param=1 versucht der Client diese möglichen Strings:

a.b.com/1/2.html?param=1
a.b.com/1/2.html
a.b.com/
a.b.com/1/
b.com/1/2.html?param=1
b.com/1/2.html
b.com/
b.com/1/

Für die URL http://a.b.c.d.e.f.com/1.html versucht der Client diese möglichen Strings:

a.b.c.d.e.f.com/1.html
a.b.c.d.e.f.com/
c.d.e.f.com/1.html
c.d.e.f.com/
d.e.f.com/1.html
d.e.f.com/
e.f.com/1.html
e.f.com/
f.com/1.html
f.com/

Hinweis: Überspringen Sie b.c.d.e.f.com, da wir nur die letzten fünf Hostnamenkomponenten und den vollständigen Hostnamen verwenden.

Für die URL http://1.2.3.4/1/ versucht der Client diese möglichen Strings:

1.2.3.4/1/
1.2.3.4/

Für die URL http://example.co.uk/1 versucht der Client diese möglichen Strings:

example.co.uk/1
example.co.uk/

Hashing

Google Safe Browsing verwendet ausschließlich SHA256 als Hash-Funktion. Diese Hash-Funktion sollte auf die obigen Ausdrücke angewendet werden.

Der vollständige 32-Byte-Hash wird je nach Umständen auf 4 Byte, 8 Byte oder 16 Byte gekürzt:

  • Bei Verwendung der Methode „hashes.search“ müssen die Hashes in der Anfrage derzeit auf genau 4 Byte gekürzt werden. Das Senden zusätzlicher Bytes in dieser Anfrage beeinträchtigt den Datenschutz der Nutzer.

  • Wenn Sie die Listen für die lokale Datenbank mit der Methode „hashList.get“ oder der Methode „hashLists.batchGet“ herunterladen, wird die Länge der vom Server gesendeten Hashes in der Benennungskonvention der Listen codiert, die ein Suffix mit der Hashlänge enthalten. Weitere Informationen finden Sie im Abschnitt Verfügbare Listen.