Web Alanları Arası Form POSTing

Bu konuyla ilgili her yerde (SO dahil) makaleler ve yayınlar gördüm ve geçerli yorum, aynı köken politikasının etki alanları arasında bir form POST'u engellemesidir. Birinin aynı köken politikasının form gönderileri için geçerli olmadığını önerdiğini gördüğüm tek yer burada .

Daha "resmi" veya resmi bir kaynaktan cevap almak istiyorum. Örneğin, RFC'yi aynı kökenli bir formun POST'u nasıl etkilediğini veya etkilemediğini bilen var mı?

açıklama : Bir GET veya POST oluşturulabilir ve herhangi bir alana gönderilip gönderilemeyeceğini sormuyorum. Soruyorum:

1. Chrome, IE veya Firefox, 'Y' alanından gelen içeriğin 'X' alanına bir POST göndermesine izin verirse
2. POST alan sunucu aslında herhangi bir form değeri görürse. Bunu söylüyorum çünkü çevrimiçi tartışmaların çoğunluğu, sunucunun postayı aldığını söyleyen test kullanıcılarını kaydeder, ancak form değerlerinin tümü boş / soyulmuştur.
3. Hangi resmi belge (yani RFC) beklenen davranışın ne olduğunu açıklar (tarayıcıların şu anda ne uyguladığına bakılmaksızın).

Bu arada, eğer aynı kökenli POST'ları etkilemezse - o zaman sahtecilik önleme jetonlarının neden gerekli olduğunu biraz daha açık hale getirir. "Biraz" diyorum çünkü bir saldırganın sahtecilik önleme jetonunu içeren bir formu almak için bir HTTP GET yayınlayabileceğine ve aynı jetonu içeren yasadışı bir POST yapabileceğine inanmak çok kolay görünüyor. Yorumlar?

Aynı kaynak ilkesi yalnızca tarayıcı tarafı programlama dilleri için geçerlidir. Dolayısıyla, JavaScript kullanarak başlangıç ​​sunucusundan farklı bir sunucuya yayınlamaya çalışırsanız, aynı başlangıç ​​politikası devreye girer, ancak doğrudan formdan yayın yaparsanız, yani eylem aşağıdaki gibi farklı bir sunucuya işaret eder:

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

ve formun gönderilmesinde herhangi bir javascript yoktur, aynı menşe politikası uygulanmaz.

Daha fazla bilgi için wikipedia'ya bakın

Rastgele bir GET veya POST isteği oluşturmak ve bunu kurbanların tarayıcısı tarafından erişilebilen herhangi bir sunucuya göndermek mümkündür. Bu, yerel ağınızdaki Yazıcılar ve Yönlendiriciler gibi cihazları içerir.

Bir CSRF sömürüsü oluşturmanın birçok yolu vardır. Yöntem kullanılarak basit bir POST tabanlı CSRF saldırısı gönderilebilir .submit(). Gibi Daha karmaşık saldırılar, siteler arası dosya yükleme CSRF saldırısına sömürecek CORS xhr.withCredentals davranış kullanın .

CSRF, JavaScripti t için Aynı Köken Politikasını ihlal etmez çünkü SOP, JavaScript'in sunucunun bir istemcinin isteğine verdiği yanıtı okumasıyla ilgilidir . CSRF saldırıları yanıtı umursamıyor , istek tarafından üretilen bir yönetimsel kullanıcı ekleme veya sunucuda rasgele kod yürütme gibi bir yan etki veya durum değişikliğine önem veriyorlar .

OWASP CSRF Önleme Hile Sayfasında açıklanan yöntemlerden birini kullanarak isteklerinizin korunduğundan emin olun . CSRF hakkında daha fazla bilgi için CSRF'deki OWASP sayfasına bakın .

Aynı köken politikasının başka bir URL'ye (farklı protokol veya alan veya bağlantı noktası) istek göndermeyle ilgisi yoktur.

Her şey başka bir url'den yanıt verilerine (okuma) erişimi kısıtlamakla ilgilidir. Dolayısıyla, bir sayfadaki JavaScript kodu isteğe bağlı alana gönderebilir veya o sayfadaki formları herhangi bir yere gönderebilir (form farklı URL'ye sahip bir iframe içinde değilse).

Ancak bu POST isteklerini etkisiz hale getiren şey, bu isteklerin antiforgery belirteçlerinden yoksun olması, bu nedenle diğer url tarafından göz ardı edilmesidir. Ayrıca, JavaScript bu güvenlik belirteçlerini almaya çalışırsa, kurban url'sine AJAX isteği göndererek, aynı Köken İlkesi ile bu verilere erişmesi engellenir.

İyi bir örnek: burada

Ve Mozilla'dan iyi bir belge: burada