URLs and Hashing

В этом разделе содержатся подробные сведения о том, как клиенты проверяют URL-адреса.

Канонизация URL-адресов

Прежде чем какие-либо URL-адреса будут проверены, ожидается, что клиент выполнит некоторую канонизацию этого URL-адреса.

Для начала мы предполагаем, что клиент проанализировал URL-адрес и сделал его действительным в соответствии с RFC 2396. Если URL-адрес использует интернационализированное доменное имя (IDN), клиент должен преобразовать URL-адрес в представление Punycode ASCII. URL-адрес должен включать компонент пути; то есть после домена должна быть хотя бы одна косая черта ( http://google.com/ вместо http://google.com ).

Сначала удалите символы табуляции (0x09), CR (0x0d) и LF (0x0a) из URL-адреса. Не удаляйте escape-последовательности для этих символов (например, %0a ).

Во-вторых, если URL-адрес заканчивается фрагментом, удалите этот фрагмент. Например, сократите http://google.com/#frag до http://google.com/ .

В-третьих, несколько раз удаляйте процентное экранирование URL-адреса, пока на нем больше не будет процентного экранирования. (Это может сделать URL-адрес недействительным.)

Чтобы канонизировать имя хоста:

Извлеките имя хоста из URL-адреса, а затем:

  1. Удалите все ведущие и конечные точки.
  2. Замените последовательные точки одной точкой.
  3. Если имя хоста можно проанализировать как адрес IPv4, нормализуйте его до 4 десятичных значений, разделенных точками. Клиент должен обрабатывать любую допустимую кодировку IP-адреса, включая восьмеричную, шестнадцатеричную и менее четырех компонентов.
  4. Если имя хоста можно проанализировать как IPv6-адрес в квадратных скобках, нормализуйте его, удалив ненужные начальные нули в компонентах и ​​свернув нулевые компоненты, используя синтаксис двойного двоеточия. Например, [2001:0db8:0000::1] следует преобразовать в [2001:db8::1] . Если имя хоста является одним из двух следующих специальных типов адресов IPv6, преобразуйте их в IPv4:
    • Адрес IPv6, сопоставленный с IPv4, например [::ffff:1.2.3.4] , который должен быть преобразован в 1.2.3.4 ;
    • Адрес NAT64 с известным префиксом 64:ff9b::/96 , например [64:ff9b::1.2.3.4] , который следует преобразовать в 1.2.3.4 .
  5. В нижнем регистре всю строку.

Чтобы канонизировать путь:

  1. Разрешите последовательности /../ и /./ в пути, заменив /./ на / и удалив /../ вместе с предыдущим компонентом пути.
  2. Замените серию последовательных косых черт одним символом косой черты.

Не применяйте канонизацию пути к параметрам запроса.

В URL-адресе экранируйте процентами все символы <= ASCII 32, >= 127, # или % . В escape-последовательности следует использовать шестнадцатеричные символы верхнего регистра.

Выражения префикса пути и суффикса хоста

После канонизации URL-адреса следующим шагом будет создание выражений суффикса/префикса. Каждое выражение суффикса/префикса состоит из суффикса хоста (или полного хоста) и префикса пути (или полного пути).

Клиент сформирует до 30 различных возможных комбинаций суффикса хоста и префикса пути. Эти комбинации используют только компоненты хоста и пути URL-адреса. Схема, имя пользователя, пароль и порт удаляются. Если URL-адрес включает параметры запроса, то хотя бы одна комбинация будет включать полный путь и параметры запроса.

Для хоста клиент будет пробовать не более пяти разных строк. Они есть:

  • Если имя хоста не является литералом IPv4 или IPv6, до четырех имен хостов формируются путем начала с домена eTLD+1 и последовательного добавления ведущих компонентов. Определение eTLD+1 должно основываться на списке общедоступных суффиксов . Например, abexample.com приведет к домену eTLD+1 example.com , а также к хосту с одним дополнительным компонентом хоста b.example.com .
  • Точное имя хоста в URL. Следуя предыдущему примеру, будет проверен abexample.com .

Для пути клиент попробует не более шести разных строк. Они есть:

  • Точный путь URL-адреса, включая параметры запроса.
  • Точный путь URL-адреса без параметров запроса.
  • Четыре пути формируются путем начала с корня (/) и последовательного добавления компонентов пути, включая косую черту в конце.

Следующие примеры иллюстрируют поведение проверки:

Для URL-адреса http://abcom/1/2.html?param=1 клиент попытается использовать следующие возможные строки:

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/

Для URL-адреса http://abcdefcom/1.html клиент будет пробовать следующие возможные строки:

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/

(Примечание: пропустите bcdefcom , поскольку мы возьмем только пять последних компонентов имени хоста и полное имя хоста.)

Для URL-адреса http://1.2.3.4/1/ клиент будет пробовать следующие возможные строки:

1.2.3.4/1/
1.2.3.4/

Для URL-адреса http://example.co.uk/1 клиент будет пробовать следующие возможные строки:

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

Хеширование

Google Safe Browsing использует исключительно SHA256 в качестве хэш-функции. Эту хеш-функцию следует применить к приведенным выше выражениям.

Полный 32-байтовый хеш будет, в зависимости от обстоятельств, сокращен до 4, 8 или 16 байт:

  • При использовании метода hashes.search мы в настоящее время требуем, чтобы хеши в запросе были усечены ровно до 4 байтов. Отправка дополнительных байтов в этом запросе поставит под угрозу конфиденциальность пользователя.

  • При загрузке списков для локальной базы данных с помощью метода hashList.get или метода hashLists.batchGet длина хешей, отправляемых сервером, кодируется в рамках соглашения об именах списков, содержащих суффикс, указывающий длину хеша. Дополнительную информацию см. в разделе «Доступные списки» .