Yanlış CORS yapılandırmasını kullanmanın üç yolu (aktarım)
Aynı Kaynak Politikası (SOP), uygulamalar arasında bilgi paylaşımını kısıtlar ve yalnızca uygulamayı barındıran alan içinde paylaşıma izin verir. Bu, sistem gizli bilgilerinin sızmasını etkili bir şekilde önler. Ama aynı zamanda başka bir sorunu da beraberinde getiriyor. Web uygulamalarının ve mikro hizmetlerin artan kullanımıyla birlikte, genellikle pratik amaçlar için (örneğin erişim belirteci ve oturum tanımlayıcı) bir alt etki alanından diğerine veya farklı etki alanları arasında bilgi aktarmak gerekir. , Başka bir uygulamaya geçti).
Etki alanları arası iletişime izin vermek için, geliştiricilerin SOP'yi atlamak ve hassas bilgileri iletmek için farklı teknikler kullanması gerekir, böylece bugün zor bir güvenlik sorunu haline gelmiştir. Bu nedenle, uygulamanın güvenlik durumunu etkilemeden bilgi paylaşımını gerçekleştirmek için HTML5'te çapraz kaynak paylaşımı (CORS) tanıtıldı. Ancak problemler de takip eder.Birçok kişi kolaylık sağlamak için varsayılan yapılandırmayı kullanır veya anlamadıkları için yanlış yapılandırmalara sahiptir.
Bu nedenle, bir güvenlik analisti / mühendisi olarak, yanlış yapılandırılmış CORS başlıklarından nasıl yararlanılacağını anlamak çok önemlidir. Bu aynı zamanda felaketleri gerçekleşmeden önce iyileştirmenize de yardımcı olacaktır.
CORS nedir?
CORS bir W3C standardıdır, tam adı "Kaynaklar arası kaynak paylaşımı" dır (Kaynaklar arası kaynak paylaşımı). Tarayıcının bir çapraz kaynak (protokol + etki alanı adı + bağlantı noktası) sunucusuna bir XMLHttpRequest isteği göndermesine izin verir, böylece AJAX'ın yalnızca aynı kaynaktan kullanılabileceği sınırlamasının üstesinden gelir.
CORS, hem tarayıcı hem de sunucu desteği gerektirir. İletişim süreci, kullanıcı müdahalesi olmadan tarayıcı tarafından otomatik olarak yapılır. Geliştiriciler için, CORS iletişimi ile aynı kökene sahip AJAX iletişimi arasında hiçbir fark yoktur ve kod tamamen aynıdır. Tarayıcı AJAX isteğinin çapraz kaynak olduğunu bulduğunda, bazı ek başlık bilgilerini otomatik olarak ekler ve bazen ek bir istek yapılır, ancak kullanıcı bunu hissetmez.
Bu nedenle, CORS iletişimini gerçekleştirmenin anahtarı sunucudur. Sunucu CORS arayüzünü uyguladığı sürece, kaynaklar arasında iletişim kurabilir.
Anahtar CORS başlığı
CORS ile ilgili birçok HTTP üst bilgisi vardır, ancak aşağıdaki üç yanıt başlığı güvenlik için en önemli olanlardır:
Access-Control-Allow-Origin: Hangi etki alanlarının etki alanı kaynaklarına erişebileceğini belirtin. Örneğin, istekci.com, provider.com'un kaynaklarına erişmek isterse, geliştirici bu başlığı, requestester.com'a provider.com kaynaklarına güvenli bir şekilde erişim izni vermek için kullanabilir.
Erişim-Kontrol-İzin Ver-Kimlik Bilgileri: Tarayıcının çerezleri göndermek için istekleri kullanıp kullanmayacağını belirtin. Tanımlama bilgileri, yalnızca allow-credentials başlığı true olarak ayarlandığında gönderilir.
Erişim Kontrolü-İzin Verme Yöntemleri: Kaynaklara erişmek için hangi HTTP istek yöntemlerinin (GET, PUT, DELETE, vb.) Kullanılabileceğini belirtin. Bu başlık, geliştiricilerin, istek sahibi.com, provider.com kaynaklarına erişim istediğinde hangi yöntemlerin etkili olacağını belirleyerek güvenliği daha da artırmasına olanak tanır.
Üç saldırı senaryosu
CORS başlığında yanlış yapılandırılmış joker karakterleri (*) kullanın
En yaygın CORS yapılandırma hatalarından biri, etki alanlarının kaynakları talep etmesine izin vermek için (*) gibi joker karakterlerin yanlış kullanılmasıdır. Bu genellikle varsayılan değer olarak ayarlanır; bu, herhangi bir alanın bu sitedeki kaynaklara erişebileceği anlamına gelir. Örneğin:
GET /api/userinfo.php Ev sahibi: www.victim.com Menşei: www.victim.comYukarıdaki talebi gönderdiğinizde, Access-Control-Allow-Origin başlık setiyle bir yanıt alacaksınız. Aşağıdaki yanıt koduna bakın.
HTTP / 1.0200 Tamam Erişim Kontrolü-İzin Ver-Menşei: * Erişim Kontrolü-İzin Ver-Kimlik Bilgileri: doğruBu örnekte, başlık bir joker karakterle (*) yapılandırılmıştır. Bu, herhangi bir alanın kaynaklara erişebileceği anlamına gelir.
Müşterimizin web uygulamasını test ederken, bu yanlış yapılandırmayı fark ettik. Ad, kullanıcı kimliği, e-posta kimliği gibi kullanıcı bilgilerini elde etmek ve bu bilgileri harici bir sunucuya göndermek için kullanabiliriz. Aşağıdaki şekilde, mağdur etki alanından saldırgan etki alanına Origin isteğini değiştiriyoruz.
Aşağıdaki yanıt, aldığımız yanıttır; bu, kurban alan adının tüm sitelerden kaynaklara erişime izin verdiği anlamına gelir. Saldırı vakamızda Testing.aaa.com web sitesi.
Bu site herhangi bir siteden bilgi paylaştığından, bundan yararlanmak için kendi alan adımızı daha fazla kullanalım. Güvenlik açığı bulunan uygulamalardan gizli bilgileri çalmak için https://testing.aaa.com adında bir etki alanı oluşturduk ve bunu yararlanma koduna yerleştirdik. Kurban tarayıcıda https://testing.aaa.com adresini açtığında, hassas bilgileri alır ve saldırganın sunucusuna gönderir. Aşağıdaki şekilde gösterildiği gibi toplayabileceğimiz bilgiler aşağıdadır.
Kökeni olarak güven etki alanı joker karakterini kullanın
Diğer bir yaygın yanlış yapılandırma, kısmen doğrulanmış alan adlarıyla bilgi paylaşımına izin vermektir. Örneğin, aşağıdaki istek:
GET /api/userinfo.php Barındırıcı: provider.com Menşei: requester.comCevap şu şekildedir:
HTTP / 1.0200 Tamam Erişim Kontrolü-İzin Ver-Menşei: requestester.com Erişim Kontrolü-İzin Ver-Kimlik Bilgileri: doğruGeliştiricinin CORS'u "Kaynak başlık" URL'sini doğrulayacak şekilde yapılandırıp yapılandırmadığını düşünün. Beyaz listedeki alan yalnızca "istek.com" dur. Şimdi, saldırgan şu isteği yaptığında:
GET /api/userinfo.php Barındırıcı: example.com Bağlantı: kapat Menşei: attackerrequester.comSunucu yanıt verecek:
HTTP / 1.0200 Tamam Erişim-Kontrolü-İzin Ver-Menşei: attackerrequester.com Erişim Kontrolü-İzin Ver-Kimlik Bilgileri: doğruBu durumun nedeni yanlış bir arka uç yapılandırması olabilir, örneğin:
eğer ($ _SERVER == '* talep eden.com') { // Verilere erişim else {// yetkisiz erişim} }Bu sorunla bir müşterinin uygulamasında karşılaştık. "Provider.com" ana etki alanı, "attackerrequester.com" gibi "request.com" ana bilgisayar adıyla biten tüm kaynaklara güvenir. Bu nedenle, kaynak başlığını attackerrequester.com olarak değiştiririz ve isteği yürütmeye devam ederiz.
Aşağıdaki yanıtta, aynı kaynak Access-control-Allow-Origin başlığındadır; bu, provider.com etki alanının, requestester.com ile biten etki alanıyla kaynak paylaşımına izin verdiği anlamına gelir.
Bu nedenle beyaz listedeki alan adlarından oluşan yeni bir alan adı oluşturabiliriz. Ardından, kötü amaçlı site, mağdurun sitesinde hassas bilgiler elde etmek için yararlanma kodunun içine yerleştirilir.
CORS kullanımını gerçekleştirmek için XSS kullanın
Geliştiriciler tarafından CORS kullanımına karşı kullanılan bir savunma mekanizması, sıklıkla bilgiye erişim isteyen alanları beyaz listeye almaktır. Ancak bu tamamen güvenli değildir, çünkü beyaz liste etki alanındaki bir alt etki alanı diğer saldırılara (XSS gibi) karşı savunmasız olduğu sürece, CORS da kullanılabilir.
Bir örneğe bakalım, aşağıdaki kod, request.com'un alt etki alanının provider.com'un kaynak yapılandırmasına erişmesine izin verecektir.
eğer ($ _SERVER == '*. istekci.com') { // Verilere erişim else {// yetkisiz erişim} }Kullanıcıların, istek.com yerine sub.requester.com'a erişebileceğini ve sub.requster.com'un XSS saldırılarına açık olduğunu varsayın. Ardından kullanıcılar, provider.com'dan yararlanmak için XSS'yi kullanabilir.
Aynı alan adı üzerinde iki uygulama barındırıyoruz. CORS uygulaması testcors.com adresinde, başka bir uygulama da XSS saldırılarına açık olan pavan.testingcors.com adresinde barındırılmaktadır.
Bu savunmasız XSS alt alanını kullanarak, testcors.com'dan hassas bilgiler elde edebiliriz. "Ad" parametresine kötü amaçlı bir javascript yükü ekledik. Sayfa yüklendikten sonra, komut dosyası çalıştırılacak ve hassas bilgiler testcors.com'dan alınacaktır.
sonuç olarak
CORS, OWASP TOP 10'daki bir güvenlik açığıdır. Siteler arasında bilgi paylaşımını gerçekleştirme sürecinde, insanlar CORS yapılandırmasının önemini göz ardı etme eğilimindedir. Bir geliştirici veya güvenlik uzmanı olarak, bu güvenlik açığını ve bundan nasıl yararlanılacağını anlamak önemlidir.
* Referans kaynağı: we45, FB editör sekisti tarafından derlenmiş, FreeBuf.COM'dan yeniden üretilmiştir
