Bisakah subdomain.example.com menetapkan cookie yang dapat dibaca oleh example.com?

Saya benar-benar tidak percaya ini sangat sulit untuk ditentukan.

Bahkan setelah membaca RFC, tidak jelas bagi saya jika server di subdomain.example.com dapat mengatur cookie yang dapat dibaca oleh example.com.

subdomain.example.com dapat menetapkan cookie yang atribut Domain-nya adalah .example.com. RFC 2965 tampaknya secara eksplisit menyatakan bahwa cookie semacam itu tidak akan dikirim ke example.com, tetapi kemudian sama-sama mengatakan bahwa jika Anda menetapkan Domain = example.com, sebuah titik didahului, seolah-olah Anda mengatakan .example.com. Secara keseluruhan, ini sepertinya mengatakan bahwa jika pengembalian example.com menetapkan cookie dengan Domain = example.com, itu tidak mendapatkan cookie itu kembali! Itu tidak benar.

Adakah yang bisa menjelaskan apa aturan sebenarnya?

Mengutip dari RFC2109 yang sama dengan yang Anda baca:

       * Cookie Set dari host-permintaan x.foo.com untuk Domain = .foo.com akan
         diterima.

Jadi subdomain.example.comdapat mengatur cookie untuk .example.com. Sejauh ini baik.

       Aturan berikut ini berlaku untuk memilih nilai cookie yang berlaku dari
       di antara semua cookie yang dimiliki agen pengguna.

       Pemilihan Domain
            Nama host yang sepenuhnya memenuhi syarat server asal harus cocok dengan domain
            atribut Domain dari cookie

Jadi, apakah kita memiliki pencocokan domain?

   * A adalah string FQDN dan memiliki bentuk NB, di mana N adalah nama yang tidak kosong
     string, B memiliki bentuk .B ', dan B' adalah string FQDN. (Jadi, xycom
     cocok dengan domain .y.com tetapi tidak y.com.)

Tapi sekarang example.comtidak akan cocok dengan domain .example.comsesuai dengan definisi. Tetapi www.example.com(atau "nama tidak kosong" lainnya di domain) akan melakukannya. RFC ini secara teori sudah usang oleh RFC2965 , yang mendikte hal-hal tentang memaksa titik terkemuka untuk domain pada Set-Cookie2operasi.

Lebih penting, seperti dicatat oleh @Tony, adalah dunia nyata. Untuk melihat sekilas apa yang dilakukan agen pengguna aktual, lihat

Firefox 3 adalah nsCookieService.cpp

dan

Cookie_monster.cc Chrome

Untuk perspektif ke dalam apa situs yang sebenarnya lakukan, coba bermain dengan wgetmenggunakan --save-cookies, --load-cookiesdan --debuguntuk melihat apa yang terjadi.

Anda mungkin akan menemukan bahwa sebenarnya sebagian besar situs menggunakan beberapa kombinasi dari Set-Cookiespesifikasi RFC yang lebih lama dengan nilai "Host", secara implisit tanpa titik terkemuka (seperti yang dilakukan twitter.com ) atau pengaturan nilai Domain (dengan titik terkemuka) dan mengarahkan ulang ke server seperti www.example.com(seperti yang dilakukan google.com ).

Jika peramban mengimplementasikan RFC 6265 , yang harus dilakukan peramban modern mana pun pada saat ini, maka kuki yang ditetapkan untuk .example.comtitik utama akan diabaikan (bagian 5.2.3), dan kuki kemudian akan dikirim ke domain telanjang dan ke semua subdomain.

Jangan mengandalkan perilaku ini jika Anda memiliki lalu lintas yang signifikan dari browser lama; RFC ini baru berlaku untuk 2011.

Seharusnya tidak mungkin. Namun, seperti yang Anda katakan, karena ini bukan standar yang banyak didokumentasikan, itu tergantung pada perangkat lunak apa yang Anda gunakan.

Sebagian besar browser modern mematuhi "model keamanan web" yang ditentukan. Model ini secara efektif mengatur perilaku browser sehubungan dengan keamanan, pada hal-hal seperti cookie (khususnya bagaimana mereka akan dikirim kembali ke situs web mana pun yang diberikan). Model ini juga memiliki aturan bahwa "browser tidak mengirim cookie ke nama domain yang tidak menyetelnya."

Karena itu, domain.com harus dapat mengatur cookie untuk js.domain.com. js.domain.com, bagaimanapun, hanya dapat mengatur cookie untuk dirinya sendiri. Tapi ini semua tergantung pada browser apa yang Anda gunakan.