Cookie SameSite Menjadikan Konteks Site Bagian dari Pengiriman Sesi

Cookie HTTP menjadi kredensial ambient pada banyak aplikasi web. Setelah browser menyimpan cookie sesi, request yang cocok dapat membawanya secara otomatis; kode aplikasi tidak perlu menempelkan kredensial pada setiap request. Kemudahan itu juga membentuk masalah keamanan: halaman di site lain dapat menyebabkan browser mengirim request ke aplikasi tempat pengguna sedang terautentikasi.

Atribut cookie SameSite memasukkan konteks request ke keputusan pengiriman browser. Sebuah cookie masih dapat cocok dengan domain, path, masa berlaku, dan persyaratan transport, tetapi tetap tidak dikirim karena request bersifat cross-site. Kontrol ini memindahkan sebagian batas sesi ke titik sebelum kredensial mencapai server.

Site dan origin merupakan batas yang berbeda

SameSite memakai konsep site pada web, bukan same-origin policy. Untuk pemrosesan cookie, aturan schemeful same-site modern membedakan site menggunakan scheme URL bersama registrable domain. Port tidak membentuk site terpisah untuk keputusan ini.

Perbedaan tersebut penting pada sibling host. https://app.example.com dan https://accounts.example.com dapat dianggap same-site walaupun keduanya merupakan origin yang berbeda. Akses JavaScript antara kedua origin tetap dibatasi oleh same-origin policy, tetapi evaluasi cookie SameSite dapat memperlakukan request di antara keduanya sebagai same-site.

Karena itu, SameSite bukan pengganti otorisasi pada tingkat origin. Desain keamanan yang menganggap setiap sibling subdomain saling tidak tepercaya tidak dapat mengandalkan atribut ini saja untuk membentuk pemisahan tersebut.

Strict menghapus jalur pengiriman cross-site

Cookie dengan SameSite=Strict tidak dikirim pada request cross-site. Cookie sesi yang umum dapat menggabungkan aturan tersebut dengan pembatasan transport dan akses script:

Set-Cookie: session=opaque-value; Path=/; Secure; HttpOnly; SameSite=Strict

Properti pentingnya bukan bahwa site lain tidak dapat mengirim request. Browser tetap dapat menjalankan banyak navigasi dan submission lintas site. Properti tersebut terletak pada cookie Strict yang memenuhi syarat tetapi tidak ikut pada request dengan konteks site cross-site.

Hasilnya mengubah request yang terlihat oleh server. Endpoint yang bergantung pada cookie sesi tidak lagi menerima kredensial ambient melalui jalur cross-site tersebut.

Konsekuensinya terlihat pada navigasi biasa. Pengguna yang mengikuti tautan dari site lain tiba tanpa cookie Strict pada navigasi cross-site itu. Aplikasi yang mengharapkan state autentikasi tetap tersedia melalui jalur masuk semacam ini mungkin memerlukan kebijakan yang lebih longgar atau flow terpisah.

Lax mempertahankan pengecualian navigasi yang sempit

SameSite=Lax menahan cookie dari banyak request subresource cross-site dan aksi cross-site yang tidak aman, sambil tetap mengizinkannya pada navigasi top-level yang memenuhi syarat dan memakai safe method. Perilaku ini mempertahankan pola navigasi melalui tautan tanpa membuat cookie tersedia secara luas untuk request cross-site.

Perbedaan tersebut penting untuk endpoint yang mengubah state. Transisi state melalui GET tetap tidak aman terlepas dari kebijakan cookie. Safe HTTP method diharapkan tidak meminta perubahan state, dan perilaku Lax memakai batas semantik tersebut untuk pengecualian navigasi top-level.

Aplikasi karena itu perlu menjaga semantik mutasi tetap selaras dengan HTTP method. SameSite=Lax dapat mengurangi pengiriman kredensial pada request POST cross-site, tetapi tidak dapat memperbaiki endpoint yang menjalankan mutasi sensitif melalui safe method.

Perilaku browser untuk cookie tanpa atribut juga telah bergeser menuju default bergaya Lax. Atribut eksplisit tetap lebih baik karena maksud kebijakan sesi terlihat pada konfigurasi, bukan bergantung pada default browser yang implisit.

None sengaja memulihkan pengiriman cross-site

Sebagian aplikasi memerlukan cookie dalam konteks third-party, misalnya service tertanam yang harus mempertahankan sesinya sendiri ketika berada dalam frame milik site lain. SameSite=None menyatakan bahwa cookie dapat dikirim pada konteks same-site maupun cross-site.

Aturan browser saat ini memasangkan SameSite=None dengan Secure:

Set-Cookie: embed_session=opaque-value; Path=/; Secure; HttpOnly; SameSite=None

None bukan sekadar bentuk Lax yang lebih longgar; nilai ini memilih model pengiriman berbeda. Ketika pengiriman cookie cross-site memang diperlukan, aplikasi secara sengaja membuka kembali jalur yang dibatasi oleh Strict dan Lax. Server kemudian memerlukan kontrol yang sesuai dengan operasinya, termasuk pertahanan anti-CSRF yang spesifik terhadap request ketika kredensial ambient dapat mengotorisasi perubahan state.

Secure melindungi transmisi cookie dengan membatasi pengiriman pada transport aman. Atribut tersebut tidak membuktikan bahwa request cross-site memang dikehendaki pemilik akun.

SameSite mengurangi paparan CSRF tetapi tidak menetapkan otorisasi

Cross-site request forgery memerlukan lebih dari sekadar kemampuan membuat request HTTP. Request palsu juga harus membawa otoritas yang diterima target. Cookie sesi merupakan sumber umum otoritas ambient tersebut, sehingga menahannya pada konteks cross-site menghapus salah satu jalur penting.

Batasnya tetap tidak lengkap. Penyerang same-site dapat ada, terutama ketika organisasi menempatkan aplikasi dengan tingkat kepercayaan berbeda pada sibling subdomain. Sebagian flow aplikasi sengaja memakai SameSite=None. Kredensial lain dapat dikirim melalui mekanisme di luar cookie. Endpoint server juga dapat memiliki cacat otorisasi yang tidak dapat diperbaiki atribut cookie.

Untuk mutasi sensitif, token anti-CSRF yang spesifik terhadap request tetap berguna karena server dapat mewajibkan nilai yang tidak dapat disediakan submission cross-site generik. Metadata request terkait origin dapat menjadi sinyal tambahan jika batasan deployment memungkinkan. Kontrol-kontrol ini menangani bagian berbeda dari masalah autentikasi request.

Scope cookie tetap penting di dalam batas site

SameSite tidak menggantikan Domain, host-only cookie, Path, Secure, atau HttpOnly. Setiap atribut membatasi aspek berbeda dari penyimpanan atau pengiriman cookie.

Cookie sesi host-only menghindari perluasan cookie secara sengaja ke sibling host melalui atribut Domain. Secure membatasi pengiriman jaringan pada transport aman. HttpOnly mencegah akses script biasa melalui document.cookie, sehingga mengurangi satu jalur langsung pencurian cookie ketika eksekusi script berhasil dikompromikan. Path memengaruhi pencocokan request, tetapi bukan batas isolasi antara aplikasi yang saling tidak tepercaya.

Properti-properti ini dapat digabungkan. Cookie sesi dapat sekaligus bersifat host-only, aman pada transport, tidak tersedia bagi JavaScript, dan dibatasi oleh konteks same-site. Menganggap satu flag sebagai keseluruhan batas sesi akan menyisakan jalur pengiriman lain di luar model.

Browser menerapkan kebijakan pengiriman kredensial

SameSite paling tepat diperlakukan sebagai aturan pengiriman kredensial di sisi browser. Server mendeklarasikan kebijakan ketika menetapkan cookie; browser kemudian mengevaluasi konteks request sebelum memutuskan apakah cookie tersebut memenuhi syarat untuk header Cookie.

Penempatan ini bernilai karena kredensial yang tidak diinginkan dapat ditahan sebelum request mencapai logika otorisasi aplikasi. Di titik yang sama terlihat batas mekanismenya. Atribut ini mengendalikan penempelan cookie, bukan pembuatan request, maksud pengguna, semantik endpoint, atau kebenaran otorisasi.

Desain sesi yang kuat memakai properti sempit tersebut secara sengaja: scope cookie membatasi ke mana kredensial dapat bergerak, SameSite membatasi konteks site yang dapat membawanya, dan kontrol sisi server memutuskan apakah request yang dihasilkan memiliki otorisasi.

Referensi: Cookies: HTTP State Management Mechanism — draf RFC 6265bis