Pertanyaan Perlindungan CSRF dengan header CORS Origin vs. token CSRF


Pertanyaan ini adalah tentang melindungi terhadap serangan Pematian Permintaan Situs Silang saja.

Khususnya tentang: Apakah perlindungan melalui header Origin (CORS) sebaik perlindungan melalui token CSRF?

Contoh:

  • Alice login (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 semacam permintaan untuk"https://example.com"(skenario CSRF klasik).

Begitu:

  • Jika kita tidak memeriksa header Origin (server-side), dan tidak ada token CSRF, kita memiliki lubang keamanan CSRF.
  • Jika kami memeriksa token CSRF, kami aman (tapi ini agak membosankan).
  • Jika kita memeriksa header Origin, permintaan dari kode sisi client evil.com harus diblokir sama baiknya dengan ketika menggunakan token CSRF - kecuali, jika mungkin entah bagaimana untuk kode evil.com untuk mengatur header Origin.

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

Tetapi bagaimana dengan jenis permintaan lainnya - mis. kirim formulir? Memuat tag skrip / img / ...? Atau cara lain halaman dapat digunakan untuk (secara hukum) membuat permintaan? Atau mungkin beberapa hack JS yang dikenal?

Catatan: Saya tidak berbicara tentang

  • aplikasi asli,
  • peramban yang dimanipulasi,
  • bug scripting lintas situs di halaman example.com,
  • ...

76
2017-07-10 15:17


asal


Jawaban:


tahu, bahwa hal ini tidak mungkin dilakukan dengan XHR (lihat misalnya. Keamanan untuk berbagi sumber daya lintas-asal), 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 sisi klien dari sesi tersebut. Jika Anda tidak mempercayai browser klien, maka Anda harus berhenti menggunakan web sama sekali untuk hal lain selain konten statis. Bahkan dengan menggunakan token CSRF, Anda mempercayai browser klien untuk benar mematuhi Kebijakan Asal yang Sama.

Meskipun ada kerentanan browser sebelumnya seperti yang ada di dalamnya IE 5.5 / 6.0 di mana telah memungkinkan bagi penyerang untuk 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.

Tetapi bagaimana dengan jenis permintaan lainnya - mis. kirim formulir? Memuat tag skrip / img / ...? Atau cara lain halaman dapat digunakan untuk (secara hukum) membuat permintaan? Atau mungkin beberapa hack JS yang dikenal?

Itu Origin header biasanya hanya dikirim untuk permintaan lintas domain XHR. Permintaan gambar tidak berisi tajuk.

Catatan: Saya tidak berbicara tentang

  • aplikasi asli,

  • peramban yang dimanipulasi,

  • bug scripting lintas situs di halaman example.com,

Saya tidak yakin apakah ini berada di bawah peramban yang dimanipulasi atau tidak, tetapi versi lama Flash memungkinkan tajuk yang tidak semestinya diatur yang akan memungkinkan penyerang mengirim permintaan dengan spoof referertajuk dari mesin korban untuk melakukan serangan.


31
2017-07-11 07:40



Konten web tidak dapat mengutak-atik header Asal. Selain itu, di bawah kebijakan asal yang sama, satu asal tidak dapat mengirim header khusus ke asal lain. [1]

Jadi, memeriksa tajuk Asal sama bagusnya memblokir serangan seperti menggunakan token CSRF.

Perhatian utama dengan mengandalkan ini adalah apakah itu memungkinkan semua permintaan yang sah bekerja. Penanya tahu tentang masalah ini, dan telah menyiapkan pertanyaan untuk mengesampingkan kasus-kasus besar (tidak ada peramban lama, hanya HTTPS).

Vendor browser mengikuti aturan ini, tapi bagaimana dengan plugin? Mereka mungkin tidak, tetapi pertanyaannya mengabaikan "memanipulasi browser." Bagaimana dengan bug di browser yang memungkinkan penyerang memalsukan tajuk Asal? Mungkin ada bug yang memungkinkan token CSRF bocor ke asal-usul juga, jadi perlu lebih banyak upaya untuk menyatakan bahwa yang satu lebih baik daripada yang lain.


24
2017-07-11 00:38