Perlindungan CSRF dengan header CORS Origin vs. token CSRF

103

Pertanyaan ini adalah tentang melindungi dari serangan Pemalsuan Permintaan Lintas Situs saja.

Ini secara khusus tentang: Apakah perlindungan melalui header Origin (CORS) sebaik perlindungan melalui token CSRF?

Contoh:

Alice masuk (menggunakan cookie) dengan browsernya ke " https://example.com ". Saya berasumsi, bahwa dia menggunakan browser modern.
Alice mengunjungi " https://evil.com ", dan kode sisi klien evil.com melakukan beberapa jenis permintaan ke " https://example.com " (skenario CSRF klasik).

Begitu:

Jika kami tidak memeriksa header Origin (sisi server), dan tidak ada token CSRF, kami memiliki lubang keamanan CSRF.
Jika kami memeriksa token CSRF, kami aman (tetapi agak membosankan).
Jika kami memeriksa header Origin, permintaan dari kode sisi klien evil.com harus diblokir seperti halnya saat menggunakan token CSRF - kecuali, jika memungkinkan, entah bagaimana kode evil.com untuk menyetel header Origin.

Saya tahu, bahwa ini seharusnya tidak mungkin dilakukan dengan XHR (lihat misalnya Keamanan untuk berbagi sumber daya lintas sumber ), setidaknya tidak, jika kita mempercayai spesifikasi W3C untuk diterapkan dengan benar di semua browser modern (dapatkah kita?)

Tapi bagaimana dengan jenis permintaan lainnya - misalnya pengiriman formulir? Memuat tag skrip / img / ...? Atau cara lain apa pun yang dapat digunakan halaman untuk (secara legal) membuat permintaan? Atau mungkin beberapa peretasan JS yang dikenal?

Catatan: Saya tidak sedang membicarakan

aplikasi asli,
browser yang dimanipulasi,
bug skrip lintas situs di halaman example.com,
...

— Chris Lercher
sumber

Saya yakin banyak proxy menghapus header asal.

— thefourtheye

Dan untuk pengiriman formulir dan tag img / script, kita harus mengandalkan CSPs, meskipun tidak yakin dengan browser lama.

— thefourtheye

@thefourtheye: Karena koneksi dimulai melalui TLS, pengguna memiliki masalah yang jauh lebih mendesak daripada CSRF jika proxy dapat menanganinya.

— Perseids

@thefourtheye, mengapa mereka menelanjangi Origin? Itu akan meniadakan perlindungan CORS.

— Paul Draper

Saya suka pertanyaan ini dan jawabannya karena ini tentang sesuatu yang spesifik, tetapi juga mengingatkan saya tentang perbedaan antara CSRF dan CORS. (Saya akui itu bukanlah konsep yang mudah membingungkan ... Tapi saya masih berhasil membingungkannya.)

— The Red Pea

Jawaban:

ketahuilah, bahwa hal ini tidak mungkin dilakukan dengan XHR (lihat misalnya Keamanan untuk berbagi sumber daya lintas sumber), setidaknya tidak, jika kita mempercayai spesifikasi W3C untuk diterapkan dengan benar di semua browser modern (dapatkah kita?)

Pada akhirnya, Anda harus "mempercayai" browser klien untuk menyimpan data pengguna dengan aman dan melindungi sesi dari sisi klien. Jika Anda tidak mempercayai browser klien, maka Anda harus berhenti menggunakan web sama sekali untuk apa pun selain konten statis. Bahkan dengan menggunakan token CSRF, Anda mempercayai browser klien untuk mematuhi Kebijakan Asal yang Sama dengan benar .

Meskipun ada kerentanan browser sebelumnya seperti yang ada di IE 5.5 / 6.0 di mana penyerang dapat melewati Kebijakan Asal yang Sama dan melakukan serangan, Anda biasanya dapat mengharapkan ini untuk ditambal segera setelah ditemukan dan dengan sebagian besar browser secara otomatis memperbarui , risiko ini sebagian besar akan dikurangi.

Tapi bagaimana dengan jenis permintaan lainnya - misalnya pengiriman formulir? Memuat tag skrip / img / ...? Atau cara lain apa pun yang dapat digunakan halaman untuk (secara legal) membuat permintaan? Atau mungkin beberapa peretasan JS yang dikenal?

The OriginHeader biasanya hanya dikirim untuk permintaan lintas domain XHR. Permintaan gambar tidak mengandung header.

Catatan: Saya tidak sedang membicarakan

aplikasi asli,

browser yang dimanipulasi,

bug skrip lintas situs di halaman example.com,

Saya tidak yakin apakah ini termasuk dalam browser yang dimanipulasi atau tidak, tetapi versi lama Flash mengizinkan penyetelan header yang sewenang-wenang yang akan memungkinkan penyerang mengirim permintaan dengan refererheader palsu dari mesin korban untuk melakukan serangan.

— SilverlightFox
sumber

Contoh Flash bagus - dan mungkin plugin lain mungkin memiliki kerentanan serupa. Saya (sayangnya) hanya dapat melindungi Alice dari CSRF, jika dia menggunakan browser modern dll, itu jelas. Tetapi bukannya tidak masuk akal, bahkan sebagai pengguna yang sadar keamanan, dia mungkin telah menginstal plugin pihak ke-3 - terutama jika plugin tersebut berasal dari perusahaan besar (tepercaya). Meskipun mereka mungkin menulis plugin yang aman, saya tidak yakin 100%, jika mereka juga memikirkan CSRF! Jadi, kecuali kotak pasir browser membatasi plugin agar tidak melanggar SOP (mungkinkah?), Saya lebih suka merekomendasikan untuk tetap menggunakan token CSRF.

— Chris Lercher

@ChrisLercher: Ya, plugin modern tampaknya sedikit lebih kuat. Namun, setiap saat versi baru dapat dirilis yang memungkinkan penyerang untuk memanfaatkannya sedemikian rupa untuk melewati perlindungan browser. Cara terbaik untuk menanganinya (misalnya token / header) akan bergantung pada sensitivitas data Anda dan apakah risiko tersebut dapat diterima. Flash mematuhi SOP, tetapi asal dari plugin Flash adalah situs tempat ia dimuat (bukan situs pemanggil seperti JavaScript). Ada crossdomain.xmlyang bisa mengaktifkan komunikasi lintas domain.

— SilverlightFox

Konten web tidak dapat merusak header Origin. Selain itu, berdasarkan kebijakan asal yang sama, satu asal bahkan tidak dapat mengirim header kustom ke asal lain. [1]

Jadi, memeriksa header Origin sama bagusnya dengan memblokir serangan seperti menggunakan token CSRF.

Perhatian utama dengan mengandalkan ini adalah apakah ini memungkinkan semua permintaan yang sah berfungsi. Penanya mengetahui tentang masalah ini, dan telah menyiapkan pertanyaan untuk mengesampingkan kasus utama (tidak ada browser lama, hanya HTTPS).

Vendor browser mengikuti aturan ini, tetapi bagaimana dengan plugin? Mungkin tidak, tapi pertanyaannya mengabaikan "browser yang dimanipulasi". Bagaimana dengan bug di browser yang memungkinkan penyerang memalsukan header Origin? Mungkin ada bug yang memungkinkan token CSRF bocor ke seluruh asal juga, jadi akan membutuhkan lebih banyak pekerjaan untuk menyatakan bahwa satu lebih baik daripada yang lain.

— tamu
sumber

Saya baru saja menguji Firefox 47 dan tidak mengirim header asal untuk posting formulir lintas-asal (cara umum menyerang layanan REST yang tidak mengaktifkan CORS untuk XHR), jadi saya tidak berpikir untuk memeriksa header asal akan efektif jika pengguna menggunakan Firefox.

— Andy

Sebagai rujukan, masalah Firefox yang tidak mengirimkan tajuk "Asal" dilacak di Bugzilla: bugzilla.mozilla.org/show_bug.cgi?id=446344 Anda dapat mundur untuk memeriksa tajuk "Perujuk" dalam kasus ini tetapi menurut pengalaman saya beberapa Pengguna Firefox memblokir tajuk "Referer" karena masalah privasi (meskipun IMHO itu akan cukup untuk menghapus jalur dan kueri).

— Steffen