URLs and Hashing

Esta seção contém especificações detalhadas de como os clientes verificam URLs.

Canonização de URLs

Antes de verificar qualquer URL, o cliente precisa realizar uma canonização nesse URL.

Para começar, presumimos que o cliente analisou o URL e o tornou válido de acordo com a RFC 2396. Se o URL usar um nome de domínio internacionalizado (IDN, na sigla em inglês), o cliente deverá converter o URL para a representação ASCII de punycode. O URL precisa incluir um componente de caminho, ou seja, ele precisa ter pelo menos uma barra após o domínio (http://google.com/ em vez de http://google.com).

Primeiro, remova os caracteres tab (0x09), CR (0x0d) e LF (0x0a) do URL. Não remova sequências de escape para esses caracteres (por exemplo, %0a).

Segundo, se o URL terminar em um fragmento, remova o fragmento. Por exemplo, reduza http://google.com/#frag para http://google.com/.

Em terceiro lugar, faça o escape de porcentagem do URL repetidamente até que ele não tenha mais escapes de porcentagem. Isso pode tornar o URL inválido.

Para canonizar o nome do host:

Extraia o nome do host do URL e:

  1. Remova todos os pontos iniciais e finais.
  2. Substitua os pontos consecutivos por um único ponto.
  3. Se o nome do host puder ser analisado como um endereço IPv4, normalize-o para quatro valores decimais separados por ponto. O cliente precisa processar qualquer codificação de endereço IP legal, incluindo octal, hexadecimal e menos de quatro componentes.
  4. Se o nome do host puder ser analisado como um endereço IPv6 entre colchetes, normalize-o removendo zeros iniciais desnecessários nos componentes e reduzindo os componentes nulos usando a sintaxe de dois-pontos. Por exemplo, [2001:0db8:0000::1] precisa ser transformado em [2001:db8::1]. Se o nome do host for um dos dois tipos de endereço IPv6 especiais a seguir, transforme-o em IPv4:
    • Um endereço IPv6 mapeado para IPv4, como [::ffff:1.2.3.4], que precisa ser transformado em 1.2.3.4.
    • Um endereço NAT64 usando o prefixo conhecido 64:ff9b::/96, como [64:ff9b::1.2.3.4], que precisa ser transformado em 1.2.3.4.
  5. Minúsculas a string inteira.

Para canonizar o caminho:

  1. Resolva as sequências /../ e /./ no caminho substituindo /./ por / e removendo /../ junto com o componente de caminho anterior.
  2. Substitua execuções de barras consecutivas por uma única barra.

Não aplique essas canonizações de caminho aos parâmetros de consulta.

No URL, use a função de escape de porcentagem para todos os caracteres que são {= ASCII 32, = = 127, # ou %. Os escape devem usar caracteres hexadecimais em maiúsculas.

Expressões de prefixo de caminho de sufixo de host

Depois que o URL for canonizado, a próxima etapa será criar as expressões de sufixo/prefixo. Cada expressão de sufixo/prefixo consiste em um sufixo de host (ou host completo) e um prefixo de caminho (ou caminho completo).

O cliente vai formar até 30 combinações possíveis de sufixo de host e prefixo de caminho. Essas combinações usam apenas os componentes de host e caminho do URL. O esquema, o nome de usuário, a senha e a porta são descartados. Se o URL incluir parâmetros de consulta, pelo menos uma combinação vai incluir o caminho completo e os parâmetros de consulta.

Para o host, o cliente tentará no máximo cinco strings diferentes. São eles:

  • Se o nome de host não for um literal IPv4 ou IPv6, até quatro nomes de host formados começando pelo domínio eTLD+1 e adicionando componentes principais sucessivos. A determinação do eTLD+1 precisa ser baseada na lista de sufixos públicos. Por exemplo, a.b.example.com resultaria no domínio eTLD+1 de example.com, bem como no host com um componente de host adicional b.example.com.
  • O nome do host exato no URL. Seguindo o exemplo anterior, a.b.example.com seria verificado.

Para o caminho, o cliente tentará no máximo seis strings diferentes. Elas são:

  • O caminho exato do URL, incluindo os parâmetros de consulta.
  • O caminho exato do URL, sem parâmetros de consulta.
  • Os quatro caminhos formados começando pela raiz (/) e anexando componentes de caminho, incluindo uma barra final.

Os exemplos a seguir ilustram o comportamento da verificação:

Para o URL http://a.b.com/1/2.html?param=1, o cliente tentará estas strings possíveis:

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/

Para o URL http://a.b.c.d.e.f.com/1.html, o cliente tentará estas strings possíveis:

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/

b.c.d.e.f.com é ignorado, já que vamos usar apenas os cinco últimos componentes do nome do host e o nome completo.

Para o URL http://1.2.3.4/1/, o cliente tentará estas strings possíveis:

1.2.3.4/1/
1.2.3.4/

Para o URL http://example.co.uk/1, o cliente tentará estas strings possíveis:

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

Hash

O Google Safe Browsing usa exclusivamente o SHA256 como função hash. Essa função de hash precisa ser aplicada às expressões acima.

O hash completo de 32 bytes será truncado para 4, 8 ou 16 bytes, dependendo das circunstâncias:

  • Ao usar o método hashes.search, atualmente exigimos que os hashes na solicitação sejam truncados para exatamente 4 bytes. O envio de bytes adicionais nessa solicitação compromete a privacidade do usuário.

  • Ao fazer o download das listas para o banco de dados local usando o método hashList.get ou o método hashLists.batchGet, o comprimento dos hashes enviados pelo servidor é codificado na convenção de nomenclatura das listas que contêm um sufixo que indica o comprimento do hash. Consulte a seção Listas disponíveis para mais detalhes.