Apa gunanya header X-Diminta-Dengan?


224

JQuery dan kerangka kerja lainnya menambahkan header berikut:

X-Diminta-Dengan: XMLHttpRequest

Mengapa ini dibutuhkan? Mengapa server ingin memperlakukan permintaan AJAX berbeda dari permintaan normal?

UPDATE : Saya baru saja menemukan contoh kehidupan nyata menggunakan header ini: https://core.spreedly.com/manual/payment-methods/adding-with-js . Jika pemroses pembayaran diminta tanpa AJAX, itu akan diarahkan kembali ke situs web asli setelah selesai. Ketika diminta dengan AJAX, tidak ada pengalihan yang dilakukan.


7
"[Ketika] diminta tanpa AJAX, itu akan diarahkan kembali ke situs web asli ketika selesai. Ketika diminta dengan AJAX, tidak ada redirection yang dilakukan." -> Itulah mengapa Anda ingin melakukannya. :)
Robert Christian

Jawaban:


257

Alasan yang baik adalah untuk keamanan - ini dapat mencegah serangan CSRF karena header ini tidak dapat ditambahkan ke domain lintas permintaan AJAX tanpa persetujuan server melalui CORS .

Hanya tajuk berikut yang diizinkan lintas domain:

  • Menerima
  • Bahasa Terima
  • Konten-Bahasa
  • ID Acara Terakhir
  • Jenis konten

yang lain menyebabkan permintaan "pra-penerbangan" dikeluarkan di browser yang didukung CORS.

Tanpa CORS tidak mungkin untuk ditambahkan X-Requested-With permintaan XHR lintas domain.

Jika server memeriksa apakah tajuk ini ada, ia tahu bahwa permintaan tersebut tidak dimulai dari domain penyerang yang mencoba mengajukan permintaan atas nama pengguna dengan JavaScript. Ini juga memeriksa bahwa permintaan tersebut tidak POSTed dari bentuk HTML biasa, yang lebih sulit untuk memverifikasi itu bukan lintas domain tanpa menggunakan token. (Namun, memeriksa Origintajuk bisa menjadi opsi di browser yang didukung, meskipun Anda akan membuat browser lama menjadi rentan .)

Bypass Flash baru ditemukan

Anda mungkin ingin menggabungkan ini dengan token , karena Flash yang berjalan di Safari pada OSX dapat mengatur header ini jika ada langkah redirect . Tampaknya itu juga berfungsi di Chrome , tetapi sekarang diatasi. Lebih detail di sini termasuk berbagai versi yang terpengaruh.

OWASP Merekomendasikan menggabungkan ini dengan pemeriksaan Asal dan Perujuk :

Teknik pertahanan ini secara khusus dibahas dalam bagian 4.3 dari Pertahanan Kuat untuk Pemalsuan Permintaan Lintas Situs. Namun, bypass pertahanan ini menggunakan Flash didokumentasikan pada awal 2008 dan lagi baru-baru ini pada tahun 2015 oleh Mathias Karlsson untuk mengeksploitasi kelemahan CSRF di Vimeo. Namun, kami percaya bahwa serangan Flash tidak dapat menipu header Origin atau Referer sehingga dengan memeriksa keduanya, kami yakin kombinasi cek ini akan mencegah serangan bypass CSRF Flash. (CATATAN: Jika ada yang bisa mengkonfirmasi atau menyangkal keyakinan ini, beri tahu kami agar kami dapat memperbarui artikel ini)

Namun, untuk alasan yang sudah dibahas memeriksa Asal bisa rumit.

Memperbarui

Menulis posting blog yang lebih mendalam tentang CORS, CSRF dan X-Requested-With di sini .


14
Saya tidak mengerti. Apa yang mencegah penyerang membuat permintaan dan menambahkan X-Requested-Withheader juga?
Greg

13
@Reg: Browser - ini tidak akan memungkinkannya lintas domain.
SilverlightFox

2
Oh, saya tidak menyadari bahwa konfigurasi CORS akan diperlukan selama Anda berada di domain yang sama. Ini jelas ketika Anda memikirkannya. Terima kasih!
Greg

10
@ vol7ron: Tidak ada yang menghentikan mereka, tetapi kemudian mereka tidak akan memiliki cookie korban mereka dalam permintaan yang mengalahkan objek mereka yang membuat permintaan. Agar CSRF berhasil, penyerang akan membutuhkan browser untuk secara otomatis melampirkan cookie dengan permintaan, jadi tanpa browser tidak ada serangan CSRF.
SilverlightFox

3
@ vol7ron: Yang pertama. CSRF adalah masalah wakil bingung . Peramban adalah wakil yang bingung dan "tertipu" mengirim cookie untuk permintaan yang tidak dibuat pengguna.
SilverlightFox

25

Pastikan Anda membaca jawaban SilverlightFox. Ini menyoroti alasan yang lebih penting.

Alasannya sebagian besar adalah bahwa jika Anda tahu sumber permintaan Anda mungkin ingin menyesuaikannya sedikit.

Misalnya katakanlah Anda memiliki situs web yang memiliki banyak resep. Dan Anda menggunakan kerangka jQuery khusus untuk memasukkan resep ke dalam wadah berdasarkan tautan yang dikliknya. Tautannya mungkinwww.example.com/recipe/apple_pie

Sekarang biasanya kembali satu halaman penuh, header, footer, konten resep dan iklan. Tetapi jika seseorang menjelajah situs web Anda beberapa bagian sudah dimuat. Jadi Anda dapat menggunakan AJAX untuk mendapatkan resep yang telah dipilih pengguna tetapi untuk menghemat waktu dan bandwidth jangan memuat header / footer / iklan.

Sekarang Anda bisa menulis titik akhir sekunder untuk data seperti www.example.com/recipe_only/apple_pie tetapi itu lebih sulit untuk dipertahankan dan dibagikan kepada orang lain.

Tetapi lebih mudah untuk mendeteksi bahwa itu adalah permintaan ajax yang membuat permintaan dan kemudian mengembalikan hanya sebagian dari data. Dengan cara itu pengguna membuang lebih sedikit bandwidth dan situs tampak lebih responsif.

Kerangka kerja hanya menambahkan header karena beberapa mungkin merasa berguna untuk melacak permintaan mana yang ajax dan yang tidak. Tetapi sepenuhnya tergantung pada pengembang untuk menggunakan teknik seperti itu.

Sebenarnya agak mirip dengan Accept-Languageheader. Peramban dapat meminta situs web, tunjukkan versi Rusia dari situs web ini tanpa harus memasukkan / ru / atau yang serupa di URL.


30
Wow, itu terdengar seperti mimpi buruk pemeliharaan yang mengerikan. Jika Anda ingin mengembalikan representasi yang berbeda dari halaman yang sama, Anda harus memberikan tipe konten yang berbeda ke Acceptheader. Menggunakan header khusus untuk ini sepertinya cara yang salah untuk dilakukan.
Gili

10

Beberapa kerangka kerja menggunakan header ini untuk mendeteksi permintaan xhr mis. Keamanan grails spring menggunakan header ini untuk mengidentifikasi permintaan xhr dan memberikan respons json atau respons html sebagai respons.

Sebagian besar pustaka Ajax (Prototipe, JQuery, dan Dojo pada v2.1) menyertakan header X-Requested-With yang menunjukkan bahwa permintaan dibuat oleh XMLHttpRequest alih-alih dipicu dengan mengklik hyperlink biasa atau tombol kirim formulir.

Sumber: http://grails-plugins.github.io/grails-spring-security-core/guide/helperClasses.html

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.