CORS - Apa motivasi di balik memperkenalkan permintaan preflight?


366

Berbagi sumber daya silang adalah mekanisme yang memungkinkan halaman web untuk membuat XMLHttpRequests ke domain lain (dari wikipedia ).

Saya telah mengutak-atik CORS selama beberapa hari terakhir dan saya pikir saya memiliki pemahaman yang cukup baik tentang bagaimana semuanya bekerja.

Jadi pertanyaan saya bukan tentang bagaimana CORS / preflight bekerja, ini tentang alasan di balik munculnya preflight sebagai tipe permintaan baru . Saya gagal melihat alasan mengapa server A perlu mengirim preflight (PR) ke server B hanya untuk mengetahui apakah permintaan nyata (RR) akan diterima atau tidak - tentu saja akan mungkin bagi B untuk menerima / menolak RR tanpa PR sebelumnya.

Setelah mencari sedikit saya menemukan sepotong informasi di www.w3.org (7.1.5):

Untuk melindungi sumber daya terhadap permintaan lintas-asal yang tidak dapat berasal dari agen pengguna tertentu sebelum spesifikasi ini ada, permintaan preflight dibuat untuk memastikan bahwa sumber daya mengetahui spesifikasi ini.

Saya menemukan ini adalah kalimat paling sulit untuk dipahami. Interpretasi saya (lebih baik menyebutnya 'tebakan terbaik') adalah tentang melindungi server B terhadap permintaan dari server C yang tidak mengetahui spesifikasi.

Bisakah seseorang menjelaskan skenario / menunjukkan masalah yang PR + RR memecahkan lebih baik daripada RR saja?

Jawaban:


323

Saya menghabiskan beberapa waktu bingung dengan tujuan permintaan preflight tapi saya pikir saya sudah mendapatkannya sekarang.

Wawasan utama adalah bahwa permintaan preflight bukanlah hal yang aman . Sebaliknya, mereka bukan hal yang mengubah aturan .

Permintaan Preflight tidak ada hubungannya dengan keamanan, dan tidak ada kaitannya dengan aplikasi yang sedang dikembangkan sekarang, dengan kesadaran CORS. Alih-alih, mekanisme preflight menguntungkan server yang dikembangkan tanpa kesadaran CORS, dan berfungsi sebagai pemeriksaan kewarasan antara klien dan server bahwa keduanya sadar CORS. Pengembang CORS merasa bahwa ada cukup banyak server di luar sana yang mengandalkan asumsi bahwa mereka tidak akan pernah menerima, misalnya permintaan lintas domain DELETE bahwa mereka menemukan mekanisme preflight untuk memungkinkan kedua belah pihak untuk ikut serta. Mereka merasa bahwa alternatif, yang seharusnya hanya mengaktifkan panggilan lintas domain, akan merusak terlalu banyak aplikasi yang ada.

Ada tiga skenario di sini:

  1. Server lama, tidak lagi dalam pengembangan, dan dikembangkan sebelum CORS. Server ini dapat membuat asumsi bahwa mereka tidak akan pernah menerima mis permintaan lintas domain DELETE. Skenario ini adalah penerima manfaat utama dari mekanisme preflight. Ya, layanan ini sudah dapat disalahgunakan oleh agen pengguna jahat atau tidak patuh (dan CORS tidak melakukan apa pun untuk mengubah ini), tetapi di dunia dengan CORS mekanisme preflight menyediakan 'pemeriksaan kewarasan' ekstra sehingga klien dan server tidak istirahat karena aturan yang mendasari web telah berubah.

  2. Server yang masih dalam pengembangan, tetapi yang mengandung banyak kode lama dan yang tidak layak / tidak diinginkan untuk mengaudit semua kode lama untuk memastikan itu berfungsi dengan baik di dunia lintas domain. Skenario ini memungkinkan server untuk secara progresif memilih ikut CORS, misalnya dengan mengatakan "Sekarang saya akan mengizinkan tajuk khusus ini", "Sekarang saya akan mengizinkan kata kerja HTTP khusus ini", "Sekarang saya akan mengizinkan cookie / informasi auth menjadi terkirim ", dll. Skenario ini mendapat manfaat dari mekanisme preflight.

  3. Server baru yang ditulis dengan kesadaran CORS. Menurut praktik keamanan standar, server harus melindungi sumber daya dalam menghadapi setiap permintaan yang masuk - server dapat klien tidak percaya untuk tidak melakukan hal-hal berbahaya. Skenario ini tidak mendapat manfaat dari mekanisme preflight : mekanisme preflight tidak membawa keamanan tambahan ke server yang telah melindungi sumber dayanya dengan benar.


12
Jika itu sebabnya mengapa dikirim pada setiap permintaan? Satu permintaan per server harus memadai untuk menentukan apakah server mengetahui CORS.
Douglas Ferguson

3
Spesifikasinya mencakup cache hasil-sebelumnya -peramban di browser. Jadi, sementara itu masih terasa keamanan yang kludgy dan tidak efektif, tampaknya mungkin untuk mengkonfigurasi server baru untuk memiliki cache preflight di-cache tanpa batas.
Michael Cole

7
Saya setuju bahwa permintaan preflight secara inheren tidak terkait dengan keamanan, tetapi sepertinya penggunaan permintaan preflight CORS jelas untuk alasan keamanan. Ini lebih dari sekadar pemeriksaan kewarasan untuk mencegah skenario kesalahan yang relatif tidak berbahaya. Jika agen pengguna secara buta mengirim permintaan ke server, dengan anggapan palsu server mengimplementasikan CORS, kemungkinan besar akan menerima pemalsuan permintaan lintas situs. Meskipun respons tidak dapat dibaca oleh javascript, server mungkin sudah mengambil tindakan yang tidak diinginkan seperti menghapus akun atau melakukan transfer bank.
Alexander Taylor

6
Masalahnya adalah, cache hasil-pre -light pada dasarnya tidak berguna karena 1. itu hanya berlaku untuk permintaan yang tepat, bukan seluruh domain, jadi semua permintaan akan melakukan preflight pertama kali; dan 2. seperti yang diterapkan, ini dibatasi hingga 10 menit di sebagian besar peramban, jadi bahkan hampir tidak terbatas.
davidgoli

2
@VikasBansal Server yang ada harus "memilih" dan setuju untuk membagikan sumber daya mereka di seluruh asal dengan mengkonfigurasi bagaimana mereka membalas permintaan opsi preflight. Jika mereka tidak menjawab permintaan preflight secara eksplisit, browser tidak akan mengeluarkan permintaan aktual. Tidak semua server mau menerima permintaan lintas-asal.
Kevin Lee

217

Apa motivasi di balik memperkenalkan permintaan preflight?

Permintaan Preflight diperkenalkan sehingga browser dapat yakin itu berurusan dengan server yang menyadari CORS sebelum mengirim permintaan tertentu. Permintaan tersebut didefinisikan sebagai permintaan yang berpotensi berbahaya (perubahan negara) dan baru (tidak mungkin dilakukan sebelum CORS karena Kebijakan Asal yang Sama ). Menggunakan permintaan preflight berarti bahwa server harus ikut serta (dengan merespons dengan baik pada preflight) untuk jenis permintaan baru yang berpotensi berbahaya yang dimungkinkan oleh CORS.

Itulah arti dari bagian spesifikasi ini : "Untuk melindungi sumber daya terhadap permintaan lintas-asal yang tidak dapat berasal dari agen pengguna tertentu sebelum spesifikasi ini ada, permintaan preflight dibuat untuk memastikan bahwa sumber daya mengetahui spesifikasi ini."

Bisakah Anda memberi saya contoh?

Mari kita bayangkan bahwa pengguna browser masuk ke situs perbankan mereka di A.com. Ketika mereka menavigasi ke malicious B.com, halaman itu menyertakan beberapa Javascript yang mencoba mengirim DELETEpermintaan A.com/account. Karena pengguna masuk ke A.com, permintaan itu, jika dikirim, akan termasuk cookie yang mengidentifikasi pengguna.

Sebelum CORS, Kebijakan Asal Sama browser akan memblokirnya dari mengirimkan permintaan ini. Tetapi karena tujuan CORS adalah untuk memungkinkan komunikasi lintas asal semacam ini menjadi mungkin, itu tidak lagi sesuai.

Peramban dapat dengan mudah mengirim DELETEdan membiarkan server memutuskan bagaimana menanganinya. Tetapi bagaimana jika A.comtidak mengetahui protokol CORS? Itu mungkin pergi dan mengeksekusi yang berbahaya DELETE. Mungkin diasumsikan bahwa — karena Kebijakan Same Origin dari peramban — ia tidak akan pernah bisa menerima permintaan seperti itu, dan karenanya mungkin tidak akan pernah diperketat terhadap serangan semacam itu.

Untuk melindungi server yang tidak menyadari CORS, protokol memerlukan browser untuk terlebih dahulu mengirim permintaan preflight . Jenis permintaan baru ini adalah sesuatu yang hanya dapat ditanggapi oleh server yang sadar dengan CORS, memungkinkan peramban mengetahui apakah aman mengirim yang sebenarnya atau tidak DELETE.

Mengapa semua ini ribut tentang browser, tidak bisa penyerang hanya mengirim DELETEpermintaan dari komputer mereka sendiri?

Tentu, tetapi permintaan seperti itu tidak akan menyertakan cookie pengguna. Serangan yang dirancang untuk mencegah hal ini bergantung pada fakta bahwa browser akan mengirim cookie (khususnya, informasi otentikasi untuk pengguna) untuk domain lain bersama dengan permintaan.

Itu terdengar seperti Cross-Site Request Pemalsuan , di mana formulir di situs B.comdapat POSTuntuk A.comdengan cookie pengguna dan melakukan kerusakan.

Betul. Cara lain untuk menempatkan ini adalah bahwa permintaan preflight dibuat agar tidak meningkatkan permukaan serangan CSRF untuk server yang tidak menyadari CORS.

Tetapi melihat persyaratan untuk permintaan "sederhana" yang tidak memerlukan preflight, saya melihat bahwa POSTitu masih diperbolehkan. Itu dapat mengubah status dan menghapus data seperti DELETE!

Itu benar! CORS tidak melindungi situs Anda dari serangan CSRF. Kemudian lagi, tanpa CORS Anda juga tidak terlindungi dari serangan CSRF. Tujuan permintaan preflight adalah hanya untuk membatasi paparan CSRF Anda dengan apa yang sudah ada di dunia pra-CORS.

Mendesah. OK, saya dengan enggan menerima kebutuhan untuk permintaan preflight. Tetapi mengapa kita harus melakukannya untuk setiap sumber daya (URL) di server? Server menangani CORS atau tidak.

Apa kamu yakin akan hal itu? Tidak jarang banyak server menangani permintaan untuk satu domain. Sebagai contoh, itu mungkin kasus yang meminta untuk A.com/url1ditangani oleh satu jenis server dan permintaan untuk A.com/url2ditangani oleh jenis server yang berbeda. Ini umumnya bukan kasus bahwa server yang menangani sumber daya tunggal dapat membuat jaminan keamanan tentang semua sumber daya di domain itu.

Baik. Mari berkompromi. Mari kita buat header CORS baru yang memungkinkan server untuk menyatakan dengan tepat sumber daya apa yang dapat berbicara, sehingga permintaan preflight tambahan untuk URL tersebut dapat dihindari.

Ide bagus! Bahkan, tajuk Access-Control-Policy-Pathitu diusulkan hanya untuk tujuan ini. Namun, pada akhirnya, itu tidak termasuk dalam spesifikasi, tampaknya karena beberapa server salah menerapkan spesifikasi URI sedemikian rupa sehingga permintaan untuk jalur yang tampaknya aman untuk browser sebenarnya tidak aman di server yang rusak.

Apakah ini keputusan bijaksana yang mengutamakan keamanan daripada kinerja, yang memungkinkan browser untuk segera mengimplementasikan spesifikasi CORS tanpa menempatkan server yang ada dalam risiko? Atau apakah itu picik untuk menghancurkan internet untuk memboroskan bandwidth dan menggandakan latensi hanya untuk mengakomodasi bug di server tertentu pada waktu tertentu?

Pendapat berbeda.

Ya, setidaknya browser akan menyimpan cache preflight untuk satu URL?

Iya. Meskipun mungkin tidak terlalu lama. Di browser WebKit, waktu cache preflight maksimum saat ini adalah 10 menit .

Mendesah. Nah, jika saya tahu bahwa server saya sadar CORS, dan karena itu tidak memerlukan perlindungan yang ditawarkan oleh permintaan preflight, apakah ada cara bagi saya untuk menghindarinya?

Satu-satunya pilihan nyata Anda adalah memastikan bahwa Anda memenuhi persyaratan untuk permintaan "sederhana". Itu mungkin berarti mengabaikan tajuk ubahsuaian yang akan Anda sertakan (seperti X-Requested-With), berbohong tentang Content-Type, atau lebih.

Apa pun yang Anda lakukan, Anda harus memastikan bahwa Anda memiliki perlindungan CSRF yang tepat karena spesifikasi CORS tidak membahas penolakan permintaan "sederhana", termasuk yang tidak aman POST. Seperti yang dinyatakan dalam spesifikasinya : "sumber daya yang permintaan sederhananya memiliki arti penting selain pengambilan harus melindungi diri dari Pemalsuan Permintaan Lintas Situs".


21
Ini adalah bagian pengantar terbaik yang pernah saya baca di CORS. Terima kasih!
kiv

5
Awesomely menjelaskan.
Pratz

4
Ini adalah jawaban terbaik yang saya lihat di topik. Dijelaskan dengan sangat baik!
alaboudi

3
CORS adalah bahan yang rumit, dan tulisan ini menjelaskan beberapa titik tersembunyi
Stanislav Verjikovskiy

1
@Yos: Peramban akan memasukkan cookie itu karena itulah cara browser diharapkan bekerja (sebagaimana dikodifikasi dalam standar seperti RFC 6265 ). Apakah peramban menggunakan proses terpisah untuk tab merupakan detail implementasi, peramban itu tidak akan mencegahnya mengirimkan cookie.
Kevin Christopher Henry

51

Pertimbangkan dunia permintaan lintas domain sebelum CORS. Anda bisa melakukan bentuk POST standar, atau menggunakan scriptatau imagetag untuk mengeluarkan permintaan GET. Anda tidak bisa membuat jenis permintaan lain selain GET / POST, dan Anda tidak bisa mengeluarkan header khusus apa pun pada permintaan ini.

Dengan munculnya CORS, penulis spec dihadapkan dengan tantangan memperkenalkan mekanisme lintas domain baru tanpa melanggar semantik web yang ada. Mereka memilih untuk melakukan ini dengan memberikan server cara untuk ikut serta ke jenis permintaan baru apa pun. Keikutsertaan ini adalah permintaan preflight.

Jadi, DAPATKAN / POST permintaan tanpa header kustom tidak perlu preflight, karena permintaan ini sudah mungkin sebelum CORS. Tapi setiap permintaan dengan header kustom, atau permintaan PUT / DELETE, jangan perlu preflight, karena ini baru ke CORS spec. Jika server tidak tahu apa-apa tentang CORS, server akan membalas tanpa header spesifik CORS, dan permintaan sebenarnya tidak akan dibuat.

Tanpa permintaan preflight, server dapat mulai melihat permintaan tak terduga dari browser. Ini dapat menyebabkan masalah keamanan jika server tidak siap untuk jenis permintaan ini. Prelight CORS memungkinkan permintaan lintas domain untuk diperkenalkan ke web dengan cara yang aman.


Bagaimana Anda membuat permintaan POST melalui skrip / tag img?
freakish

2
Kamu tidak bisa Maksud saya, Anda bisa melakukan formulir POST, ATAU melakukan GET menggunakan skrip / img. Saya mengedit posting untuk mudah-mudahan memperjelas ini.
monsur

Saya melihat. Itu masuk akal.
freakish

5
Terima kasih atas jawabannya, yang tentunya melengkapi gambar saya! Sayangnya saya masih gagal melihat titik pusat di belakang preflight. Mengenai jawaban Anda: Apa yang dimaksud dengan ' permintaan tak terduga '? Bagaimana itu bisa menjadi 'lebih' tak terduga / kurang aman di dunia non-preflight daripada di dunia preflight (dengan misalnya preflight yang hilang atau browser jahat yang hanya 'lupa' tentang preflighting)?
jan groth

7
Mungkin ada API di luar sana yang mengandalkan kebijakan yang sama dengan asal browser untuk melindungi sumber dayanya. Mereka seharusnya memiliki keamanan tambahan, tetapi mereka bergantung pada kebijakan asal yang sama. Tanpa preflight, pengguna di domain yang berbeda sekarang dapat mengeluarkan permintaan ke API. API akan menganggap permintaan itu valid (karena tidak tahu apa-apa tentang CORS) dan menjalankan permintaan itu. Peramban dapat memblokir respons agar tidak menjangkau pengguna, tetapi pada titik ini, kerusakan mungkin sudah terjadi. Jika permintaan itu PUT / HAPUS, sumber daya mungkin telah diperbarui atau dihapus.
monsur

37

CORS memungkinkan Anda menentukan lebih banyak tajuk dan tipe metode dari yang sebelumnya dimungkinkan dengan asal-usul silang <img src>atau <form action>.

Beberapa server dapat (dengan buruk) dilindungi dengan asumsi bahwa browser tidak dapat membuat, mis. DELETEPermintaan lintas asal atau permintaan lintas asal dengan X-Requested-Withheader, sehingga permintaan semacam itu "tepercaya".

Untuk memastikan bahwa server benar-benar sangat mendukung CORS dan tidak hanya menanggapi permintaan acak, preflight dijalankan.


12
Ini seharusnya jawaban yang diterima. Ini adalah yang paling jelas dan to-the-point. Pada dasarnya satu-satunya titik permintaan preflight adalah untuk mengintegrasikan standar Web pra-CORS dengan standar Web pasca-CORS.
chopper draw lion4

2
Saya suka jawaban ini, tapi saya rasa itu bukan alasan penuh ... "asumsi kepercayaan" harus diterapkan hanya untuk hal-hal yang hanya dapat dilakukan oleh peramban (khususnya, mengirimkan informasi pengguna peramban yang dibatasi ke domain mereka - yaitu, cookies). Jika itu bukan bagian dari asumsi, maka apa pun yang dapat dilakukan oleh permintaan browser lintas-asal dapat dilakukan oleh agen pihak ketiga, bukan browser, kan?
Fabio Beltramini

2
@FabioBeltramini Benar, non-browser dapat mengirim apapun yang mereka inginkan. Namun, serangan melalui browser adalah spesial karena Anda dapat membuat browser orang lain melakukan sesuatu, dari IP mereka sendiri, dengan cookie mereka sendiri, dll.
Kornel

Saya mulai melihat masalah sebenarnya. Terima kasih atas komentar dan balasan @FabioBeltramini dan balasan Kronel. Jika pemeriksaan pra-penerbangan tidak ada, penyerang akan dapat menempatkan beberapa kode JavaScript di situsnya tetapi dieksekusi dari banyak komputer orang lain. Semua klien lain agak sulit untuk 'mempekerjakan' orang lain untuk melakukan ini, termasuk Aplikasi seluler.
Xiao Peng - ZenUML.com

16

Berikut cara lain untuk melihatnya, menggunakan kode:

<!-- hypothetical exploit on evil.com -->
<!-- Targeting banking-website.example.com, which authenticates with a cookie -->
<script>
jQuery.ajax({
  method: "POST",
  url: "https://banking-website.example.com",
  data: JSON.stringify({
    sendMoneyTo: "Dr Evil",
    amount: 1000000
  }),
  contentType: "application/json",
  dataType: "json"
});
</script>

Sebelum CORS, upaya eksploitasi di atas akan gagal karena melanggar kebijakan yang sama-asal. API yang dirancang dengan cara ini tidak memerlukan perlindungan XSRF, karena dilindungi oleh model keamanan asli browser. Tidak mungkin peramban pra-CORS untuk menghasilkan JSON POST lintas-asal.

Sekarang CORS hadir - jika memilih ikut CORS melalui pra-penerbangan tidak diperlukan, tiba-tiba situs ini akan memiliki kerentanan besar, bukan karena kesalahan mereka sendiri.

Untuk menjelaskan mengapa beberapa permintaan diizinkan untuk melewati pra-penerbangan, ini dijawab oleh spek:

Permintaan lintas asal sederhana telah didefinisikan sebangun dengan permintaan yang mungkin dihasilkan oleh agen pengguna yang saat ini digunakan yang tidak sesuai dengan spesifikasi ini.

Untuk mengatasinya, GET tidak pra-penerbangan karena ini adalah "metode sederhana" seperti yang didefinisikan oleh 7.1.5. (Tajuk juga harus "sederhana" untuk menghindari pra-penerbangan). Pembenaran untuk ini adalah bahwa permintaan GET lintas-asal "sederhana" sudah bisa dilakukan oleh mis <script src="">(ini adalah cara kerja JSONP). Karena setiap elemen dengan srcatribut dapat memicu GET lintas-asal, tanpa pra-penerbangan, tidak akan ada manfaat keamanan untuk memerlukan pra-pertarungan pada XHR "sederhana".


1
@MilesRout: Telnet bukan bagian dari model ancaman yang bertujuan untuk ditanggulangi preflight. Preflight relevan dengan browser yang 1) Bergantung pada "otoritas sekitar" yang tersimpan, (misalnya cookie), dan 2) dapat diakali untuk menyalahgunakan otoritas itu oleh pihak ketiga (misalnya, pemalsuan permintaan lintas situs). Model umum dikenal sebagai masalah wakil bingung .
Dylan Tack

Itulah masalah dengan otoritas sekitar, Anda selalu dapat menyalahgunakannya.
Miles Rout

13

Saya merasa bahwa jawaban yang lain tidak fokus pada alasan pra-pertarungan meningkatkan keamanan.

Skenario:

1) Dengan pra-penerbangan . Seorang penyerang memalsukan permintaan dari situs dummy-forums.com sementara pengguna diautentikasi ke safe-bank.com
Jika Server tidak memeriksa asal, dan entah bagaimana memiliki cacat, browser akan mengeluarkan permintaan pra-penerbangan, OPTION metode. Server tidak mengetahui bahwa CORS yang diharapkan oleh browser sebagai respons sehingga browser tidak akan melanjutkan (tidak ada salahnya)

2) Tanpa pra-penerbangan . Seorang penyerang memalsukan permintaan dalam skenario yang sama seperti di atas, browser akan mengeluarkan permintaan POST atau PUT segera, server menerimanya dan mungkin memprosesnya, ini berpotensi akan menyebabkan kerusakan.

Jika penyerang mengirim permintaan secara langsung, asal silang, dari beberapa host acak, kemungkinan besar orang memikirkan permintaan tanpa otentikasi. Itu permintaan palsu, tapi bukan permintaan xsrf. sehingga server telah akan memeriksa kredensial dan gagal. CORS tidak berusaha mencegah penyerang yang memiliki kredensial untuk mengeluarkan permintaan, meskipun daftar putih dapat membantu mengurangi vektor serangan ini.

Mekanisme pra-penerbangan menambah keamanan dan konsistensi antara klien dan server. Saya tidak tahu apakah ini sepadan dengan jabat tangan ekstra untuk setiap permintaan karena caching sangat bisa digunakan di sana, tapi begitulah cara kerjanya.


Setuju dengan masalah serangan CSRF yang masih mungkin terhadap "server baru" yang disebutkan dalam balasan @ michael-iles.
belut ghEEz

Ini adalah deskripsi yang berguna yang mungkin berguna untuk direkam di tempat lain. Mungkin pertimbangkan untuk menambahkannya ke salah satu halaman MDN?
sontonbarker

Tetapi mengapa beberapa permintaan seperti POST dengan Teks / Jenis Konten tidak melakukan permintaan pra-penerbangan? Di kepala saya, setiap permintaan 'tulis' (POST, PUT, DELETE) harus memiliki permintaan pra-penerbangan ini jika keamanan menjadi masalah.
Israel Fonseca

POST dengan teks / polos dianggap sebagai permintaan sederhana - perhatikan bahwa browser tidak akan menampilkan respons jika asal tidak cocok (yang akan terjadi jika server tidak dikonfigurasi untuk CORS).
Hirako

Di sisi menyerang, ada hal-hal menarik yang dapat dilakukan, mengeksploitasi fakta permintaan sederhana ditoleransi dan akan dikirim oleh sebagian besar browser. misalnya ini .
Hirako

3

Selain itu, untuk metode permintaan HTTP yang dapat menyebabkan efek samping pada data pengguna (khususnya, untuk metode HTTP selain GET, atau untuk penggunaan POST dengan jenis MIME tertentu), spesifikasi tersebut mengamanatkan bahwa browser "mengatur terlebih dahulu" permintaan

Sumber


2

Permintaan pra-penerbangan diperlukan untuk permintaan yang dapat mengubah status di server. Ada 2 jenis permintaan -

1) Panggilan yang tidak dapat mengubah status di server (seperti MENDAPATKAN) - Pengguna mungkin mendapatkan respons untuk permintaan (jika server tidak memeriksa keaslian) tetapi jika domain yang meminta tidak ditambahkan ke header respons Access-Control- Izinkan-Asal, browser tidak menampilkan data kepada pengguna, yaitu permintaan dikirim dari browser tetapi pengguna tidak dapat melihat / memanfaatkan respons.

2) Panggilan yang dapat mengubah status di server (seperti POST, HAPUS) - Karena dalam 1), kita melihat bahwa browser tidak memblokir permintaan tetapi responsnya, menyatakan panggilan yang berubah tidak boleh dilakukan tanpa pemeriksaan sebelumnya . Panggilan semacam itu mungkin membuat perubahan pada server yang dapat dipercaya yang tidak memeriksa asal-usul panggilan (disebut Pemalsuan Permintaan Situs Lintas), meskipun respons terhadap browser mungkin gagal. Untuk alasan ini, kami memiliki konsep permintaan pra-penerbangan yang melakukan panggilan PILIHAN sebelum setiap perubahan panggilan negara dapat dikirim ke server.


1

Bukankah permintaan sebelumnya tentang Kinerja ? Dengan permintaan preflighted, klien dapat dengan cepat mengetahui apakah operasi diizinkan sebelum mengirim sejumlah besar data, misalnya, di JSON dengan metode PUT. Atau sebelum melakukan perjalanan data sensitif dalam header otentikasi melalui kabel.

Fakta PUT, DELETE, dan metode lain, selain tajuk khusus, tidak diizinkan secara default (Mereka membutuhkan izin eksplisit dengan "Metode Akses-Kontrol-Permintaan" dan "Akses-Kontrol-Permintaan-Header"), yang berbunyi seperti pemeriksaan ulang, karena operasi ini dapat memiliki lebih banyak implikasi pada data pengguna, bukan MENDAPATKAN permintaan. Jadi, sepertinya:

"Saya melihat bahwa Anda mengizinkan permintaan lintas situs dari http: //foo.example , TAPI Anda PASTI akan mengizinkan permintaan DELETE? Apakah Anda mempertimbangkan dampak yang mungkin ditimbulkan oleh permintaan ini dalam data pengguna?"

Saya tidak mengerti korelasi yang dikutip antara permintaan preflighted dan manfaat server lama. Layanan Web yang diterapkan sebelum CORS, atau tanpa kesadaran CORS, tidak akan pernah menerima permintaan lintas situs APAPUN, karena pertama-tama respons mereka tidak akan memiliki tajuk "Akses-Kontrol-Izinkan-Asal".


4
Anda salah memahami Access-Control-Allow-Origin. Tidak adanya header itu tidak mencegah browser mengirim permintaan, itu hanya mencegah JS dari dapat membaca data dalam respon.
Dylan Tack

Bisakah Anda menjelaskan ini 'Tidak adanya tajuk itu tidak mencegah browser mengirim permintaan, itu hanya mencegah JS agar tidak dapat membaca data dalam respons' lagi, saya tidak mengerti sepenuhnya.
Siddharth

@DylanTack Poin bagus. Ini membuat saya bertanya-tanya, mengapa GET xhr tidak menjadi preflight juga? Meskipun tidak mungkin, permintaan GET bisa berbahaya / bermutasi data juga. Juga, karena semua ini dapat diselesaikan dengan CSRF, menurut saya browser ini terlalu protektif terhadap server yang terlalu lalai untuk menerapkan praktik keamanan umum.
Peleg

Jawaban yang diterima menjelaskannya dengan baik, sebagai "hal yang tidak mengubah aturan" (kompatibilitas ke belakang dengan situs web yang dibuat sebelum CORS ada). Tetap menarik untuk melihat kode, jadi saya sudah mengirim jawaban lain dengan contoh kode.
Dylan Tack

1

Dalam browser yang mendukung CORS, permintaan membaca (seperti GET) sudah dilindungi oleh kebijakan asal-sama: Situs web jahat yang mencoba membuat permintaan lintas-domain yang diautentikasi (misalnya ke situs web internet banking korban atau antarmuka konfigurasi router) tidak akan dapat membaca data yang dikembalikan karena bank atau router tidak mengatur Access-Control-Allow-Originheader.

Namun, dengan permintaan penulisan (seperti POST) kerusakan dilakukan ketika permintaan tiba di server web. * Server web dapat memeriksa Originheader untuk menentukan apakah permintaan tersebut sah, tetapi pemeriksaan ini sering tidak dilaksanakan karena server web tidak perlu untuk CORS atau server web lebih tua dari CORS dan karena itu mengasumsikan bahwa POST lintas domain sepenuhnya dilarang oleh kebijakan asal-sama.

Itulah sebabnya webservers diberi kesempatan untuk ikut serta dalam menerima permintaan menulis lintas-domain .

* Pada dasarnya versi AJAX dari CSRF.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.