CORS - Ön kontrol taleplerini getirmenin arkasındaki motivasyon nedir?

Kaynaklar arası kaynak paylaşımı , bir web sayfasının XMLHttpRequest'leri başka bir etki alanına ( wikipedia'dan ) yapmasına izin veren bir mekanizmadır .

Son birkaç gündür CORS ile uğraşıyorum ve sanırım her şeyin nasıl çalıştığını iyi anladım.

Benim sorum CORS / ön kontrolün nasıl çalıştığı ile ilgili değil, yeni bir istek türü olarak ön kontroller oluşturmanın arkasındaki nedenle ilgili . A sunucusunun neden gerçek istek (RR) kabul edilip edilmeyeceğini öğrenmek için sunucu B'ye bir ön kontrol (PR) göndermesi gerektiğinin herhangi bir nedenini göremiyorum - kesinlikle B'nin RR'yi kabul etmeden / reddetmesi mümkün olacaktır önceden herhangi bir PR.

Biraz aradıktan sonra bu bilgiyi www.w3.org (7.1.5) adresinde buldum :

Kaynakları, bu belirtim bulunmadan önce belirli kullanıcı aracılarından kaynaklanamayan çapraz kökenli isteklere karşı korumak için, kaynağın bu belirtimin farkında olduğundan emin olmak amacıyla bir ön kontrol isteği yapılır.

Bunun şimdiye kadar anlaşılması en zor olduğunu düşünüyorum. Benim yorum (daha iyi 'en iyi tahmin' olarak adlandırmalıyım) benim sunucu B özelliğinin farkında olmayan C sunucusundan gelen isteklere karşı korumakla ilgilidir.

Birisi lütfen bir senaryoyu açıklayabilir / PR + RR'nin sadece RR'den daha iyi çözdüğü bir sorunu gösterebilir mi?

Ön kontrol talebinin amacına karışmak için biraz zaman harcadım ama sanırım şimdi anladım.

Temel öngörü, ön kontrol isteklerinin bir güvenlik olayı olmamasıdır . Aksine, kuralları değiştirmeyen bir şeydir.

Ön kontrol taleplerinin güvenlikle hiçbir ilgisi yoktur ve CORS bilinciyle şu anda geliştirilmekte olan uygulamalar üzerinde hiçbir etkisi yoktur. Bunun yerine, ön kontrol mekanizması CORS'ın farkında olmadan geliştirilen sunuculara fayda sağlar ve istemci ile sunucu arasında her ikisinin de CORS farkında olduğu bir sağlık kontrolü görevi görür. CORS geliştiricileri, dışarıda asla almayacakları varsayımına dayanan yeterli sunucu bulunduğunu, örneğin her iki tarafın da kaydolmasına izin vermek için ön kontrol mekanizmasını icat ettikleri bir alanlar arası DELETE isteği olduğunu hissettiler. Etki alanları arası çağrıları etkinleştirmek için kullanılacak alternatifin çok fazla mevcut uygulamayı bozacağını hissettiler.

Burada üç senaryo var:

1. Eski sunucular, artık geliştirilme aşamasındadır ve CORS'den önce geliştirilmiştir. Bu sunucular hiçbir zaman alamayacakları varsayımlarda bulunabilir, örneğin bir etki alanları arası DELETE isteği. Bu senaryo, ön kontrol mekanizmasının birincil faydalanıcısıdır. Evet, bu hizmetler zaten kötü amaçlı veya uygunsuz bir kullanıcı aracısı tarafından kötüye kullanılabilir (ve CORS bunu değiştirmek için hiçbir şey yapmaz), ancak CORS'lı bir dünyada ön kontrol mekanizması ekstra bir 'sağlık kontrolü' sağlar, böylece istemciler ve sunucular çünkü web'in altında yatan kurallar değişti.

2. Hala geliştirilme aşamasında olan, ancak çok eski kod içeren ve alanlar arası bir dünyada düzgün çalıştığından emin olmak için tüm eski kodları denetlemenin mümkün / arzu edilmeyen sunucuları. Bu senaryo, sunucuların aşamalı olarak CORS'a kaydolmasına izin verir, örneğin "Şimdi bu özel üstbilgiye izin vereceğim", "Şimdi bu özel HTTP fiiline izin vereceğim", "Şimdi çerezlere / yetkilendirme bilgilerinin "gönderilen vb uçuş öncesi mekanizmadan Bu senaryo yararlanır.

3. CORS bilinciyle yazılmış yeni sunucular. Standart güvenlik uygulamalarına göre, sunucu, gelen herhangi bir istek karşısında kaynaklarını korumalıdır - sunucular, istemcilerin kötü amaçlı şeyler yapmamalarına güvenemez. Bu senaryo ön kontrol mekanizmasından faydalanmaz : ön kontrol mekanizması, kaynaklarını düzgün şekilde koruyan bir sunucuya ek güvenlik sağlamaz.

Ön kontrol taleplerini getirmenin arkasındaki motivasyon neydi?

Ön kontrol istekleri, tarayıcının belirli istekleri göndermeden önce CORS uyumlu bir sunucuyla uğraştığından emin olabilmesi için tanıtıldı. Bu talepler, hem potansiyel olarak tehlikeli (durum değiştiren) hem de yeni ( Aynı Köken Politikası nedeniyle CORS'den önce mümkün olmayan ) olarak tanımlandı. Ön kontrol isteklerinin kullanılması, sunucuların CORS tarafından mümkün kılınabilecek yeni, potansiyel olarak tehlikeli istek türlerine kaydolmasını (ön kontrole düzgün yanıt vererek) anlamına gelir.

Spesifikasyonun bu bölümünün anlamı şudur: "Kaynakları, bu spesifikasyon mevcut olmadan belirli kullanıcı aracılarından kaynaklanamayan çapraz kökenli taleplere karşı korumak için, kaynağın bu spesifikasyonun farkında olmasını sağlamak için bir ön kontrol talebi yapılır."

Bana bir örnek verebilirmisin?

Bir tarayıcı kullanıcısının bankacılık sitesinde oturum açtığını düşünelim A.com. Kötü amaçlı yazılımlara gittiklerinde B.com, bu sayfada DELETEistek göndermeye çalışan bazı Javascriptler bulunur A.com/account. Kullanıcı oturum açtığından A.com, bu istek gönderilirse kullanıcıyı tanımlayan çerezleri içerir.

CORS'den önce, tarayıcının Aynı Köken Politikası bu talebin gönderilmesini engellemiş olurdu. Ancak CORS'un amacı sadece bu tür çapraz kökenli iletişimi mümkün kılmak olduğundan, bu artık uygun değildir.

Tarayıcı olabilir basitçe göndermek DELETEve sunucu bunu nasıl işleneceğine karar verelim. Peki ya A.comCORS protokolünün farkında değilse? Devam edebilir ve tehlikeli olanı idam edebilir DELETE. Tarayıcının Aynı Köken Politikası nedeniyle asla böyle bir talep alamayabileceğini ve dolayısıyla böyle bir saldırıya karşı hiç sertleştirilmemiş olabileceğini varsaymış olabilir.

Bu tür CORS farkında olmayan sunucuları korumak için, protokol tarayıcının önce bir ön kontrol isteği göndermesini gerektirir . Bu yeni istek, tarayıcının aslını göndermenin güvenli olup olmadığını bilmesini sağlayan, yalnızca CORS bilinçli sunucuların düzgün yanıt verebileceği bir şeydir DELETE.

Neden tarayıcı ile ilgili tüm bu karışıklık, saldırgan sadece DELETEkendi bilgisayarından bir istek gönderemez ?

Elbette, ancak böyle bir istek kullanıcının çerezlerini içermez. Bunun önlenmesi için tasarlanan saldırı, tarayıcının isteğin yanı sıra diğer etki alanı için çerezler (özellikle kullanıcı için kimlik doğrulama bilgileri) göndermesine bağlıdır.

Yediğim sesler xsrf sitesi bir form, B.comkutu POSTiçin A.comve kullanıcının kurabiye zarar verir.

Doğru. Bunu ifade etmenin bir başka yolu, ön kontrol isteklerinin CORS farkında olmayan sunucular için CSRF saldırı yüzeyini artırmayacak şekilde oluşturulmuş olmasıdır.

Ancak ön kontrol gerektirmeyen "basit" isteklerin gereksinimlerine baktığımda, buna POSThala izin verildiğini görüyorum . Bu durum gibi değişebilir ve verileri silebilir DELETE!

Bu doğru! CORS sitenizi CSRF saldırılarına karşı korumaz. Sonra tekrar, CORS olmadan CSRF saldırılarına karşı da korunmazsınız. Ön kontrol taleplerinin amacı, CSRF maruziyetinizi CORS öncesi dünyada var olanlarla sınırlamaktır.

İç çekmek. Tamam, isteksizce ön kontrol taleplerini kabul ediyorum. Ancak bunu sunucudaki her kaynak (URL) için neden yapmalıyız? Sunucu ya CORS işlemektedir ya da işlemez.

Bundan emin misin? Birden fazla sunucunun tek bir etki alanı için istekleri işlemesi nadir değildir. Örneğin, isteklerin A.com/url1bir tür sunucu A.com/url2tarafından işlenmesi ve isteklerin farklı bir tür sunucu tarafından işlenmesi söz konusu olabilir. Genellikle tek bir kaynağı işleyen sunucunun söz konusu etki alanındaki tüm kaynaklar için güvenlik garantisi sağlayabilmesi söz konusu değildir.

İnce. Uzlaşalım. Sunucunun tam olarak hangi kaynaklarla konuşabileceğini belirtmesine izin veren yeni bir CORS başlığı oluşturalım, böylece bu URL'lere ek ön kontrol isteklerinden kaçınılabilir.

İyi bir fikir! Aslında, başlık Access-Control-Policy-Pathsadece bu amaç için önerildi. Nihayetinde, görünüşe göre , bazı sunucular URI spesifikasyonunu, tarayıcıya güvenli görünen yollara taleplerin aslında kırık sunucularda güvenli olmayacağı şekilde yanlış uyguladığı için , spesifikasyonun dışında bırakıldı .

Bu, performans üzerindeki güvenliği önceliklendiren ve tarayıcıların mevcut sunucuları riske atmadan CORS spesifikasyonunu hemen uygulamasına izin veren ihtiyatlı bir karar mıydı? Yoksa sadece belirli bir sunucudaki hataları barındırmak için bant genişliğini boşa harcamak ve gecikmeyi iki katına çıkarmak için inandırıcı değil miydi?

Görüşler farklı.

Peki, tarayıcılar en azından ön kontrolleri tek bir URL için önbelleğe alacak mı?

Evet. Muhtemelen çok uzun sürmese de. WebKit tarayıcılarında maksimum ön kontrol önbellek süresi şu anda 10 dakikadır .

İç çekmek. Sunucularımın CORS uyumlu olduğunu ve bu nedenle ön kontrol isteklerinin sunduğu korumaya ihtiyaç duymadığını biliyorsam, bunlardan kaçınmamın bir yolu var mı?

Tek gerçek seçeneğiniz, "basit" isteklerin gereksinimlerini karşıladığınızdan emin olmaktır . Bu, başka türlü ekleyebileceğiniz (beğenebileceğiniz X-Requested-With), hakkında yalan söyleme Content-Typeveya daha fazlası gibi özel başlıkları dışarıda bırakmak anlamına gelebilir .

Ne yaparsanız yapın, CORS belirtimi güvensiz de dahil olmak üzere "basit" istekleri reddetmeyi ele almadığından, uygun CSRF korumasına sahip olduğunuzdan emin olmalısınız POST. Spesifikasyonda belirtildiği gibi : "basit taleplerin geri çağrılmanın dışında önemi olan kaynaklar kendilerini Siteler Arası İstek Sahteciliğinden korumalıdır".

CORS'den önce web alanları arası isteklerin dünyasını düşünün. Standart bir POST formu yapabilir scriptveya imagebir GET isteği yayınlamak için a veya etiketi kullanabilirsiniz. GET / POST dışında başka bir istek türü yapamazsınız ve bu isteklerde özel bir başlık veremezsiniz.

CORS'un ortaya çıkmasıyla birlikte, spesifik yazarlar, web'in mevcut semantiğini bozmadan yeni bir etki alanları arası mekanizma getirme zorluğu ile karşı karşıya kaldılar. Bunu, sunuculara herhangi bir yeni istek türüne kaydolma yolu vererek yapmayı seçtiler. Bu katılım, ön kontrol talebidir.

Bu nedenle, herhangi bir özel üstbilgisi olmayan GET / POST isteklerinin ön kontrol gerektirmez, çünkü bu istekler CORS'den önce zaten mümkün olmuştur. Ama özel başlıklarını veya PUT / DELETE istekleri ile herhangi bir talebe yok bu CORS Spec için yeni olduğundan, bir ön kontrol gerekir. Sunucu CORS hakkında hiçbir şey bilmiyorsa, CORS'ye özgü üstbilgiler olmadan yanıt verir ve gerçek istek yapılmaz.

Ön kontrol isteği olmadan, sunucular tarayıcılardan beklenmeyen istekler görmeye başlayabilir. Bu tür sunucular için sunucular hazırlanmadıysa bu bir güvenlik sorununa yol açabilir. CORS ön kontrol, web alanları arası isteklerin web'e güvenli bir şekilde sunulmasına izin verir.

CORS, çapraz başlangıçlı <img src>veya ile daha önce mümkün olandan daha fazla başlık ve yöntem türü belirtmenize olanak tanır <form action>.

Bazı sunucular (ör. Çapraz kaynak DELETEtalebi veya X-Requested-Withbaşlıklı çapraz kaynak talebi gibi) bir tarayıcının yapamayacağı varsayımı ile (kötü bir şekilde) korunmuş olabilir , bu nedenle bu tür talepler "güvenilir" dir.

Sunucunun gerçekten CORS'i gerçekten desteklediğinden ve yalnızca rastgele isteklere yanıt vermediğinden emin olmak için ön kontrol yürütülür.

Kod kullanarak ona bakmanın başka bir yolu:

<!-- hypothetical exploit on evil.com -->
<!-- Targeting banking-website.example.com, which authenticates with a cookie -->
<script>
jQuery.ajax({
  method: "POST",
  url: "https://banking-website.example.com",
  data: JSON.stringify({
    sendMoneyTo: "Dr Evil",
    amount: 1000000
  }),
  contentType: "application/json",
  dataType: "json"
});
</script>

CORS öncesi, yukarıdaki istismar girişimi aynı menşe politikasını ihlal ettiği için başarısız olacaktır. Bu şekilde tasarlanmış bir API, tarayıcının yerel güvenlik modeli tarafından korunduğu için XSRF korumasına ihtiyaç duymadı. Bir CORS öncesi tarayıcının çapraz kökenli bir JSON POST oluşturması imkansızdı.

Şimdi CORS sahneye çıkıyor - uçuş öncesi CORS'a katılma gerekmiyorsa, aniden bu sitenin kendi hatası olmadan büyük bir güvenlik açığı olacaktı.

Bazı isteklerin uçuş öncesi neden atlamasına izin verildiğini açıklamak için, bu özellik spec tarafından cevaplandırılır:

Basit bir çapraz kökenli istek, bu spesifikasyona uymayan halihazırda konuşlandırılmış kullanıcı aracıları tarafından oluşturulabilecek isteklerle uyumlu olarak tanımlanmıştır.

Bunu çözmek için, GET, 7.1.5 ile tanımlandığı gibi "basit bir yöntem" olduğu için önceden yayınlanmaz. (Uçuş öncesi kaçınmak için başlıklar da "basit" olmalıdır). Bunun gerekçesi, "basit" çapraz kaynaklı GET isteğinin örn. Tarafından gerçekleştirilebileceğidir <script src="">(JSONP bu şekilde çalışır). Bir srcniteliğe sahip herhangi bir öğe, uçuş öncesi olmadan çapraz kökenli bir GET'i tetikleyebileceğinden, "basit" XHR'lerde ön mücadele gerektirmenin güvenlik yararı olmazdı.

Diğer cevapların, dövüş öncesi güvenliği artırmanın nedenine odaklanmadığını hissediyorum.

Senaryolar:

1) Uçuş öncesi . Kullanıcı safe-bank.com olarak doğrulanırken bir saldırgan dummy-forums.com sitesinden bir istekte bulunur
. Sunucu başlangıç ​​noktasını kontrol etmezse ve bir şekilde bir kusuru varsa, tarayıcı bir uçuş öncesi isteği, OPTION yöntem. Sunucu, CORS hiçbirini tarayıcının yanıt olarak beklediğini bilmez, böylece tarayıcı ilerlemez (herhangi bir zarar vermez)

2) Uçuş öncesi olmadan . Saldırgan yukarıdaki isteği aynı senaryo altında düzenler, tarayıcı POST veya PUT isteğini hemen yayınlar, sunucu kabul eder ve işleyebilir, bu muhtemelen bazı zararlara neden olur.

Saldırgan doğrudan, çapraz kökenli bir istek gönderirse, rasgele bir ana bilgisayardan büyük olasılıkla kimlik doğrulaması olmayan bir istek düşünür. Bu sahte bir istek, ancak xsrf değil. sunucu kimlik bilgilerini kontrol eder ve başarısız olur. Beyaz listenin bu saldırı vektörünü azaltmaya yardımcı olabilmesine rağmen, CORS istekleri için kimlik bilgileri olan bir saldırganı engellemeye çalışmaz.

Uçuş öncesi mekanizması, istemciler ve sunucular arasında güvenlik ve tutarlılık sağlar. Önbellek kullanımı mümkün olduğundan, bu her istek için ekstra el sıkışma değerinde olup olmadığını bilmiyorum, ama böyle çalışır.

Ayrıca, kullanıcı verileri üzerinde yan etkilere neden olabilecek HTTP istek yöntemleri için (özellikle GET dışındaki HTTP yöntemleri veya belirli MIME türleriyle POST kullanımı için), tarayıcıların isteği "ön kontrol etmesini" zorunlu kılar

Kaynak

Sunucudaki durumu değiştirebilecek istekler için uçuş öncesi istekler gereklidir. 2 tür istek vardır -

1) Sunucudaki durumu değiştiremeyen çağrılar (GET gibi) - Kullanıcı istek için bir yanıt alabilir (sunucu başlangıç ​​noktasını kontrol etmezse), ancak istekte bulunan etki alanı yanıt başlığına Access-Control- Allow-Origin, tarayıcı verileri kullanıcıya göstermez, yani istek tarayıcıdan gönderilir, ancak kullanıcı yanıtı görüntüleyemez / kullanamaz.

2) Sunucudaki durumu değiştirebilen çağrılar (POST, DELETE gibi) - 1'den beri), tarayıcının isteği engellemediğini, ancak yanıtı, durum değiştiren çağrıların önceden kontrol edilmeden yapılmasına izin verilmemesi gerektiğini görüyoruz. . Bu tür çağrılar, tarayıcıya yanıt bir hata olsa bile, çağrıların kökenini kontrol etmeyen (Siteler Arası İstek Sahteciliği olarak adlandırılır) güvenen bir sunucuda değişiklikler yapabilir. Bu nedenle, herhangi bir durum değiştiren çağrının sunucuya gönderilmesinden önce SEÇENEK çağrısı yapan uçuş öncesi talepler konseptimiz vardır.

Performansla ilgili ön talep edilen talepler değil ? Önceden gelen istekler ile, bir müşteri büyük miktarda veri göndermeden önce işleme izin verilip verilmediğini hızlı bir şekilde bilir, örneğin PON yöntemiyle JSON'da. Veya hassas verileri kablo üzerinden kimlik doğrulama başlıklarında gezmeden önce.

Özel başlıkların yanı sıra PUT, DELETE ve diğer yöntemlerin gerçeğine varsayılan olarak izin verilmez ("Erişim-Denetim-İstek-Yöntemleri" ve "Erişim-Denetim-İstek-Üstbilgileri" ile açıkça izin almaları gerekir) tıpkı bir çift kontrol gibi, çünkü bu işlemlerin GET istekleri yerine kullanıcı verileri üzerinde daha fazla etkisi olabilir. Yani, kulağa şöyle geliyor:

" Http: //foo.example adresinden siteler arası isteklere izin verdiğinizi gördüm , AMA SİLME isteklerine izin vereceğinizden emin misiniz? Bu isteklerin kullanıcı verilerinde neden olabileceği etkileri düşündünüz mü?"

Ön ödemeli isteklerle eski sunucuların yararları arasında belirtilen korelasyonu anlamadım. CORS'den önce veya bir CORS farkındalığı olmadan uygulanan bir Web Hizmeti, HERHANGİ BİR siteler arası istek almaz, çünkü ilk olarak yanıtlarında "Erişim-Kontrol-İzin Ver-Kökeni" başlığı bulunmaz.

CORS'i destekleyen bir tarayıcıda, okuma istekleri (GET gibi) zaten aynı menşe politika tarafından korunuyor: Kimliği doğrulanmış bir etki alanları arası istekte bulunmaya çalışan kötü amaçlı bir web sitesi (örneğin kurbanın internet bankacılığı web sitesine veya yönlendiricinin yapılandırma arayüzüne) banka veya yönlendirici Access-Control-Allow-Originüstbilgiyi ayarlamadığından, döndürülen verileri okuyabilir .

Ancak, yazı ile isteklerinde (POST gibi), istek web sunucusuna ulaştığında hasar verilir. * Bir web sunucusu Origin, isteğin yasal olup olmadığını belirlemek için başlığı kontrol edebilir, ancak web sunucusunun her ikisinin de gerekmediği için bu denetim genellikle uygulanmaz CORS için veya web sunucusu CORS'den daha eskidir ve bu nedenle web alanları arası POST'lerin aynı menşe politika tarafından tamamen yasaklandığını varsaymaktadır.

Bu nedenle web sunucularına etki alanları arası yazma isteklerini alma şansı verilir .

_{* Esasen CSRF'nin AJAX versiyonu.}