Atur cookie untuk javascript domain yang berbeda

4 Protokol

4. 1 Pertukaran data

Saat browser membuat permintaan yang diprakarsai pengguna ke server Web, mungkin ada beberapa cookie XDC untuk dikirim ke server yang tunduk pada otorisasi XDC server. Browser mungkin memiliki beberapa, semua, atau tidak ada otorisasi yang diberikan ke server (atau domain DNS induknya). Proposal kami menyediakan tiga mekanisme untuk menemukan semua otorisasi yang berlaku

• Kirim permintaan preflight ke server

• Kirim permintaan pengguna, izinkan server untuk memberikan otorisasi yang hilang, lalu kirim ulang permintaan lagi

• Lakukan pencarian DNS

Kami mengeluarkan permintaan preflight untuk semua permintaan pengguna yang menggunakan metode HTTP POST dan PUT. Tidak melakukannya dapat mengakibatkan server mengaktifkan mekanisme penemuan kedua yang, pada gilirannya, dapat menyebabkan pengiriman ulang sejumlah besar data dalam permintaan. Informasi preflight yang diterima dari server di-cache (untuk durasi yang ditunjukkan oleh server), jadi tidak semua permintaan pengguna memerlukan otorisasi preflight; . Informasi prapenerbangan dapat mencakup sertifikat saluran XDC dan otorisasi XDC serta waktu aktif untuk informasi dan opsi tambahan. Satu-satunya opsi yang saat ini ditentukan adalah tanda yang menunjukkan apakah browser harus menggunakan DNS untuk mencari otorisasi tambahan untuk server (atau domain DNS induknya) dan, jika demikian, seberapa sering

Saat server menerima permintaan pengguna sebenarnya, ia mungkin menemukan bahwa beberapa cookie XDC yang diharapkannya belum disertakan oleh browser. ethernet browser tidak memiliki cookie sama sekali, atau memiliki cookie tetapi tidak memiliki otorisasi untuk server. Untuk memperhitungkan kasus terakhir, server dapat merespons dengan otorisasi yang hilang, dan meminta browser untuk mengulangi permintaan tersebut, sekarang dengan cookie yang hilang (mungkin, dicakup oleh otorisasi yang baru ditemukan)

Browser yang menerima cookie XDC dari server dapat menggunakan semua otorisasi yang sebelumnya di-cache atau otorisasi yang dikirimkan server dengan cookie itu sendiri. Karena server selalu dapat menggabungkan cookie dan otorisasi dalam satu respons, tidak diperlukan perjalanan bolak-balik tambahan untuk menyelesaikan penemuan

Sumber terakhir otorisasi XDC untuk situs Web adalah DNS. Untuk mendukung pengiriman out-of-band, kami mengusulkan untuk menempatkan otorisasi XDC di catatan sumber daya TXT (RR) di DNS [], yang disandikan untuk menghormati aturan DNS. Karena catatan sumber daya TXT dapat digunakan oleh banyak aplikasi, terdapat risiko bahwa catatan yang diterima oleh browser bukan merupakan otorisasi XDC. Dalam implementasi kami, klien hanya membuang RR jika tidak dapat menafsirkannya dengan benar;

Pencarian DNS dilakukan saat mengirim saat browser menemukan cookie XDC yang belum terselesaikan di "jar" cookie, dan saat menerima saat server mengirim cookie XDC yang tidak dapat diselesaikan dengan cara lain (cache atau otorisasi XDC in-band). DNS tidak dikonsultasikan kecuali server menunjukkannya sebagai tanggapannya terhadap permintaan preflight

4. 2 permintaan sebelum penerbangan

Permintaan preflight adalah permintaan HTTP; . Permintaan preflight dikeluarkan untuk URL yang sama dengan permintaan pengguna asli. Server yang sesuai dapat mengembalikan nol atau lebih Xdc-Info-Request to true. A preflight request is issued for the same URL as the original user request. A compliant server may return zero or more Xdc-Channel dan Xdc-Authorization headers. It may also include the Xdc-Max-Age yang menunjukkan waktu retensi maksimum informasi yang diberikan dalam respons. (Jika tidak ada yang diberikan, default protokol akan digunakan. ) Terakhir, header Xdc-Options dapat menyertakan instruksi pemrosesan XDC tambahan; . Contoh permintaan preflight ditunjukkan pada Gambar. dns-max-age option is defined; if set, it instructs the browser to look up missing XDC authorizations in the DNS and defines the maximum frequency of such lookups. A sample preflight request is shown in Figure .

Gambar 2

Permintaan pra-penerbangan. >> menandai tajuk yang dikirim ke server, <, tajuk diterima darinya

Gambar ukuran penuh

4. 3 Mengatur cookie lintas domain

Gambar menunjukkan diagram urutan untuk server pengaturan cookie XDC. Server menggunakan Xdc-Authorization (dan mungkin Xdc-Channel . Nilai header adalah otorisasi XDC yang disandikan. Kami menggunakan penyandian ganda. pertama nilainya dikodekan basis 64 dan kemudian dikodekan URL. Untuk menyetel cookie lintas domain, server kami menggunakan header Xdc-Set-Cookie yang baru. Biasanya, klien akan menghapus cookie yang gagal diberikan otorisasi oleh server. Namun, dalam model kami, klien dapat menghubungi DNS untuk mengambil otorisasi yang hilang. Semua otorisasi XDC di tangan, klien memvalidasi cookie dan menyimpannya di "jar" cookie.

Gambar 3

Diagram urutan untuk pengaturan cookie XDC. Browser mengirimkan permintaan pengguna dan menerima respons yang mungkin berisi cookie dan otorisasi XDC. Jika salah satu cookie XDC tidak memiliki otorisasi yang cocok, pencarian DNS dilakukan

Gambar ukuran penuh

4. 4 Membaca cookie lintas domain

Diagram urutan untuk skenario pembacaan cookie XDC ditunjukkan pada Gambar. Sebelum mengirim cookie XDC ke server, klien Web harus menemukan semua otorisasi yang hilang. Ini menghubungi DNS dan meminta catatan sumber daya TXT untuk host server Web. Setelah menerima dan memvalidasi otorisasi, mengirimkan cookie XDC yang sesuai ke server menggunakan header Xdc-Cookie yang baru. Seperti yang kami sebutkan, server mungkin mengharapkan cookie XDC tambahan yang tidak diterimanya dengan permintaan tersebut. Server Web kami mungkin merespons dengan header Xdc-Authorization yang hilang dan menyetel kode status HTTP ke XDC_RESPONSE_REQUESTED, a value we introduced. This status code tells the browser that the sole purpose of the HTTP response is to provide the necessary XDC authorizations and that the browser must repeat the request including all valid XDC cookies. Since now two requests are treated as a single request, the server needs to remember that it already provided all XDC authorizations it has. To avoid the need to store the state of this two-step request on the server we propose a new header, Xdc-Response dengan nilai true and false. When a client repeats a request in response to the XDC_RESPONSE_REQUESTED , klien menyetel header ini ke true and includes it in the request. Not sending the header is equivalent to sending Xdc-Response. salah . Klien mengulangi operasi dengan mengevaluasi semua cookie XDC yang dipegangnya terhadap kumpulan otorisasi XDC yang diperbarui untuk host target.

Gambar 4

Diagram urutan untuk membaca cookie XDC. Sebelum mengirim permintaan pengguna, browser mencari otorisasi yang hilang (jika ada) di DNS. Kemudian permintaan dikirim bersama dengan cookie XDC. Server dapat memberikan otorisasi tambahan untuk menerima cookie XDC yang diharapkan tetapi tidak diterima (langkah 4). Setelah menerima respons XDC pada langkah 5, server merespons dengan data. Langkah 4 dan 5 tidak diperlukan untuk permintaan pengguna yang memerlukan otorisasi preflight

Gambar ukuran penuh

Gambar menunjukkan jejak permintaan tunggal ke server pembaca cookie XDC. Awalnya browser tidak memiliki otorisasi apa pun untuk host baca. xdc. com . Server merespons dengan empat otorisasi dan menyetel kode status HTTP ke XDC_RESPONSE_REQUESTED (399). Browser mengulangi permintaan menyetel header Xdc-Response ke true dan . Ada enam cookie yang valid untuk host yang tersebar di tiga saluran lintas domain.

Gambar 5

Permintaan HTTP yang menyampaikan cookie XDC ke server. >> menandai tajuk yang dikirim ke server, <, tajuk diterima darinya

Gambar ukuran penuh

4. 5 Ringkasan perubahan pada protokol HTTP

Di bagian ini kami meringkas semua tambahan pada protokol HTTP yang diperlukan untuk mendukung cookie lintas domain kami. Tabel mencantumkan tajuk HTTP yang kami usulkan. Tabel mencantumkan satu kode status HTTP yang baru diusulkan

Tabel 2 header HTTP

Tabel ukuran penuh

Tabel 3 Kode status HTTP

Tabel ukuran penuh

5 Bukti konsep

Bukti konsep kami terdiri dari beberapa komponen

• Utilitas untuk menghasilkan sertifikat saluran, menandatangani otorisasi XDC, dan menyimpannya dalam format yang berbeda

• Aplikasi pembaca cookie XDC

• Aplikasi penulisan cookie XDC

• Server HTTP yang mampu melayani permintaan preflight XDC

• Server DNS yang dikonfigurasi dengan otorisasi XDC

• Klien berkemampuan XDC

Utilitas dan aplikasi ditulis dalam Java. Kami menggunakan API kriptografi Bouncy Castle [] untuk semua pekerjaan dengan X. 509 atribut dan sertifikat kunci publik. Untuk menghosting aplikasi, kami menggunakan Apache Tomcat []. Kami mengaktifkan dukungan sisi server untuk otorisasi preflight dengan mengonfigurasi proxy HTTP Apache kami dengan dua modul, mod_rewrite [] dan mod_headers []. Konfigurasi mod_rewrite menyetel variabel lingkungan pada permintaan HTTP OPTIONS yang berisi header Xdc-Info-Request. benar ; . Server DNS menghosting otorisasi XDC. Kami menggunakan BIND 9. 7. 0 []. Klien berkemampuan XDC kami diimplementasikan sebagai ekstensi browser Firefox. Firefox menyediakan kerangka kerja pluggable untuk memperluas fungsionalitasnya, dan model objek komponen lintas platform, yang disebut XPCOM, untuk memprogram ekstensi []. Beberapa binding bahasa didukung untuk XPCOM; . Semua kode sumber dan petunjuk konfigurasi untuk bukti konsep kami tersedia dari [].

6 Evaluasi

Proposal kami menambahkan overhead komunikasi ke interaksi normal browser/server Web. Situs web yang tidak mengetahui cookie lintas domain kami akan dikenakan biaya minimal. permintaan preflight awal akan gagal atau tidak mengembalikan informasi, dan default protokol (beberapa hari) akan menentukan frekuensi permintaan berikutnya; . Overhead yang diberlakukan oleh situs Web yang sadar XDC akan bergantung pada

• Frekuensi permintaan preflight

• Frekuensi pencarian DNS

• Frekuensi permintaan berulang

• Jumlah saluran yang berinteraksi dengan situs (mis. e. , membaca atau menulis cookie XDC)

• Ukuran sertifikat saluran XDC individu dan otorisasi XDC

• Jumlah dan ukuran cookie XDC yang disetel dan diterima

Situs web dapat mengontrol frekuensi permintaan preflight dengan menyetel header Xdc-Max-Age , dan frekuensi pencarian DNS dengan menyetel . 2). Kedua pengaturan tunduk pada analisis tradeoff (jumlah permintaan yang tidak perlu yang tidak menemukan informasi baru terhadap latensi menemukan perubahan) tetapi dalam kebanyakan kasus mereka dapat diatur ke hari, minggu, dan bahkan bulan. Xdc-Options (Section 4.2). Both settings are subject to tradeoff analysis (the number of unnecessary requests that discover no new information against the latency of discovering a change) but in most cases they can be set to days, weeks and even months.

Itu dapat ditarik kembali dari Bagian 4. 4 bahwa server Web dapat memulai permintaan berulang hanya ketika cookie XDC yang mereka harapkan akan diterima tidak disediakan oleh browser. Kami berharap setelah beberapa komunikasi awal browser akan memiliki semua otorisasi untuk server Web tertentu, dan pertukaran tambahan tidak diperlukan. Server web yang melayani klien bandwidth rendah dapat memilih untuk menyimpan semua otorisasi XDC mereka di DNS;

Analisis oleh Tappenden dan Miller [] menunjukkan bahwa rata-rata jumlah cookie yang digunakan oleh situs Web adalah 2. 92, dan angka mediannya adalah 1. 0; . Ini menunjukkan bahwa jumlah cookie lintas-domain yang digunakan oleh situs Web tipikal harus kecil, dan jumlah saluran yang terkait dengannya, bahkan lebih kecil. Sekitar 278 kB data ditransfer dalam sesi aplikasi Web rata-rata []. Dalam prototipe kami, otorisasi XDC yang disandikan penuh bervariasi antara 1.108 dan 1.440 karakter ASCII untuk kunci RSA 1024-bit f. Bahkan jika otorisasi preflight tidak digunakan, hanya sejumlah kecil data yang akan ditambahkan ke setiap sesi

Header kami Xdc-Cookie dan Xdc-Set-Cookie have the same basic structure as the corresponding headers for traditional cookies. As we explained in Table the traditional headers can even be overloaded to support XDC functionality. Assuming that the payload size and the number of cross-domain cookies and of traditional cookies will not significantly differ, any additional overhead may come only from the XDC Name attribute. Based on the length of a raw XDC name (160 bits for SHA-1-generated names) and the fact that we use double encoding (base 64 and URL), it can be shown that the average length of an encoded XDC name is 31.6 characters. (In the interest of brevity we omit the calculation.) Comparing Xdc-Set-Cookie dengan Set-Cookie (yang mungkin . 6 karakter per cookie. Xdc-Cookie and Cookie (which may not), we get the worst case average difference of 31.6 characters per cookie.

7 Diskusi

7. 1. Umum

Skema yang diusulkan memiliki beberapa sifat penting. Pertama, ini memungkinkan kita untuk menghasilkan nama saluran yang unik dengan kemungkinan tabrakan yang dapat diabaikan. Kedua, otorisasi XDC menyediakan mekanisme kontrol akses sederhana yang kira-kira setara dengan yang saat ini digunakan di Web berdasarkan aturan pencocokan domain dan kebijakan asal yang sama. Memang, klien Web tradisional melihat atribut Domain dalam cookie dan memutuskan apakah nama host server Web yang berkomunikasi cocok dengannya; . Dalam kasus kami, pencocokan nama host didasarkan pada perbandingan langsung dari nama host seperti yang dilaporkan oleh DNS dan nama host di otorisasi XDC. Ketiga, otorisasi XDC tidak dapat dimaafkan (dengan teknologi saat ini); . hanya pemilik, pemilik kunci privat, yang dapat menandatangani otorisasi. Pengikatan antara kunci publik pemilik dan nama saluran bergantung pada properti resistensi tabrakan dari fungsi hash yang digunakan untuk menghitung nama saluran. Dalam percobaan kami, kami menggunakan algoritma SHA-1 []

7. 2 Model kepercayaan untuk otorisasi

Seperti yang dibahas di Bagian 3, skema kami tidak mendukung pencabutan otorisasi. Setelah diberikan, otorisasi XDC tetap berlaku hingga kedaluwarsa, dan tidak dapat ditarik kembali. Selain itu, jika kunci pribadi pemilik XDC dikompromikan, tidak ada mekanisme perbaikan untuk bermigrasi ke penggunaan kunci baru (dan XDC baru). Kami berpendapat bahwa risiko ini dapat diterima. Jika kuncinya dikompromikan, pemilik dapat membuat pasangan kunci baru sehingga membuat XDC baru, mengeluarkan otorisasi XDC baru, dan mendistribusikannya ke semua server Web out-of-band yang berpartisipasi. Server yang membaca cookie XDC dapat langsung berhenti menerima cookie lama meskipun browser terus menyimpannya (dan otorisasi XDC lama) hingga kedaluwarsa. Karena bukti anekdotal menunjukkan bahwa pencabutan sertifikat SSL karena kompromi kunci sangat jarang terjadi, kami berharap pencabutan kunci XDC juga akan jarang terjadi. Membangun infrastruktur yang kompleks untuk kejadian langka seperti itu, menurut pandangan kami, tidak dibenarkan

Penggunaan infrastruktur kunci publik kami dalam otorisasi XDC agak tidak konvensional. Pemilik saluran lintas domain bertindak sebagai otoritas sertifikasi khusus aplikasi (CA) sedangkan dalam keadaan normal CA tidak bergantung pada aplikasi, meskipun CA dapat menerbitkan sertifikat entitas akhir yang sesuai untuk aplikasi tertentu. Menggunakan pendekatan tradisional akan membuat cookie kami kurang ringan karena (a) lebih banyak informasi perlu dibawa dalam otorisasi XDC dan (b) infrastruktur kepercayaan lainnyag harus digunakan untuk memvalidasi sertifikat khusus aplikasi yang dikeluarkan untuk pemilik XDC. Karena itu, infrastruktur kepercayaan kami berdiri sendiri dan tidak memiliki ketergantungan eksternal

7. 3 Model ancaman

Cookie dapat dilihat sebagai elemen data pasif yang berinteraksi dengan aktor berikut. Situs web, jaringan, browser, dan pengguna. Cookie tradisional dibuat berdasarkan model ancaman yang berpusat pada pengguna. Kebijakan asal yang sama mengasumsikan bahwa pengguna adalah pemilik akhir dari sebuah cookie. Jika browser dan jaringan jujur, itu melindungi dari server Web yang tidak jujur ​​(atau ingin tahu) yang mungkin ingin mendapatkan akses tidak sah ke cookie. Cookie lintas domain yang kami usulkan menggunakan model ancaman dasar yang sama. Selain itu, saluran XDC yang aman mempromosikan pertukaran cookie XDC yang aman dan rahasia, mengurangi serangan spoofing DNS, dan memberikan lapisan perlindungan ekstra terhadap peniruan identitas situs Web

7. 4 Kontrol dan privasi pengguna

Pada akhirnya, pengguna harus mengendalikan pembagian cookie yang dilakukan oleh browsernya. Atribut komentar di cookie XDC dan otorisasi XDC akan membantunya dalam membuat keputusan yang tepat tentangnya

Selain itu, kerangka perlindungan pelacakan ('Jangan Lacak', atau DNT) yang hampir selesai di World Wide Web Consortium [] dapat diadaptasi untuk mencakup cookie XDC juga. Kerangka kerja DNT menentukan hak pengguna terkait pelacakan oleh situs Web, praktik yang diperlukan dari mereka untuk mematuhi preferensi pengguna, dan sarana teknis untuk mengekspresikan preferensi ini dan kepatuhan terhadapnya. Kami percaya bahwa cookie lintas domain yang diusulkan dalam makalah ini tidak menimbulkan kekhawatiran baru yang belum ada untuk cookie pihak pertama dan pihak ketiga tradisional. Sejauh kerangka kerja DNT mengatasi masalah tersebut, kerangka kerja DNT juga harus menanganinya untuk cookie XDC. Aturan kepatuhan khusus dan mekanisme teknis perlu dimodifikasi untuk memasukkan cakupan baru, yaitu saluran XDC. (Saat ini, kerangka kerja DNT hanya mempertimbangkan situs dan sumber daya di dalam situs tersebut)

Bahkan kuki tradisional tetap menjadi misteri bagi banyak pengguna akhir, tetapi setidaknya kuki tersebut berisi atribut Domain yang menunjukkan ruang lingkup dan penerapan kuki. Nama cookie XDC, di sisi lain, adalah intisari kunci publik, dan tidak mengandung informasi apa pun yang dapat dikenali oleh pengguna. Untuk mengurangi hal ini, kami menyarankan agar browser memelihara log yang sedang berjalan dari penggunaan terbaru semua cookie XDC persisten yang merekam nama saluran, nama host server Web yang membaca atau menulis cookie, tanggal dan waktu akses terakhirnya, jenis akses . Log ini dapat digunakan oleh administrator dan pengguna tingkat lanjut untuk menganalisis pola akses XDC dan memodifikasi aturan penerimaan cookie browser mereka jika diperlukan

7. 5 Kesesuaian dengan infrastruktur yang ada

Meskipun semua fungsionalitas yang tersedia melalui cookie tradisional dapat diimplementasikan dengan cookie XDC, kami tidak mengusulkan untuk menghapusnya secara bertahap, bahkan dalam jangka panjang. Kue tradisional menikmati penerimaan luas dan hampir tidak memiliki biaya operasional dan komunikasi. Kedua jenis cookie harus dapat hidup berdampingan dalam protokol yang sama. Browser web harus memperlakukan cookie ini sebagai benar-benar terpisah. cookie tradisional bernama X dan cookie XDC bernama X mewakili data yang tidak terkait meskipun diterima dari (atau perlu dikirim ke) server yang sama. Pemisahan yang bersih seperti itu membuat cookie XDC lebih mudah diterapkan, dan harus memudahkan adopsi mereka oleh produsen browser

Proposal kami membuat perubahan pada protokol HTTP. Setiap perubahan pada HTTP harus berinteroperasi dengan infrastruktur Web yang ada. Kita perlu mengevaluasi bagaimana aktor yang sadar XDC (mis. e. , server, klien, dan proxy) berinteraksi dengan mereka yang tidak mengetahui XDC. Tiga kasus penggunaan dapat dipertimbangkan

• Klien sadar XDC/server tidak sadar. Ini adalah kasus paling sederhana. browser dapat mengeluarkan permintaan preflight XDC, mereka akan gagal atau tidak mengembalikan informasi. Server akan mengabaikan semua cookie XDC yang dikirim oleh browser (jika berhasil menemukan otorisasi XDC untuk server dengan cara lain)

• Server yang sadar XDC/klien tidak sadar. Aplikasi server harus dikodekan secara defensif dan memiliki implementasi cadangan yang tidak bergantung pada cookie XDC. Server dapat menguji klien dengan mengirimkan kode status XDC_RESPONSE_REQUESTED dan memeriksa apakah menerima permintaan berulang dengan Xdc . header set to true.

• XDC-proksi yang tidak diketahui. Karena otorisasi preflight menggunakan metode OPTIONS (Bagian 4. 2), dan respons terhadap permintaan OPSI tidak dapat di-cache [], proksi yang tidak menyadari XDC tidak boleh mengganggu bagian solusi kami ini. XDC_RESPONSE_REQUESTED respons yang memulai permintaan berulang harus menyetel header Cache-Control ke . Untuk mencegah caching respons header khusus XDC terhadap permintaan pengguna, Anda harus mengatur header no-cache to prevent their caching by any proxies. To forestall caching of XDC-specific headers responses to user requests must set the Cache-Control ke no-cache . [].

8 Kesimpulan

Cookie menyediakan mekanisme manajemen status sederhana untuk HTTP. Seperti yang diterapkan saat ini, mereka hanya dapat dibagikan di antara host di domain DNS yang sama (dengan beberapa batasan). Namun, dalam banyak kasus, ini terlalu membatasi, dan kemampuan untuk berbagi cookie di seluruh domain mungkin diperlukan. Meskipun ada sarana teknis untuk mengatasi keterbatasan saat ini, namun sulit diterapkan, mahal, dan terkadang tidak aman. Sebaliknya, kebijakan asal yang sama yang saat ini digunakan di Web mungkin terlalu permisif dalam beberapa kasus;

Dalam makalah ini kami memperkenalkan model otorisasi sederhana untuk berbagi cookie antara domain DNS yang berbeda. Cookie semacam itu ditulis atau dibaca dari saluran lintas domain (XDC). Baik penulis maupun pembaca diberikan otorisasi XDC yang memberikan izin yang sesuai kepada pemegangnya dan mengikat izin ini secara kriptografis ke pemilik saluran XDC. Otorisasi XDC dapat dikirimkan dalam aliran HTTP yang membawa cookie XDC itu sendiri, atau dicari di DNS. Pengikatan otorisasi XDC ke host yang menyajikannya bergantung pada kepercayaan proses resolusi nama dan, oleh karena itu, mungkin rentan terhadap pharming dan serangan lain terhadap DNS. Saluran XDC yang aman memungkinkan pemiliknya untuk menunjukkan bahwa cookie hanya dapat dibagikan di seluruh koneksi SSL;

Mirip dengan CORS, mekanisme Cross-Origin Resource Sharing yang diterapkan di banyak browser [], solusi kami menggunakan otorisasi preflight yang dapat di-cache klien yang seharusnya meminimalkan permintaan berulang dan overhead komunikasi terkait XDC lainnya. Permintaan Preflight memberikan browser dengan otorisasi XDC situs Web, dan juga memberikan instruksi tambahan tentang penanganan cookie XDC (seperti frekuensi pencarian DNS). Karena situs Web mana pun diharapkan menggunakan hanya sejumlah kecil saluran lintas domain, otorisasi XDC cukup kecil (sekitar 1. 5 K), dan cookie XDC sendiri hanya sedikit lebih besar dari cookie tradisional, solusi keseluruhannya ringan. Dengan biaya rendah, solusi kami menyediakan mekanisme sederhana dan aman untuk berbagi cookie lintas domain di Web

Catatan akhir

aStandar pengelolaan status HTTP lain baru-baru ini diusulkan (RFC 6265) []. Itu usang RFC 2965 dan menambah RFC 2109. bDalam makalah ini kami tidak mempertimbangkan alamat IP yang digunakan dalam URL HTTP (dan atribut Domain cookie). Penggunaan langsung mereka umumnya tidak dianjurkan []. cRFC 2965 juga mendefinisikan header baru, Set-Cookie2 []. Perbedaan dengan tajuk lama sedikit, dan kami tidak akan membahasnya lebih lanjut. dPerhatikan bahwa, seperti CORS, kami membuat permintaan preflight untuk mengumpulkan informasi otorisasi sebelum memenuhi permintaan pengguna. catatan sumber daya eDNS digunakan untuk menyimpan teks arbitrer []fA versi terbaru dari prototipe kami dapat menghasilkan otorisasi XDC menggunakan algoritme ECDSA. Dengan kurva eliptik 192-bit, yang memberikan keamanan yang sebanding dengan kunci RSA 1024-bit [], otorisasi yang dikodekan penuh lebih pendek sekitar 200 byte. Misalnya, yang digunakan oleh implementasi SSL/TLS browser.

Referensi

1. Kristol DM. Cookie HTTP. Standar, privasi, dan politik. ACM Trans Internet Technol 2001, 1(2). 151–198. 10. 1145/502152. 502153

   Artikel  Google Cendekia

2. Kristol D, Montulli L. Mekanisme Manajemen Status HTTP. 1997. IETF, RFC 2109

   Bab  Google Cendekia

3. Kristol D, Montulli L. Mekanisme manajemen status HTTP. 2000. IETF, RFC 2965

   Bab  Google Cendekia

4. Hanya HTTP. Buka Proyek Keamanan Aplikasi Web (OWASP). 2007

   beasiswa Google

5. Kelompok Kerja Perlindungan Pelacakan ( ). Konsorsium W3 (2012) http. // www. w3. org/2011/tracking-protection/ (). Konsorsium W3 (2012)

6. Zalewski M. Buku panduan keamanan browser. Google, Inc. 2009

   beasiswa Google

7. Persistent Client State HTTP Cookies Perusahaan komunikasi Netscape (tidak bertanggal) Perusahaan komunikasi Netscape (tidak bertanggal)

8. Bagaimana Bisnis Menggunakan Web 2. 0. Survei global McKinsey McKinsey and Company (2007)

9. O'Reilly T. Apa itu Web2. 0. Pola desain dan model bisnis untuk perangkat lunak generasi berikutnya. Jaringan O'Reilly 2005

   beasiswa Google

10. Phifer G. Hype cycle untuk web dan teknologi interaksi pengguna. Gartner, Inc;

    beasiswa Google

11. Profil untuk OASIS Security Assertion Markup Language (SAML) V2. 0. 2005

12. Protokol dan profil layanan penemuan penyedia identitas. 2008

13. Jang D, Venkataraman A, Sawka GM, Shacham H. Menganalisis kebijakan lintas domain aplikasi flash. Di dalam. Proses. dari Web 2. 0 Lokakarya Keamanan dan Privasi 2011

    beasiswa Google

14. Kontaxis G, Antoniades D, Polakis I, Markatos EP. Studi empiris tentang keamanan kebijakan lintas domain dalam aplikasi internet yang kaya. Di dalam. Proses. Lokakarya Eropa ke-4 tentang Keamanan Sistem 2011

    beasiswa Google

15. Pettersen Y. Mekanisme manajemen status HTTP v2. IETF. 2008. Draf Internet draf-pettersen-cookie-v2-05

    beasiswa Google

16. Callaghan PJ, Howland MJ, Pritko SM. Produk metode, sistem, dan program untuk berbagi informasi status di seluruh Domain. AS. S. Kantor Paten dan Merek Dagang. 2008. Publikasi Permohonan Paten US 2008/0027824 A1

    beasiswa Google

17. Guo R, Zhou B. kue silang. Protokol cookie untuk mashup web. Di dalam. Proses. Simposium Internasional 2008 tentang Perdagangan dan Keamanan Elektronik 2008, 416–420

    Bab  Google Cendekia

18. Penyimpanan Web. 2011. Konsorsium W3, Rekomendasi Calon W3C 12/08/2011 Konsorsium W3, Rekomendasi Calon W3C 12/08/2011

19. Pesan Web HTML5. 2011. Konsorsium W3, Rancangan Kerja W3C 20/10/2011 Konsorsium W3, Rancangan Kerja W3C 20/10/2011

20. jendela. postMessage ( ). Jaringan Pengembang Mozilla (2012) https. // pengembang. mozilla. org/en-US/docs/DOM/window. jendela postMessage. postMessage (). Jaringan Pengembang Mozilla (2012)

21. Hanna S, Shin R, Akhawe D, Boehm A, Saxena P, Song D. API Baru Kaisar. Pada (Dalam) penggunaan aman dari primitif sisi klien baru. Di dalam. Proses. Web ke-4 2. 0 Lokakarya Keamanan dan Privasi 2010

    beasiswa Google

22. Berbagi sumber daya lintas sumber. 2010. World Wide Web Consortium, W3C Working Draft 27/07/2010 World Wide Web Consortium, W3C Working Draft 27/07/2010

23. Zakas N. Ajax lintas domain dengan berbagi sumber daya lintas asal. 2010. NCZOnline, 2010

    beasiswa Google

24. Farrell S, Housley R. Profil sertifikat atribut internet untuk otorisasi. 2002. IETF, RFC 3281

    Bab  Google Cendekia

25. Karlof CK, Shankar U, Tygar D, Wagner D. Cookie terkunci. Keamanan autentikasi web terhadap Phishing, Pharming, dan serangan aktif. 2007. Universitas California di Berkeley, Laporan Teknis UCB/EECS-2007-25

    beasiswa Google

26. Teknologi Informasi - Interkoneksi Sistem Terbuka - Direktori. Kerangka Otentikasi Rekomendasi ITU-T X. 509 (1997) Rekomendasi ITU-T X. 509 (1997)

27. Cooper D, Santesson S, Farrell S, Boeyen S, Housley R, Polk W. Internet X. 509 sertifikat infrastruktur kunci publik dan profil Daftar Pencabutan Sertifikat (CRL). 2008. IETF, RFC 5280

    Bab  Google Cendekia

28. Mockapetris P. Nama domain – Implementasi dan spesifikasi. 1987. IETF, RFC 1035

    Bab  Google Cendekia

29. Eastlake DE. Catatan resource DNS kitchen sink. 1999. IETF, Draf Internet draf-ietf-dnsind-kitchen-sink-02

    beasiswa Google

30. Legiun Istana Goyang. Selamat datang ( ) Legiun Istana Goyang (2011) http. // www. bouncycastle. org/java. html Legiun Istana Goyang (2011)

31. Apache Tomcat, Yayasan Perangkat Lunak Apache (2011) http. //kucing jantan. apache. org/Yayasan Perangkat Lunak Apache (2011)

32. Modul Apache mod_rewrite Yayasan Perangkat Lunak Apache (2011) http. // httpd. apache. org/docs/current/mod/mod_rewrite. html Yayasan Perangkat Lunak Apache (2011)

33. Modul Apache mod_headers Yayasan Perangkat Lunak Apache (2011) http. // httpd. apache. org/docs/current/mod/mod_headers. html Yayasan Perangkat Lunak Apache (2011)

34. Server Nama ISC BIND - Petunjuk, Tautan, Buku Putih ( ). BIND9. NET/BIND9. ORG (2010) http. // www. ikat9. bersih/ (). BIND9. NET/BIND9. ORG (2010)

35. Ekstensi jaringan pengembang Mozilla (2011) https. // pengembang. mozilla. org/en/Extensions Jaringan pengembang Mozilla (2011)

36. Rabinovich P. Cookie lintas domain, 2011. https. // sourceforge. net/projects/xdccookies/ SourceForge. bersih

    beasiswa Google

37. Tappenden AF, Miller J. Kue. Sebuah studi penyebaran dan implikasi pengujian. ACM Trans Web 2009, 3(3). 1–49

    Artikel  Google Cendekia

38. Schneider F, Agarwal S, Alpcan T, Feldmann A. Jaring baru. mencirikan lalu lintas AJAX. Di dalam. Proses. Konferensi Internasional ke-9 tentang Pengukuran Jaringan Pasif dan Aktif 2008, 31–40

    Bab  Google Cendekia

39. Secure Hash Signature Publikasi FIPS Standar 180–2 (2002) Publikasi FIPS 180-2 (2002)

40. Fielding R, Gettys J, Mogul J, Frystyk H, Masinter L, Leach P, Berners-Lee T 1999. Protokol Transfer Hiperteks – HTTP/1. 1. IETF, RFC 2616

41. Barth A. Mekanisme manajemen status HTTP. 2011. IETF, RFC 6265

    Bab  Google Cendekia

42. Panduan untuk membangun aplikasi web dan layanan web yang aman Open Web Application Security Project (OWASP) (2005) Open Web Application Security Project (OWASP) (2005)

43. Rosenblum R. Menggunakan sistem nama domain untuk menyimpan atribut string arbitrer. 1987. IETF, RFC 1464

    beasiswa Google

44. Barker E, Barker W, Burr W, Polk W, Smid M. Rekomendasi untuk manajemen kunci – Bagian 1. Umum. Revisi Publikasi Khusus NIST 2012, 3. 800–857

    beasiswa Google

Unduh referensi

Informasi penulis

Penulis dan Afiliasi

1. Pengembangan Perangkat Lunak Keamanan, Exostar, Herndon, AS

   Paul Rabinovich

Penulis

1. Paul Rabinovich

   Lihat publikasi penulis

   Anda juga dapat menelusuri penulis ini di PubMed   Google Cendekia

Penulis yang sesuai

Korespondensi dengan Paul Rabinovich

Informasi tambahan

Kepentingan yang bersaing

Penulis menyatakan bahwa dia tidak memiliki kepentingan bersaing

File asli yang dikirimkan penulis untuk gambar

Di bawah ini adalah tautan ke file asli yang dikirimkan oleh penulis untuk gambar

File asli penulis untuk gambar 1

File asli penulis untuk gambar 2

File asli penulis untuk gambar 3

File asli penulis untuk gambar 4

File asli penulis untuk gambar 5

Hak dan izin

Akses Terbuka Artikel ini didistribusikan di bawah ketentuan Creative Commons Attribution 2. 0 Lisensi Internasional (https. //creativecommons. org/lisensi/oleh/2. 0), yang mengizinkan penggunaan, distribusi, dan reproduksi tanpa batas dalam media apa pun, asalkan karya aslinya dikutip dengan benar

Cetak ulang dan Izin

Tentang artikel ini

Kutip artikel ini

Rabinovich, P. Cookie lintas domain yang aman untuk HTTP. Aplikasi Layanan Internet J 4, 13 (2013). https. //doi. org/10. 1186/1869-0238-4-13

Bagaimana cara mengatur cookie untuk JavaScript domain lain?

Bisakah Anda menyetel cookie untuk domain lain?

Bagaimana cara mengatur cookie untuk beberapa domain?

Bisakah cookie digunakan untuk beberapa domain?