Apa yang harus menghentikan kode jahat dari spoofing header "Asal" untuk mengeksploitasi CORS?

142

Cara saya memahaminya, jika skrip sisi klien yang berjalan pada halaman dari foo.com ingin meminta data dari bar.com, dalam permintaan itu harus menentukan header Origin: http://foo.com, dan bar harus merespons dengan Access-Control-Allow-Origin: http://foo.com.

Apa yang ada untuk menghentikan kode berbahaya dari situs roh.com dari hanya memalsukan header Origin: http://foo.comuntuk meminta halaman dari bar?

— Jay Lamont
sumber

Saya percaya intinya adalah bahwa domain asli dari halaman yang dilayani (di sini, foo.com) harus memberikan Access-Control-Allow-Origintajuk atau browser tidak mengizinkan permintaan untuk bar.com.

— Chris Hayes

Membaca posting ini benar-benar membantu saya dalam pemahaman saya tentang proses kor antara browser, server asal, dan server target. html5rocks.com/en/tutorials/cors

— brendonparker

@ ChrisHayes Bukan cara CORS bekerja sama sekali. Anda dapat membaca ini sedikit lebih banyak dengan melihat spesifikasi , atau halaman wiki MDN yang hebat tentang subjek ini .

— Ray Nicholus

@brendonparker Ya, itu artikel yang bagus. Penulis itu menjawab banyak pertanyaan CORS pada SO, dan juga memelihara enable-cors.org .

— Ray Nicholus

@ RayNicholus Menarik, saya jelas-jelas pergi. Terima kasih atas tautannya. Menilai oleh suara pada komentar saya, saya bukan satu-satunya yang menderita di bawah khayalan ini. Saya harap mereka kembali dan belajar (dan menghapus suara mereka!).

— Chris Hayes

Jawaban:

149

Browser mengendalikan pengaturan Origintajuk, dan pengguna tidak dapat mengesampingkan nilai ini. Jadi Anda tidak akan melihat Origintajuk yang dipalsukan dari peramban. Pengguna jahat dapat membuat permintaan ikal yang mengatur Origintajuk secara manual , tetapi permintaan ini akan datang dari luar peramban, dan mungkin tidak memiliki info khusus peramban (seperti cookie).

Ingat: CORS bukan keamanan. Jangan mengandalkan CORS untuk mengamankan situs Anda. Jika Anda menyajikan data yang dilindungi, gunakan cookie atau token OAuth atau sesuatu selain Originheader untuk mengamankan data itu. The Access-Control-Allow-Originheader CORS hanya perintah yang asal harus diizinkan untuk membuat permintaan cross-asal. Jangan mengandalkan itu untuk hal lain.

— monsur
sumber

Ini sangat masuk akal. Jika browser tidak mengizinkan JavaScript untuk mengganti header Origin, maka tidak ada masalah. Jika Anda menjalankan permintaan dari luar browser, Anda tidak akan memiliki cookie. Saya kira saya bingung karena di semua dokumen yang saya baca, tidak ada yang mengatakan secara eksplisit bahwa header Origin tidak dapat diganti. Terima kasih!

— Jay Lamont

Jika seseorang ingin menipu sesuatu, maka mereka dapat melakukannya. Dengan menggunakan hampir semua bahasa scripting, mereka dapat membuat permintaan http. Perl dan Python memiliki perpustakaan http yang membuatnya sangat mudah. Perpustakaan menyimpan dan mengirim cookie, memungkinkan Anda menambahkan header sewenang-wenang, dan memberikan banyak informasi debug. Jadi tajuk CORS hanya untuk mempersulit javascript berbahaya pada forum yang Anda baca untuk melakukan sesuatu yang buruk pada rekening bank Anda di domain lain saat Anda masuk ke keduanya di browser Anda.

— Mnebuerquo

Dan hanya untuk memperjelas, pengguna jahat hanya dapat menelurkan contoh browser yang ditambal untuk memungkinkan mereka kontrol manual atas header Origin, dan kemudian dengan sempurna menyamar sebagai pengguna normal, cookie, AJAX dan semua.

— Jordan Rieger

"Browser mengendalikan pengaturan header Asal, dan pengguna tidak dapat mengesampingkan nilai ini." Saya yakin sangat mudah untuk menggunakan alat seperti Fiddler2 atau Charles untuk memodifikasi header setelah permintaan meninggalkan browser.

— Asa

pengguna jahat hanya dapat menelurkan instance browser yang ditambal untuk memungkinkan mereka kontrol manual atas header Origin Jika Anda memiliki akses ke mesin ke titik di mana Anda dapat 'hanya menelurkan instance browser yang ditambal' (tidak benar-benar terdengar sederhana seperti itu kepada saya), mengapa tidak langsung membaca cookie dari disk? Mereka disimpan dalam teks biasa lho. Dalam kehidupan nyata, skrip lintas situs adalah ancaman nyata, sedangkan skenario serangan Anda hanya dibuat-buat dan tidak praktis.

— Stijn de Witt

TLDR: Tidak ada yang menghentikan kode jahat dari spoofing asalnya. Ketika itu terjadi, server Anda tidak akan pernah mengetahuinya dan akan bertindak atas permintaan tersebut. Terkadang permintaan itu mahal. Jadi jangan gunakan CORS sebagai ganti segala jenis keamanan.

Saya telah bermain-main dengan CORS baru-baru ini, dan saya bertanya pada diri sendiri pertanyaan yang sama. Apa yang saya temukan adalah bahwa browser mungkin cukup pintar untuk mengetahui permintaan CORS palsu ketika melihatnya, tetapi server Anda tidak sepintar itu.

Hal pertama yang saya temukan adalah bahwa Originheader adalah nama header HTTP terlarang yang tidak dapat dimodifikasi secara pemrograman. Yang berarti Anda dapat memodifikasinya dalam waktu sekitar 8 detik menggunakan Modify Headers untuk Google Chrome .

Untuk mengujinya, saya menyiapkan dua domain Klien dan satu domain Server. Saya menyertakan daftar putih CORS di Server, yang memungkinkan permintaan CORS dari Klien 1 tetapi tidak dari Klien 2. Saya menguji kedua klien, dan memang permintaan CORS 1 Klien berhasil sementara Klien 2 gagal.

Lalu saya spoof Originheader Klien 2 untuk mencocokkan Klien 1. Server menerima Origintajuk palsu , dan berhasil melewati pemeriksaan daftar putih (atau gagal jika Anda tipe pria setengah gelas kosong). Setelah itu, Server melakukan dengan patuh dengan mengonsumsi semua sumber daya yang dirancang untuk dikonsumsi (panggilan basis data, mengirim email mahal, mengirim pesan sms bahkan lebih mahal, dll.). Ketika itu selesai, server dengan senang hati mengirim Access-Control-Allow-Originheader palsu itu kembali ke browser.

Dokumentasi yang saya baca menyatakan bahwa Access-Control-Allow-Originnilai yang diterima harus sama dengan Originnilai yang dikirim dalam permintaan. Mereka memang cocok, jadi saya terkejut ketika saya melihat pesan berikut di Chrome:

XMLHttpRequest tidak dapat memuat http://server.dev/test. Header 'Access-Control-Allow-Origin' memiliki nilai http://client1.dev yang tidak sama dengan asal yang disediakan. http://client2.dev Karena itu, Asal tidak diizinkan mengakses.

Dokumentasi yang saya baca sepertinya tidak akurat. Tab jaringan Chrome dengan jelas menunjukkan header permintaan dan respons sebagai http://client1.dev, tetapi Anda dapat melihat dalam kesalahan bahwa entah bagaimana Chrome mengetahui asal sebenarnya http://client2.devdan menolak tanggapan dengan benar. Yang tidak penting pada saat ini karena server sudah menerima permintaan palsu dan menghabiskan uang saya.

— Nocturno
sumber

@Nocturno, terima kasih atas contohnya. Izinkan saya menambahkan pengamatan saya. CORS terkait dengan fitur keamanan browser. Jika browser yang aman dimodifikasi dari keadaan aslinya, itu bisa ditafsirkan sebagai browser yang mungkin tidak memiliki fitur keamanan.

— Luka Žitnik

Sama sekali tidak brilian. Benar-benar merindukan inti dari CORS. Jika Anda berada dalam posisi untuk mencegat permintaan yang berasal dari mesin pengguna, Anda bisa membaca cookie mereka, menginstal keylogger, virus dan semua ancaman nyata lainnya. CORS ada untuk melindungi pengguna jujur yang masuk ke situs A dari skrip berbahaya yang entah bagaimana disuntikkan ke situs B. Skrip di situs B (yang bisa berupa cuplikan Javascript di pos forum yang tidak lolos dengan benar oleh situs B) melakukan tindakan di situs A di bawah akun pengguna (mis. hapus barang dll), menggunakan cookie sesi dari situs A.

— Stijn de Witt

Ini disebut cross-site scripting dan tanpa CORS dapat dilakukan tanpa perlu mendapatkan kendali atas mesin pengguna. Itulah intinya. Tidak ada kontrol atas mesin pengguna diperlukan karena ketika membuat permintaan ke situs A browser digunakan untuk secara otomatis menambahkan cookie sesi ke permintaan sehingga tampak seperti permintaan yang valid dari pengguna itu sendiri ketika sebenarnya itu berasal dari skrip di beberapa lainnya situs Kebijakan Same-Origin mencegahnya dan CORS digunakan untuk domain daftar putih yang harus diberikan akses meskipun mereka memiliki asal yang berbeda.

— Stijn de Witt

@Nocturno Ya saya mungkin agak terlalu kasar, maaf soal itu. Poin asli Anda tetap berlaku. Kebijakan Same-Origin adalah fitur keamanan browser dan CORS adalah mekanisme untuk melemahkan keamanan itu dengan memasukkan beberapa domain ke daftar putih. OP perlu memahami bahwa spoofing header Origin tidak benar-benar layak sebagai 'serangan' karena itu tidak membawa Anda apa pun yang tidak bisa didapat dengan misalnya curl.

— Stijn de Witt

@Nocturno Saya pikir pernyataan pembuka Anda agak menyesatkan. There's nothing stopping malicious code from spoofing the origin-> Ya ada, javascript tidak dapat diatur Origin. Ya, pengguna dapat memodifikasi browser mereka / menggunakan fiddler untuk mengubah asal, tapi bukan itu yang CORS pertahankan; situs web yang dikendalikan penyerang tidak dapat mengubah Asal, yang penting.

— RJFalconer

Hanya bungkus sederhana:

T: Apakah Kebijakan Asal yang Sama (SOP) diberlakukan hanya oleh browser?
A: Ya. Untuk semua panggilan yang Anda lakukan di dalam browser, SOP sudah pasti diterapkan oleh browser. Server mungkin atau mungkin tidak memeriksa asal permintaan.

T: Jika permintaan tidak mematuhi SOP, apakah browser memblokirnya?
A: Tidak, itu di luar otoritas browser. Peramban hanya mengirim permintaan asal silang dan menunggu respons untuk melihat apakah panggilan tersebut ditandai oleh server melalui Access-Controlheader - *. Jika server tidak mengirim kembali Access-Control-Allow-Originheader, tidak mengulangi asal pemanggil, atau tidak mengirim kembali *di header, maka semua hal yang browser akan lakukan adalah menahan diri untuk tidak memberikan respons kepada pemanggil.

T: Apakah itu berarti saya tidak bisa menipu Origin?
A: Di browser dan menggunakan skrip, Anda tidak dapat menimpa Originkarena berada dalam kendali browser. Namun, jika Anda ingin meretas sendiri, Anda dapat merusak panggilan yang keluar dari browser ANDA menggunakan ekstensi browser atau alat lain yang Anda instal pada mesin Anda. Anda juga dapat mengeluarkan HTTPpanggilan menggunakan curl, Python, C#, dll dan mengubah Originheader server trik.

T: Jadi jika saya bisa mengelabui server dengan mengubah Origin, apakah itu berarti CORStidak aman?
A: CORS per se diam tentang keamanan - yaitu otentikasi dan otorisasi permintaan. Terserah server untuk memeriksa permintaan dan mengotentikasi / mengotorisasi mereka dengan mekanisme apa pun yang bekerja dengan mereka seperti cookie dan header. Karena itu, itu dapat melindungi kita sedikit lebih dalam kasus serangan seperti XSS:

Contoh: Katakanlah Anda telah masuk ke situs web Anda dan skrip jahat mencoba mengirim permintaan ke situs web bank Anda untuk menanyakan saldo Anda: serangan Refleksi XSS . Situs web bank Anda memercayai kredensial yang berasal dari (di sini atas nama) situs web Anda sehingga permintaan akan diautentikasi dan HTTPrespons yang bertujuan untuk kode berbahaya dikeluarkan. Jika situs web bank Anda tidak peduli tentang berbagi titik akhir dengan sumber lain, itu tidak termasukAccess-Control-Allow-Originsundulan dalam respons. Sekarang, setelah kedatangan permintaan, browser menyadari bahwa permintaan tersebut adalah permintaan Cross Origins, tetapi responsnya tidak menunjukkan bahwa server senang berbagi sumber daya (di sini titik akhir kueri saldo) dengan situs web Anda. Jadi itu memutus aliran, maka hasil yang dikembalikan tidak akan pernah mencapai kode berbahaya.

— Alireza
sumber

Bagus, lebih baik / lebih jelas daripada jawaban yang diterima IMO

— 3dGrabber