Cookies - SameSite Attribute

Photo by Mohammad Rahmani on Unsplash

Mulai dari versi 84, Chrome mengubah nilai default atribut SameSite pada Cookies menjadi Lax. Layanan yang menggunakan Third-party cookies mungkin akan terpengaruh jika tidak mengatur SameSite dengan benar.

Tinjauan

Cookies adalah mekanisme yang digunakan dalam layanan web untuk menyimpan status, yang biasa digunakan untuk mempertahankan sesi login, keranjang belanja, pelacakan iklan, dll. Namun, penggunaan Cookies secara luas juga menimbulkan masalah privasi dan keamanan, dan SameSite diperkenalkan untuk mengatasi masalah ini.

First-Party and Third-Party

Berdasarkan sumber Cookie (Set-Cookie), setiap Cookie memiliki Domain tertentu. Saat melihat URL saat ini di browser pengguna, jika Domain Cookie cocok dengan URL saat ini, itu adalah First-Party; sebaliknya, itu adalah Third-Party.

Third-party

Misalnya, saat menjelajahi situs a.com, sebuah permintaan (request) dikirim ke third-party.com dan menerima Cookie dari third-party.com. Karena browser secara otomatis menyertakan Cookie dengan Domain yang sama dalam permintaan, jika Anda kemudian menjelajahi situs lain seperti b.com dan situs tersebut juga mengirim permintaan ke third-party.com, server akan menerima Cookie. Untuk kedua situs ini, Cookie third-party.com adalah Third-party.

First-party

Jika Anda menjelajahi situs web yang cocok dengan Domain third-party.com, Cookie juga akan dikirim. Dalam hal ini, Cookie ini disebut First-party.

Same-Origin and Same-Site

Contoh sebelumnya menyebutkan penggunaan Domain untuk menentukan jenis Cookie, tetapi cara yang lebih tepat adalah menentukan apakah Situs (Site) itu sama. Apakah ini berhubungan dengan Same-origin yang sering kita lihat?

Cookies SameSite

Origin

Origin terdiri dari Scheme, Host, dan Port. Metode penentuannya sangat sederhana: jika Scheme, Host, dan Port dari dua URL semuanya sama, mereka adalah Same-origin; sebaliknya, mereka adalah Cross-origin.

Site

Penentuan Same-Site melibatkan Effective top-level domains (eTLDs). Semua eTLD didefinisikan dalam Public Suffix List, dan sebuah Site terdiri dari sebuah eTLD ditambah sebuah awalan (prefix).

Sebagai contoh: github.io ada di Public Suffix List. Menambahkan awalan (misalnya, a.github.io) membuatnya menjadi sebuah Site. Oleh karena itu, a.github.io dan b.github.io adalah dua Site yang berbeda (Cross-site).

example.com tidak ada di Public Suffix List, tetapi .com ada, jadi example.com adalah sebuah Site, dan a.example.com serta b.example.com adalah Site yang sama (Same-site).

Ingat bahwa Site tidak termasuk Port, jadi meskipun Port-nya berbeda, mereka masih bisa menjadi Same-site.

Why SameSite?

Mekanisme di mana “setiap Permintaan membawa cookie dari Domain tersebut” juga membawa masalah keamanan dan lainnya, yang paling penting adalah Cross-site request forgery (CSRF).

CSRF

Misalkan seorang pengguna telah login ke example.com dan mendapatkan Cookie. Ketika pengguna menjelajahi situs berbahaya evil.com, JavaScript di situs tersebut dapat mengirim Permintaan POST ke example.com/pay?amount=1000. Browser akan secara otomatis menyertakan Cookie example.com, dan pengguna tanpa sadar membayar 1000 dolar. Server tidak dapat menentukan dari mana Permintaan ini berasal.

Keterbatasan

Cookie sendiri tidak dapat diatur untuk dikirim hanya dalam lingkungan First-party, jadi Permintaan membawa Cookie di lingkungan apa pun. Server tidak dapat mengidentifikasi sumber Permintaan dan hanya dapat merespons seperti biasa, menyebabkan Klien membuang bandwidth mengirim Cookie yang tidak berguna.

Solusi

Dengan atribut SameSite, kita dapat mengatur kondisi pengiriman Cookie secara individual di lingkungan yang berbeda.

SameSite

Atribut SameSite memiliki tiga nilai. Mengaturnya ke Strict atau Lax dapat membatasi Cookie agar hanya dikirim dalam Permintaan Same-Site. Jika dibiarkan kosong, perilakunya bergantung pada browser; untuk Chrome, defaultnya adalah Lax.

Strict

Cookie hanya dikirim dalam lingkungan First-party. Namun, ada masalah: misalkan pengguna melihat tautan posting Facebook di example.com (katakanlah fb.com). Bahkan jika pengguna telah login ke fb.com dan memiliki Cookie, mengklik tautan tidak akan mengirim Cookie karena kedua situs tersebut Cross-site, jadi mereka hanya akan melihat halaman login.

Oleh karena itu, Strict cocok untuk tindakan sensitif, seperti menghapus postingan, melakukan pembayaran, dll.

Lax

Untuk mengatasi keterbatasan Strict yang terlalu ketat, Lax mengizinkan pengiriman Cookie bahkan dalam situasi Cross-site dalam kasus berikut:

Mengetik URL di bilah alamat
Mengklik tautan <a href="...">
Mengirim formulir <form method="GET">
Prerendering <link rel="prerender" href="...">

Kasus-kasus ini memiliki dua kesamaan: semuanya adalah permintaan GET dan semuanya memicu Navigasi Tingkat Atas (Top-level Navigation). Ini menghindari masalah Strict yang mengharuskan login lagi setiap kali, dan juga mencegah pengiriman Cookie tanpa sadar saat menjelajahi situs web lain.

Lax + POST

Namun, untuk menghindari rusaknya beberapa alur login yang ada, Chrome saat ini sedikit melonggarkan batasan untuk SameSite=Lax, memberikan waktu bagi pengembang untuk beradaptasi.

Dalam waktu dua menit setelah Cookie ditetapkan, apa pun Metode Permintaannya, selama itu memicu navigasi halaman tingkat atas, Cookie akan dikirim. Ini berarti jika browser berpindah halaman, misalnya mengirim formulir <form method="POST">.

Untuk detailnya, silakan lihat utas tentang Lax + POST.

None

Untuk mengirim Third-party cookie, Anda harus mengatur SameSite=None; Secure. Ya, mulai sekarang, jika Anda ingin mengirim Third-party cookie di lingkungan pengujian, harap siapkan https://localhost.

Selain itu, mengirim Cross-Origin Requests melalui XHR/Fetch memerlukan pengaturan withCredentials: true untuk mengirim Cookie dan membuat Set-Cookie di header Respons efektif. Server juga harus mengatur Access-Control-Allow-Credentials: true di header Respons agar JavaScript dapat mengakses konten Respons.

Browser yang Tidak Mendukung

Belum semua browser mendukung aturan SameSite terbaru, jadi beberapa solusi sementara (Workaround) dapat ditambahkan di Server untuk mendukung berbagai browser:

Metode ini dapat memecahkan masalah untuk hampir semua browser, tetapi kelemahannya adalah akan ada dua salinan Cookie:

Set-cookie: name=value; SameSite=None; Secure
Set-cookie: name-legacy=value; Secure

Kode sisi server:

if (req.cookies['name']) {
  // Gunakan yang baru jika ada
  cookieVal = req.cookies['name'];
} else if (req.cookies['name-legacy']) {
  // Jika tidak, gunakan yang lama
  cookieVal = req.cookies['name-legacy'];
}

User Agent

Tentukan browser menggunakan User agent dari Permintaan untuk memutuskan konten Set-Cookie. Metode ini hanya memerlukan modifikasi kode yang mengatur Cookie, tanpa mengubah bagian Parsing. Namun, metode penilaian ini melibatkan lebih banyak variabel dan membuatnya lebih mudah untuk mengatur Cookie yang salah.

Tinjauan Kembali

Cookie tanpa atribut SameSite yang disetel akan default ke SameSite=Lax dan tidak dapat dikirim dalam lingkungan Cross-site.
Untuk mengirim Cookie di Cross-site, Anda perlu mengatur SameSite=None; Secure.
Anda dapat menggunakan SameSite sandbox untuk menguji apakah browser Anda saat ini mematuhi aturan SameSite terbaru.