Çapraz kaynak paylaşımı (Cross-origin resource sharing CORS)

Bu bölümde, çapraz kaynak paylaşımının (Cross-Origin Resource Sharing - CORS) ne olduğunu açıklayacağız,Cross-origin resource sharinge dayalı yaygın saldırı örneklerini tanımlayacak ve bu saldırılara karşı nasıl korunulması gerektiğini tartışacağız. Bu konu, PortSwigger Research ile işbirliği içinde yazılmış olup, "Exploiting CORS misconfigurations for Bitcoins and bounties" adlı sunumlarıyla bu saldırı türüne popülerlik kazandırmışlardır.

​

CORS Nedir?(Cross-origin resource sharing?)​

Çapraz kaynak paylaşımı (CORS), belirli bir etki alanının(Domain) dışındaki kaynaklara kontrollü bir erişime olanak tanıyan bir tarayıcı mekanizmasıdır. Same-origin policy (SOP) esneklik kazandırır. Ancak, aynı zamanda, bir web sitesinin CORS politikası kötü yapılandırılmış ve uygulanmışsa, cross-domain saldırılarının kurbanı olabilir ve Cross site forgery CSRF) gibi cross-origin saldırılarına karşı bir koruma sağlamaz.

Same-origin politikası​

Bir web sitesinin kaynak etki alanının(Domain) dışındaki kaynaklarla etkileşim yapma yeteneğini sınırlayan kısıtlayıcı cross-origin ayarlarıdır. Same-origin politikası, potansiyel olarak kötü niyetli cross-domain etkileşimlerine karşı yıllar önce tanımlanmıştır, Örneğin bir web sitesinin başka bir siteden özel veri çalmasını engeller. Genellikle bir etki alanının (Domain) diğer etki alanlarına(Domain) istek göndermesine izin verir, ancak cevaplara erişmesine izin vermez.

Same-origin politikasının gevşetilmesi​

Same-origin politikası oldukça kısıtlayıcıdır ve bu nedenle kısıtlamaları aşmak için çeşitli yaklaşımlar geliştirilmiştir.

• Pek çok web sitesi, alt alan(sub-domain) adlarıyla veya üçüncü taraf sitelerle, cross-origin access için tam erişim gerektiren bir etkileşime girer.
• Kontrollü bir şekilde same-origin politikasının gevşetilmesi, cross-origin kaynak paylaşımı (CORS) kullanılarak mümkündür.

Cross-origin kaynak paylaşımı protokolü, güvenilir web kökenlerini veya kimlik doğrulamasına izin verilip verilmediği gibi ilişkili özellikleri tanımlayan bir dizi HTTP başlığı kullanır. Bu başlıklar, tarayıcının erişmeye çalıştığı cross-origin alanlı web sitesi arasında bir başlık alışverişi ile yapılır.

CORS yapılandırma sorunlarından kaynaklanan güvenlik açıkları ​

Birçok modern web sitesi, alt alanlardan(sub-domain) veya güvenilir üçüncü taraflardan erişime izin vermek için CORS'u kullanır. Ancak, CORS'un uygulanması veya uyarlanmasında yapılan eksiklikler veya her şeyin düzgün çalışmasını sağlamak için aşırı serbest bırakılmış olabilir ve bu da sömürülebilir güvenlik açıklarına yol açabilir. Bunun sonucunda da saldırganlar tarafından hedef olabilir.

İstemci kaynaklı origin headerından sunucu taraflı üretilen ACAO headerı​

Bazı uygulamaların başka etki alanlarına(Domain) erişim sağlamak zorundadır. İzin verilen etki alanlarının(Domain) bir listesini tutmak ve bunu güncel tutmak, sürekli bir uğraş gerektirir ve herhangi bir hata, çalışan sistemi bozma riski taşır. Bu nedenle bazı uygulamalar, başka herhangi bir etki alanından(Domain) gelen erişimlere izin vermenin kolay yolunu kullanır buda gelen bütün erişimlere izin vermektir.

Bunu yapmanın bir yolu, isteklerden birisi olan Origin başlığını okuyarak ve isteyen kökenin izin verildiğini belirten bir yanıt başlığı ekleyerek gerçekleştirilir.
Örneğin, aşağıdaki isteği alan bir uygulamayı düşünün:


Aşağıda ki sonuç döner;


Bu başlıklar, erişim isteğinde bulunulan alan adından (malicious-website.com) izin verildiğini ve cross-origin isteklerin çerezleri içerebileceğini (Access-Control-Allow-Credentials: true) ve bu nedenle oturumda işleneceğini belirtir.

Uygulama, Access-Control-Allow-Origin üstbilgisinde ki isteğe bağlı kökenleri verdiği için,herhangi bir alan adından, açığı olan alan adında bulunan kaynaklara erişmesine olanak tanır. Yanıt herhangi bir hassas bilgi içeriyorsa, API anahtarını veya CSRF belirteci gibi, aşağıdaki komut dosyasını (Script) web sitenize yerleştirerek bunları alabilirsiniz:

Origin başlıklarını ayrıştırma hataları​

Bir çok kaynaktan erişim sağlanmasını destekleyen bazı uygulamalar, bunu whitelist denilen zararsız olduğunu düşündükleri kaynakların listesini oluşturarak yaparlar. Bir CORS talebi alındığında, sağlanan kaynak bu whitelist denilen listeyle karşılaştırılır. İsteği gönderen kaynak, listede görünüyorsa, erişimin verilmesi için Access-Control-Allow-Origin başlığına yansıtılır. Örneğin, uygulama aşağıdaki gibi normal bir istek alır:


Uygulama, sağlanan kökeni izin verilen kökenler listesiyle karşılaştırır ve eğer listede ise kökeni aşağıdaki gibi yansıtır:


CORS whitelist kontrollerini yaparken sık sık hatalar meydana gelir. Bazı organizasyonlar, henüz var olmayan tüm alt alanlardan(Sub-domain) (kendi alt alanlarını da içeren) erişimlere izin verir. Aynı zamanda, bazı uygulamalar, çeşitli diğer organizasyonların alt alanlarını da içeren alanlara da erişim izini verir. Bu kurallar genellikle URL ön ekleri(prefixes) veya son ekleriyle(suffixes) eşleştirilerek veya düzenli ifadeler kullanılarak uygulanır. Uyarlamada yapılan herhangi bir hata, istenilmeyen farklı alanlara erişim sağlanmasına sebebiyet verebilir.

Örneğin, bir uygulama aşağıdaki gibi biten tüm alanlara erişime izin verirse:


Bir saldırgan, aşağıdaki alanı kaydederek erişime sahip olabilir:


Alternatif olarak, bir uygulama aşağıdaki gibi başlayan tüm alanlara erişime izin verirse:


Bir saldırgan, aşağıdaki alanı kullanarak erişime sahip olabilir:

Beyaz listeye(Whitelist) alınan boş(Null) başlangıç değeri​

Origin tanımlaması, null değerini destekler. Tarayıcılar, çeşitli olağandışı durumlarda Origin başlığında null değerini gönderebilir:

• Cross-origin yönlendirmeler.
• Serileştirilmiş verilerden gelen istekler.
• file: protokolü kullanılarak yapılan istekler.
• Sandboxed cross-origin istekleri.

Bazı uygulamalar, uygulamanın yerel geliştirmesini desteklemek için null kökenini beyaz listeye eklemiş olabilir. Örneğin, bir uygulama aşağıdaki çapraz kökenli isteği alırsa:


Ve sunucu aşağıdaki yanıtı verirse:


Bu durumda, bir saldırgan farklı hileler kullanarak Origin başlığında null değerini içeren bir cross-origin istek oluşturabilir. Bu, beyaz listeyi kandıracak ve cross-domain erişimine yol açacaktır. Örneğin, bu, aşağıda bulunan bir sandboxed iframe cross-origin istek kullanılarak yapılabilir:

CORS güven ilişkilerini kullanarak XSS saldırısını sömürme​

Düzgün bir şekilde yapılandırılmış olsa bile, CORS iki etki alanı arasında bir güven ilişkisi kurmaya yarar. Bir web sitesi, çapraz site komut dosyası (XSS) açığına sahip bir etki alanını listeye eklemişse(Whitelist), saldırgan XSS'i sömürerek bu açığı kullanabilir ve CORS'u kullanarak güvenilen uygulamadan hassas bilgileri alabilir.

Aşağıdaki istek dikkate alındığında:


Sunucu aşağıdaki yanıtı verirse:


O zaman saldırgan, subdomain.vulnerable-website.com üzerinde bir XSS açığı bulursa, aşağıdaki gibi bir URL kullanarak API anahtarını almak için bunu kullanabilir:

Kötü yapılandırılmış CORS ile TLS'nin Kırılması​

HTTPS'yi titizlikle kullanan bir uygulamanın, düz HTTP kullanan güvenilir bir alt etki alanını da listeye(Whitelist) eklediğini varsayalım.
Örneğin, uygulama aşağıdaki isteği aldığında:


Uygulama şu yanıtı verirse:


Bu durumda, bir saldırgan, bir kurban kullanıcının trafiğini yakalayabilecek konumda olduğunda, CORS yapılandırmasını kullanarak kurbanın uygulamayla etkileşimini tehlikeye atabilir. Bu saldırı şu adımları içerir:

• Kurban kullanıcı herhangi bir düz HTTP isteğinde bulunur.
• Saldırgan, aşağıdaki yönlendirmeyi enjekte eder.
• Kod:

  http://trusted-subdomain.vulnerable-website.com

• Kurbanın tarayıcısı yönlendirmeyi takip eder.
• Saldırgan, düz HTTP isteğini yakalar ve aşağıdaki CORS isteğini içeren sahte bir yanıt döndürür:
• Kod:

  https://vulnerable-website.com

• Kurbanın tarayıcısı CORS isteğini, şu kökeni içeren şekilde yapar:
• Kod:

  http://trusted-subdomain.vulnerable-website.com

• Uygulama isteği, listede(Whitelist) olan bir köken olduğu için kabul eder ve istenen hassas verileri yanıt olarak döndürülür.
• Saldırganın sahte sayfası hassas verileri okuyabilir ve bunları saldırganın kontrolündeki herhangi bir alan adına iletebilir.

Bu saldırı, zayıf yapılandırılmış CORS yapılandırmasına sahip olan savunmasız web sitesi dahil, HTTPS kullanılan, hiçbir HTTP uç noktasına sahip olmamasına ve tüm çerezlerin güvenli olarak işaretlendiği bir websitesinde de kullanılabilir.

Kimlik bilgileri olmayan intranetler ve CORS​

Çoğu CORS saldırısı, aşağıdaki yanıt başlığının varlığına dayanır:


Bu başlık olmadan, kurban kullanıcının tarayıcısı çerezlerini göndermeyi reddeder, bu da saldırganın yalnızca kimlik doğrulamasız içeriğe erişim elde edebileceği anlamına gelir ve saldırgan aynı içeriğe doğrudan hedef web sitesine göz atarak kolayca erişebilir.

Ancak, bir saldırganın doğrudan bir web sitesine erişemeyeceği yaygın bir durum vardır: websitesi organizasyonun intranetinin bir parçası olduğunda ve özel IP adres alanında bulunduğunda. İç web siteleri, genellikle harici sitelere göre daha düşük güvenlik standartlarına tabi tutulur ve saldırganların zayıflıkları bulmasına ve daha fazla erişime sahip olmasına olanak tanır.
Örneğin, özel bir ağ içindeki cross-origin bir istek aşağıdaki gibi olabilir:


Ve sunucu şu yanıtı verirse:


Uygulama sunucusu, kimlik bilgileri olmadan herhangi bir kaynaktan gelen kaynak isteklerine güveniyorsa. Özel IP adresi alanındaki kullanıcılar genel internete erişebiliyorsa, intranet kaynaklarına erişmek için kurbanın tarayıcısını proxy olarak kullanarak harici bir siteden CORS tabanlı bir saldırı gerçekleştirilebilir.

CORS tabanlı saldırıları önlemenin etkili yolları​

Web kaynağında hassas bilgiler bulunuyorsa, köken Access-Control-Allow-Origin başlığında uygun şekilde belirtilmelidir.

Yalnızca güvenilir sitelere izin verme​

Belki de açıkça görünüyor olabilir, ancak Access-Control-Allow-Origin başlığında belirtilen kökenler yalnızca güvenilir siteler olmalıdır. Özellikle, çapraz kaynak taleplerinden gelen kaynakları doğrulama olmadan dinamik olarak yansıtmak kolayca saldırganlar tarafından kullanılabilir ve bundan kaçınılmalıdır.

Null değerini beyaz listeye almaktan kaçının​

Access-Control-Allow-Origin başlığında null değerini kullanmaktan kaçınılmalıdır. İç belgelerden gelen Cross-origin kaynak çağrıları ve sandboxed istekler null kökenini belirtebilir. CORS başlıkları, özel ve genel sunucular için güvenilir kökenlere uygun şekilde tanımlanmalıdır.

İç ağlarda wildcards kaçınma​

İç ağlarda wildcards kullanmaktan kaçınılmalıdır. Dahili tarayıcılar güvenilmeyen harici etki alanlarına erişebildiğinde, dahili kaynakları korumak için tek başına ağ yapılandırması yapmak yeterli değildir.

CORS, sunucu tarafı güvenlik politikalarının yerine geçmez​

CORS, tarayıcı davranışlarını tanımlar ve hassas verilerin sunucu tarafı korumasının yerine geçmez - saldırgan doğrudan herhangi bir güvenilir kökenden bir istek oluşturabilir. Bu nedenle, web sunucuları hassas verileri korumak için doğrulama ve oturum yönetimi gibi ek olarak CORS'un düzgün yapılandırılması dışında korumalar uygulamalıdır.


Kaynak: What is CORS (cross-origin resource sharing)? Tutorial & Examples | Web Security Academy



LAB1

Bu web sitesi, tüm kökenlere güvenen güvensiz bir CORS yapılandırmasına sahiptir.
Labı çözmek için, yöneticinin API anahtarını almak için CORS'u kullanan bir JavaScript kodu oluşturun ve kodu saldırı sunucunuza yükleyin. Lab çözüldüğünde, yöneticinin API anahtarını başarıyla gönderdiğinizde labı tamamlamış olursunuz.
Aşağıdaki kimlik bilgilerini kullanarak kendi hesabınıza giriş yapabilirsiniz: wiener: peter(Peter ile : arasında ki boşluğu siliniz.

LAB2

Bu web sitesi, "null" kökenine güvenen güvensiz bir CORS yapılandırmasına sahiptir.
Labı çözmek için, yöneticinin API anahtarını almak için CORS'u kullanan bir JavaScript kodu oluşturun ve kodu saldırı sunucunuza yükleyin. Lab çözüldüğünde, yöneticinin API anahtarını başarıyla gönderdiğinizde lab tamamlanmış olur.
Kendi hesabınıza aşağıdaki kimlik bilgilerini kullanarak giriş yapabilirsiniz: wiener: peter(Peter ile : arasında ki boşluğu siliniz.

LAB3

Bu web sitesi, protokolüne bakılmaksızın tüm alt alanlara güvenen güvensiz bir CORS yapılandırmasına sahiptir.
Labı çözmek için, yöneticinin API anahtarını almak için CORS'u kullanan bir JavaScript kodu oluşturun ve kodu saldırı sunucunuza yükleyin. Lab çözüldüğünde, yöneticinin API anahtarını başarıyla gönderdiğinizde lab tamamlanmış olur.
Kendi hesabınıza aşağıdaki kimlik bilgilerini kullanarak giriş yapabilirsiniz: wiener: peter(Peter ile : arasında ki boşluğu siliniz.

İpucu:Eğer kurbanı "man-in-the-middle" saldırısıyla (MITM) hedef alabilseydiniz, güvensiz bir alt alan bağlantısını ele geçirip, CORS yapılandırmasını sömürmek için kötü amaçlı JavaScript enjekte edebilirdiniz. Ne yazık ki, lab ortamında kurbanı MITM saldırısıyla hedef alamazsınız, bu nedenle alt alana JavaScript enjekte etmek için alternatif bir yöntem bulmanız gerekecek.

LAB4

Bu web sitesi, tüm iç ağ kökenlerine güvenen güvensiz bir CORS yapılandırmasına sahiptir.
Bu labı tamamlamak için birden fazla adım gereklidir. Labı çözmek için, JavaScript kullanarak yerel ağda (192.168.0.0/24, port 8080) bir uç nokta bulun ve ardından bir CORS tabanlı saldırı oluşturmak için bunu kullanarak kullanıcı silin. Lab, kullanıcı "carlos" u sildiğinizde çözülmüş olur.

Not: Üçüncü taraflara saldırmayı önlemek için, güvenlik duvarımız lablar ile keyfi harici sistemler arasındaki etkileşimleri engeller. Labı çözmek için, sağlanan saldırı sunucusunu ve/veya Burp Collaborator'ın varsayılan genel sunucusunu kullanmanız gerekmektedir.