URLs and Hashing

Bagian ini berisi spesifikasi mendetail tentang cara klien memeriksa URL.

Kanonikalisasi URL

Sebelum URL diperiksa, klien diharapkan melakukan beberapa kanonikalisasi pada URL tersebut.

Untuk memulai, kita mengasumsikan bahwa klien telah mengurai URL dan membuatnya valid sesuai dengan RFC 2396. Jika URL menggunakan nama domain internasional (IDN), klien harus mengonversi URL ke representasi Punycode ASCII. URL harus menyertakan komponen jalur; yaitu, harus memiliki minimal satu garis miring setelah domain (http://google.com/, bukan http://google.com).

Pertama, hapus karakter tab (0x09), CR (0x0d), dan LF (0x0a) dari URL. Jangan hapus urutan escape untuk karakter ini (misalnya, %0a).

Kedua, jika URL berakhir dengan fragmen, hapus fragmen tersebut. Misalnya, persingkat http://google.com/#frag menjadi http://google.com/.

Ketiga, hapus persentase URL berulang kali hingga tidak ada lagi persentase yang di-escape. (Tindakan ini dapat membuat URL menjadi tidak valid.)

Untuk melakukan kanonisasi nama host:

Ekstrak nama host dari URL, lalu:

  1. Hapus semua titik di awal dan di akhir.
  2. Mengganti titik berurutan dengan satu titik.
  3. Jika nama host dapat diuraikan sebagai alamat IPv4, normalisasi menjadi 4 nilai desimal yang dipisahkan titik. Klien harus menangani encoding alamat IP yang sah, termasuk oktal, heksadesimal, dan kurang dari empat komponen.
  4. Jika nama host dapat diuraikan sebagai alamat IPv6 dalam tanda kurung, normalisasi dengan menghapus nol di awal yang tidak diperlukan dalam komponen dan menciutkan komponen nol menggunakan sintaksis titik dua ganda. Misalnya, [2001:0db8:0000::1] harus diubah menjadi [2001:db8::1]. Jika nama host adalah salah satu dari dua jenis alamat IPv6 khusus berikut, ubah menjadi IPv4:
    • Alamat IPv6 yang dipetakan IPv4, seperti [::ffff:1.2.3.4], yang harus diubah menjadi 1.2.3.4;
    • Alamat NAT64 menggunakan awalan 64:ff9b::/96 yang terkenal, seperti [64:ff9b::1.2.3.4], yang harus diubah menjadi 1.2.3.4.
  5. Mengubah seluruh string menjadi huruf kecil.

Untuk melakukan kanonikalisasi jalur:

  1. Selesaikan urutan /../ dan /./ di jalur dengan mengganti /./ dengan /, dan menghapus /../ beserta komponen jalur sebelumnya.
  2. Mengganti deretan garis miring berturut-turut dengan satu karakter garis miring.

Jangan terapkan kanonisasi jalur ini ke parameter kueri.

Di URL, gunakan escape persentase untuk semua karakter yang <= ASCII 32, >= 127, #, atau %. Escape harus menggunakan karakter hex huruf besar.

Ekspresi Awalan Jalur Akhiran Host

Setelah URL dikanonikasikan, langkah selanjutnya adalah membuat ekspresi akhiran/awalan. Setiap ekspresi akhiran/awalan terdiri dari akhiran host (atau host lengkap) dan awalan jalur (atau jalur lengkap).

Klien akan membentuk hingga 30 kemungkinan kombinasi akhiran host dan awalan jalur yang berbeda. Kombinasi ini hanya menggunakan komponen host dan jalur URL. Skema, nama pengguna, sandi, dan port akan dihapus. Jika URL menyertakan parameter kueri, setidaknya satu kombinasi akan menyertakan jalur lengkap dan parameter kueri.

Untuk host, klien akan mencoba maksimal lima string yang berbeda. Bagian-bagian tersebut adalah:

  • Jika nama host bukan literal IPv4 atau IPv6, maksimal empat nama host dapat dibentuk dengan memulai dari domain eTLD+1 dan menambahkan komponen utama berturut-turut. Penentuan eTLD+1 harus didasarkan pada Daftar Akhiran Publik. Misalnya, a.b.example.com akan menghasilkan domain eTLD+1 example.com serta host dengan satu komponen host tambahan b.example.com.
  • Nama host yang sama persis di URL. Mengikuti contoh sebelumnya, a.b.example.com akan diperiksa.

Untuk jalur, klien akan mencoba maksimal enam string yang berbeda. Bagian-bagian tersebut adalah:

  • Jalur URL yang tepat, termasuk parameter kueri.
  • Jalur URL yang tepat, tanpa parameter kueri.
  • Empat jalur yang terbentuk dengan memulai dari root (/) dan menambahkan komponen jalur secara berurutan, termasuk garis miring di akhir.

Contoh berikut mengilustrasikan perilaku pemeriksaan:

Untuk URL http://a.b.com/1/2.html?param=1, klien akan mencoba kemungkinan string berikut:

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/

Untuk URL http://a.b.c.d.e.f.com/1.html, klien akan mencoba kemungkinan string berikut:

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/

(Catatan: lewati b.c.d.e.f.com, karena kita hanya akan mengambil lima komponen nama host terakhir, dan nama host lengkap.)

Untuk URL http://1.2.3.4/1/, klien akan mencoba kemungkinan string berikut:

1.2.3.4/1/
1.2.3.4/

Untuk URL http://example.co.uk/1, klien akan mencoba kemungkinan string berikut:

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

Hashing

Google Safe Browsing secara eksklusif menggunakan SHA256 sebagai fungsi hash. Fungsi hash ini harus diterapkan ke ekspresi di atas.

Hash 32 byte penuh, bergantung pada situasinya, akan dipotong menjadi 4 byte, 8 byte, atau 16 byte:

  • Saat menggunakan metode hashes.search, saat ini kami mewajibkan hash dalam permintaan untuk dipotong menjadi tepat 4 byte. Mengirim byte tambahan dalam permintaan ini akan membahayakan privasi pengguna.

  • Saat mendownload daftar untuk database lokal menggunakan metode hashList.get atau metode hashLists.batchGet, panjang hash yang dikirim oleh server dienkode dalam konvensi penamaan daftar yang berisi akhiran yang menunjukkan panjang hash. Lihat bagian Daftar yang Tersedia untuk mengetahui detail selengkapnya.