Formulir Lintas Domain POSTing

145

Saya telah melihat artikel dan posting di seluruh (termasuk SO) tentang topik ini, dan komentar yang berlaku adalah bahwa kebijakan yang sama asal mencegah bentuk POST di seluruh domain. Satu-satunya tempat saya melihat seseorang menyarankan bahwa kebijakan asal yang sama tidak berlaku untuk membentuk pos, ada di sini .

Saya ingin mendapat jawaban dari sumber yang lebih "resmi" atau formal. Misalnya, apakah ada yang tahu RFC yang membahas bagaimana asal-sama tidak atau tidak mempengaruhi formulir POST?

klarifikasi : Saya tidak menanyakan apakah GET atau POST dapat dibangun dan dikirim ke domain apa pun. Saya bertanya:

jika Chrome, IE, atau Firefox akan memungkinkan konten dari domain 'Y' untuk mengirim POST ke domain 'X'
jika server yang menerima POST benar-benar akan melihat nilai formulir apa pun. Saya mengatakan ini karena sebagian besar diskusi online mencatat penguji mengatakan server menerima posting, tetapi nilai formulir semuanya kosong / dilucuti.
Apa dokumen resmi (yaitu RFC) menjelaskan apa perilaku yang diharapkan (terlepas dari apa yang telah diterapkan browser saat ini).

Kebetulan, jika asal-sama tidak mempengaruhi bentuk POST - maka itu membuatnya agak lebih jelas mengapa token anti-pemalsuan diperlukan. Saya mengatakan "agak" karena tampaknya terlalu mudah untuk percaya bahwa seorang penyerang bisa mengeluarkan HTTP GET untuk mengambil bentuk yang berisi token anti-pemalsuan, dan kemudian membuat POST ilegal yang berisi token yang sama. Komentar?

— Brent Arias
sumber

Ya, penyerang bisa melakukan itu ... dengan browser web biasa.

— Michael Hampton

Mungkin tidak ada RFC karena alasan yang sama mengapa tidak ada RFC yang mengatakan: "jangan memposting kata sandi Anda di situs web Anda". Standar web hanya diperlukan ketika banyak pihak harus bekerja sama untuk mencapai sesuatu: kebijakan asal yang sama lebih merupakan seperangkat "praktik terbaik keamanan" yang kompleks yang mencegah pengguna diretas.

— Ciro Santilli 郝海东冠状病六四事件法轮功

@ Circo Tolong katakan secara eksplisit. Aturan untuk mem-posting silang ke situs lain tidak memengaruhi banyak pihak. Tidak perlu bahasa berkabut.

— Alien Kecil

Jawaban:

175

Kebijakan asal yang sama hanya berlaku untuk bahasa pemrograman sisi browser. Jadi jika Anda mencoba memposting ke server yang berbeda dari server asal menggunakan JavaScript, maka kebijakan asal yang sama ikut bermain tetapi jika Anda memposting langsung dari formulir yaitu tindakan menunjuk ke server yang berbeda seperti:

<form action="http://someotherserver.com">

dan tidak ada javascript yang terlibat dalam memposting formulir, maka kebijakan asal yang sama tidak berlaku.

Lihat wikipedia untuk informasi lebih lanjut

— Suresh Kumar
sumber

Maaf menyeret pertanyaan lama, apa yang akan terjadi jika tindakan diubah menggunakan JS tetapi kemudian formulir diposting menggunakan tombol? Apakah itu memungkinkan posting lintas domain berhasil?

— Chris

AFAIK seharusnya tidak menjadi masalah tapi saya belum mencobanya sendiri. Akan menarik untuk mencari tahu.

— Suresh Kumar

Saya memiliki pemikiran yang sama. Saya sebenarnya memiliki kekhawatiran tentang keamanan, beberapa pihak ketiga JS / virus mengubah tindakan untuk mengirim formulir di suatu tempat berbahaya, tetapi menyadari hal ini dapat dilakukan pada setiap pembayaran yang menerima formulir lintas domain atau tidak dan hasilnya akan sama. Pelajaran di sini benar-benar: periksa file JS pihak ketiga;)

— Chris

Singkatnya: YA, POSTING lintas domain diizinkan.

— Christian Davén

-1 untuk: Kebijakan asal yang sama tidak ada hubungannya dengan mengirim permintaan ke url lain (protokol atau domain atau port) yang berbeda, ini semua tentang membatasi akses ke (membaca) data respons dari url lain (dan dengan demikian mencegah javascript untuk memperbarui dokumen dengan formulir yang memiliki token keamanan dari url lain).

— Mohsenme

Dimungkinkan untuk membuat permintaan GET atau POST yang sewenang-wenang dan mengirimkannya ke server apa pun yang dapat diakses oleh browser korban. Ini termasuk perangkat di jaringan lokal Anda, seperti Printer dan Router.

Ada banyak cara membangun eksploitasi CSRF. Serangan CSRF sederhana berbasis POST dapat dikirim menggunakan .submit()metode. Serangan yang lebih kompleks, seperti upload file lintas-situs, serangan CSRF akan mengeksploitasi penggunaan CORS terhadap perilaku xhr.withCredentals .

CSRF tidak melanggar Kebijakan Same-Origin Untuk JavaScrip t karena SOP berkaitan dengan JavaScript yang membaca respons server terhadap permintaan klien. Serangan CSRF tidak peduli dengan responsnya, mereka peduli dengan efek samping , atau menyatakan perubahan yang dihasilkan oleh permintaan, seperti menambahkan pengguna administratif atau menjalankan kode arbitrer di server.

Pastikan permintaan Anda dilindungi menggunakan salah satu metode yang dijelaskan dalam Lembar Curang Pencegahan CSRF OWASP . Untuk informasi lebih lanjut tentang CSRF, lihat halaman OWASP tentang CSRF .

— Mikey
sumber

Saya telah memperbarui pertanyaan saya untuk menjelaskan. Juga, tautan WordPress yang Anda berikan melibatkan eksploit yang dimulai dari dalam asal-X yang sama, daripada dimulai dari lintas-domain Y ... jadi itu bukan skenario yang tepat dari apa yang saya lihat.

— Brent Arias

@Brent Arias ya, apa yang Anda gambarkan dalam 1 dan 2 persis sama dengan apa yang dilakukan serangan CSRF, mungkin Anda harus mencoba mengeksekusi salah satu eksploitasi CSRF yang disediakan dan mengendus lalu lintas. Saya telah memperbarui posting saya, Anda harus membaca setiap tautan yang disediakan karena akan menjawab pertanyaan-pertanyaan ini secara akurat. Inti dari serangan "pemalsuan permintaan lintas situs" (CSRF) adalah permintaan yang berasal dari domain lain, semua eksploitasi yang disediakan sepenuhnya memenuhi persyaratan mendasar ini.

— Mikey

Kebijakan asal yang sama tidak ada hubungannya dengan mengirim permintaan ke url lain (protokol atau domain atau port berbeda).

Ini semua tentang membatasi akses ke (membaca) data respons dari url lain. Jadi kode JavaScript dalam halaman dapat memposting ke domain sewenang-wenang atau mengirimkan formulir dalam halaman itu ke mana saja (kecuali jika formnya dalam iframe dengan url yang berbeda).

Tetapi apa yang membuat permintaan POST ini tidak efisien adalah bahwa permintaan ini tidak memiliki token anti-pemalsuan, sehingga diabaikan oleh url lainnya. Selain itu, jika JavaScript mencoba mendapatkan token keamanan itu, dengan mengirimkan permintaan AJAX ke url korban, itu dicegah untuk mengakses data tersebut dengan Kebijakan Asal yang Sama.

Contoh yang bagus: di sini

Dan dokumentasi yang bagus dari Mozilla: di sini

— Mohsenme
sumber