Kötü amaçlı kodun CORS'dan yararlanmak için "Origin" başlığını taklit etmesini ne engelleyecek?

143

Anladığım kadarıyla, foo.com'dan bir sayfada çalışan bir istemci tarafı komut dosyası bar.com'dan veri talep etmek isterse, istekte üstbilgiyi belirtmeli Origin: http://foo.comve bar ile yanıt vermelidir Access-Control-Allow-Origin: http://foo.com.

Roh.com sitesinden gelen kötü amaçlı kodun, çubuktan Origin: http://foo.comsayfalar istemek için üstbilgiyi taklit etmesini engellemek için ne var ?

— Jay Lamont
kaynak

Asıl mesele şu ki, sayfanın sunulduğu orijinal etki alanı (burada foo.com) Access-Control-Allow-Originüstbilgiyi sağlamak zorunda, aksi takdirde tarayıcı isteğe izin vermiyor bar.com.

— Chris Hayes

Okumak, bu yazı gerçekten tarayıcı, özgün sunucu ve hedef sunucu arasındaki cors sürecin benim anlayış yardımcı oldu. html5rocks.com/en/tutorials/cors

— brendonparker

@ChrisHayes CORS hiç böyle çalışmıyor. Spesifikasyona veya konuyla ilgili bu harika MDN wiki sayfasına bakarak bunu biraz daha okuyabilirsiniz .

— Ray Nicholus

@brendonparker Evet, bu harika bir makale. Bu yazar, SO ile ilgili birçok CORS sorusunu yanıtlıyor ve ayrıca enable-cors.org'u da sürdürüyor .

— Ray Nicholus

@RayNicholus İlginç, açık bir şekilde uzaktım. Bağlantılar için teşekkürler. Yorumuma verilen oylara bakılırsa, bu yanılsama altında acı çeken tek kişi ben değilim. Umarım bu ikisi geri gelir ve öğrenir (ve oylarını alır!).

— Chris Hayes

Yanıtlar:

149

Tarayıcılar, Originüstbilgiyi ayarlama konusunda kontrol sahibidir ve kullanıcılar bu değeri geçersiz kılamaz. Böylece Originüstbilginin bir tarayıcıdan aldatıldığını görmezsiniz . Kötü niyetli bir kullanıcı, Originbaşlığı manuel olarak ayarlayan bir curl isteği oluşturabilir , ancak bu istek bir tarayıcının dışından gelir ve tarayıcıya özgü bilgilere (çerezler gibi) sahip olmayabilir.

Unutmayın: CORS güvenlik değildir. Sitenizin güvenliğini sağlamak için CORS'a güvenmeyin. Korumalı veriler sunuyorsanız, Originbu verilerin güvenliğini sağlamak için tanımlama bilgileri veya OAuth jetonları veya başlık dışında başka bir şey kullanın. Access-Control-Allow-OriginCORS kökenleri çapraz menşe istekte bulunmaya izin verilmelidir sadece dikte başlık. Daha fazlası için ona güvenmeyin.

— monsur
kaynak

Bu çok mantıklı. Tarayıcı JavaScript'in Origin başlığını geçersiz kılmasına izin vermiyorsa, sorun yoktur. Tarayıcının dışından istekleri yerine getiriyorsanız, çerezlere sahip olmayacaksınız. Ben hiçbir yerde bu Kökeni başlığı açıkça dedin, ben çünkü okuyordum dokümanlar tümünde karıştı tahmin edemedi geçersiz kılınan olun. Teşekkürler!

— Jay Lamont

Birisi bir şeyi aldatmak isterse, bunu yapabilir. Hemen hemen tüm betik dillerini kullanarak http istekleri oluşturabilirler. Perl ve Python, bunu oldukça kolaylaştıran http kitaplıklarına sahiptir. Kitaplıklar tanımlama bilgilerini saklar ve gönderir, rastgele başlıklar eklemenize izin verir ve bol miktarda hata ayıklama bilgisi verir. Dolayısıyla, CORS başlıkları, tarayıcınızda her ikisine de giriş yaptığınızda, başka bir etki alanındaki banka hesabınıza kötü bir şey yapmak için okuduğunuz bir forumdaki kötü amaçlı javascript'i zorlaştırmak içindir.

— Mnebuerquo

Ve sadece açıklığa kavuşturmak için, kötü niyetli kullanıcı, Origin başlığını manuel olarak kontrol etmelerine izin vermek için yama uygulanmış bir tarayıcı örneği oluşturabilir ve ardından normal bir kullanıcıyı, çerezleri, AJAX'ı ve hepsini mükemmel şekilde taklit edebilir.

— Ürdün Rieger

"Tarayıcılar, Origin başlığını ayarlama denetimindedir ve kullanıcılar bu değeri geçersiz kılamaz." Eminim, istek tarayıcıdan çıktığında başlıkları değiştirmek için Fiddler2 veya Charles gibi bir araç kullanmak çok kolaydır.

— Asa

Kötü niyetli kullanıcı, Origin başlığını manuel olarak kontrol etmelerine izin vermek için yamalanmış bir tarayıcı örneği oluşturabilir.Makineye 'basitçe yamalı bir tarayıcı örneği oluşturabileceğiniz' noktaya erişiminiz varsa (aslında kulağa o kadar basit gelmiyor bana), neden çerezleri doğrudan diskten okumuyorsunuz? Bildiğiniz düz metin olarak saklanırlar. Gerçek hayatta, siteler arası komut dosyası oluşturma gerçek bir tehdittir, oysa saldırı senaryonuz sadece uydurma ve pratik değildir.

— Stijn de Witt

TLDR: Kötü amaçlı kodun kaynağını aldatmasını engelleyen hiçbir şey yoktur. Bu olduğunda, sunucunuz bundan asla haberdar olmayacak ve isteklere göre hareket edecektir. Bazen bu istekler pahalıdır. Bu nedenle, herhangi bir güvenlik türü yerine CORS kullanmayın.

Son zamanlarda CORS ile oyun oynuyorum ve kendime aynı soruyu sordum. Bulduğum şey, tarayıcının sahte bir CORS isteğini gördüğünde bilecek kadar akıllı olabileceği, ancak sunucunuzun o kadar akıllı olmadığı.

Bulduğum ilk şey, Originbaşlığın programla değiştirilemeyen HTTP yasaklı bir başlık adı olduğuydu. Bu , Google Chrome için Başlıkları Değiştir'i kullanarak yaklaşık 8 saniye içinde değiştirebileceğiniz anlamına gelir .

Bunu test etmek için iki İstemci alanı ve bir Sunucu alanı kurdum. Sunucuya, İstemci 1'den CORS isteklerine izin veren ancak İstem 2'den gelen CORS isteklerine izin veren bir CORS beyaz listesi ekledim. Her iki istemciyi de test ettim ve aslında İstemci 1'in CORS istekleri, İstemci 2 başarısız olurken başarılı oldu.

Sonra İstemci 2'nin Originbaşlığını İstemci 1'lerle eşleşecek şekilde aldattım. Sunucu sahte Originüstbilgiyi aldı ve beyaz liste denetimini başarıyla geçti (veya bardağın yarısı boş bir adamsanız başarısız oldu). Bundan sonra, Sunucu tüketmek üzere tasarladığı tüm kaynakları (veritabanı aramaları, pahalı e-postalar, daha da pahalı sms mesajları gönderme vb.) Tüketerek görev bilinciyle gerçekleştirdi. Bu yapıldığında, sunucu sahte Access-Control-Allow-Originbaşlığı tarayıcıya memnuniyetle geri gönderdi .

Okuduğum belgeler, Access-Control-Allow-Originalınan Origindeğerin istekte gönderilen değerle tam olarak eşleşmesi gerektiğini belirtiyor . Eşleştiler, bu yüzden Chrome'da aşağıdaki mesajı gördüğümde şaşırdım:

XMLHttpRequest yüklenemiyor http://server.dev/test. 'Access-Control-Allow-Origin' başlığı, http://client1.dev sağlanan orijine eşit olmayan bir değere sahip. http://client2.dev Bu nedenle menşe erişimine izin verilmiyor.

Okuduğum belgeler doğru görünmüyor. Chrome'un ağ sekmesi, hem isteği hem de yanıt başlıklarını olduğu gibi açıkça gösterir http://client1.dev, ancak Chrome'un bir şekilde gerçek kaynağı bildiğini http://client2.devve yanıtı doğru bir şekilde reddettiğini görebilirsiniz. Bu noktada önemli değil çünkü sunucu sahte isteği çoktan kabul etmiş ve paramı harcamıştı.

— nocturno
kaynak

@Nocturno, örnek için teşekkürler. Sadece gözlemimi ekleyeyim. CORS, tarayıcı güvenlik özellikleriyle ilgilidir. Güvenli bir tarayıcı bozulmamış durumundan değiştirilirse, bu, tarayıcının muhtemelen bir güvenlik özelliğinden yoksun olduğu şeklinde yorumlanabilir.

— Luka Žitnik

Hiç de parlak değil. CORS noktasını tamamen ıskalıyor. Kullanıcının makinesinden gelen istekleri yakalayacak konumdaysanız, çerezlerini okuyabilir, keylogger'lar, virüsler ve diğer tüm gerçek tehditleri yükleyebilirsiniz. CORS, A sitesinde oturum açmış dürüst kullanıcıları, bir şekilde B sitesine enjekte edilen kötü amaçlı bir komut dosyasından korumak için vardır. A sitesindeki oturum çerezini kullanarak, kullanıcının hesabı altında A sitesinde gerçekleştirilen eylemler (örneğin, öğeleri silme vb.)

— Stijn de Witt

Bu, siteler arası komut dosyası oluşturma olarak adlandırılır ve CORS olmadan, kullanıcının makinesini kontrol etmeye gerek kalmadan yapılabilir. Bütün mesele bu. Kullanıcının makinesi üzerinde herhangi bir kontrole gerek yoktu çünkü A sitesine istekte bulunurken tarayıcı, oturum çerezini isteğe otomatik olarak eklerdi, böylece aslında başka bir komut dosyasından geliyorsa, kullanıcının kendisinden geçerli bir istek gibi görünüyordu. bir site. Same-Origin politikası bunu engeller ve CORS, farklı bir kaynaktan olsalar bile erişim izni verilmesi gereken alanları beyaz listeye almak için kullanılır.

— Stijn de Witt

@Nocturno Evet, belki biraz fazla kabaydım, bunun için üzgünüm. Asıl amacınız geçerli. Same-Origin politikası bir tarayıcı güvenlik özelliğidir ve CORS, bazı alanları beyaz listeye alarak bu güvenliği zayıflatan bir mekanizmadır. OP'nin Origin başlığını aldatmanın bir 'saldırı' olarak gerçekten uygun olmadığını anlaması gerekir, çünkü size örneğin curl ile elde edilemeyecek hiçbir şey getirmez.

— Stijn de Witt

@Nocturno Açılış konuşmanızın biraz yanıltıcı olduğunu düşünüyorum. There's nothing stopping malicious code from spoofing the origin-> Evet var, javascript ayarlanamıyor Origin. Evet, bir kullanıcı tarayıcısını değiştirebilir / kökenini değiştirmek için kemancı kullanabilir, ancak CORS'nin savunduğu şey bu değil; saldırgan tarafından kontrol edilen web siteleri , asıl önemli olan Köken'i değiştiremez.

— RJFalconer

Sadece mütevazı bir özet:

S: Aynı Kaynak Politikası (SOP) yalnızca tarayıcılar tarafından mı uygulanıyor?
A: Evet. Bir tarayıcı içinde yaptığınız tüm aramalarda, SOP kesinlikle tarayıcı tarafından uygulanır. Sunucu, talebin kaynağını kontrol edebilir veya kontrol etmeyebilir.

S: Bir istek SOP ile uyumlu değilse, tarayıcı onu engelliyor mu?
C: Hayır, tarayıcıların yetkisinin ötesinde. Tarayıcılar sadece çapraz orijinli istekler gönderir ve aramanın sunucu tarafından Access-Control- * başlıkları aracılığıyla okunaklı olup olmadığını görmek için yanıtı bekler . Sunucu Access-Control-Allow-Originbaşlığı geri göndermiyorsa , arayanın kaynağını geri göndermiyorsa veya *başlıkta geri göndermiyorsa , tarayıcının yapacağı tek şey, arayan kişiye yanıtı vermekten kaçınmaktır.

S: Adres sahteciliği yapamayacağım anlamına mı geliyor Origin?
C: Tarayıcıda ve komut dosyası kullanırken Origin, tarayıcının kontrolünde olduğu için geçersiz kılamazsınız. Ancak, kendinizi hacklemek istiyorsanız, tarayıcınızdan gelen aramaları, tarayıcı uzantılarını veya makinenize yüklediğiniz diğer araçları kullanarak kurcalayabilirsiniz. Ayrıca verebilir HTTPkullanarak çağrı curl, Python, C#vb ve değiştirmek Originhüner sunucularına başlığını.

S: Öyleyse değiştirerek sunucuyu kandırabilirsem , bu güvenli olmadığı Originanlamına CORSmı gelir ?
C: CORS Kendiliğinden güvenlik konusunda sessizdir - yani taleplerin kimlik doğrulaması ve yetkilendirilmesi. İstekleri incelemek ve tanımlama bilgileri ve başlıklar gibi birlikte çalıştıkları herhangi bir mekanizma ile bunları doğrulamak / yetkilendirmek sunuculara bağlıdır. Bunu söyledikten sonra, XSS gibi saldırılar durumunda bizi biraz daha koruyabilir:

Örnek: Diyelim ki web sitenizde oturum açtınız ve kötü amaçlı bir komut dosyası, bakiyenizi sorgulamak için bankanızın web sitesine bir istek göndermeye çalışıyor: Yansıyan XSS saldırısı. Bankanızın web sitesi, web sitenizden (burada adına) gelen kimlik bilgilerine güvenir, böylece istek doğrulanır ve HTTPkötü amaçlı koda yönelik bir yanıt verilir. Bankanızın web sitesi uç noktalarını diğer kaynaklarla paylaşmayı umursamıyorsa, içermezAccess-Control-Allow-Originyanıtta başlık. Şimdi, istek geldiğinde, tarayıcı isteğin Cross Origins isteği olduğunu fark eder, ancak yanıt, sunucunun kaynağı (burada denge sorgusu uç noktası) web sitenizle paylaşmaktan memnun olduğunu göstermez. Böylece akışı keser, dolayısıyla döndürülen sonuç asla kötü amaçlı koda ulaşmaz.

— Alireza
kaynak

Kabul edilen cevaptan güzel, daha iyi / daha net IMO

— 3dGrabber