Hızlı cevap: CORS yanlış yapılandırması (Cross Origin Resource Sharing), bir web uygulamasının farklı kaynaklardan gelen isteklere hangi izinleri verdiğini gevşek tanımlaması sonucu, saldırgan sitesinin kurbanın oturumuyla hassas veriye erişebilmesidir. En sık hata, sunucunun isteği gönderen kaynağı olduğu gibi yansıtıp aynı zamanda kimlik bilgisiyle erişime izin vermesidir. Bu durumda saldırganın sitesi, giriş yapmış kullanıcının tarayıcısı üzerinden API'ye kimlikli istek atıp yanıtı okuyabilir. Kök çözüm, izin verilen kaynakları sunucu tarafında katı bir beyaz liste ile sabitlemek, kimlikli erişimi yalnızca gerçekten gerekli ve güvenilen kaynaklara açmak ve joker izinleri kimlik bilgisiyle birlikte asla kullanmamaktır.

Tarayıcılar, bir sitenin başka bir kaynağın verisini izinsiz okumasını Same Origin Policy ile engeller. CORS, bu kuralı bilinçli ve kontrollü biçimde gevşetmenin resmi yoludur. Ama yanlış yapılandırıldığında, korumayı sağlayan mekanizmanın kendisi bir açığa dönüşür. Bu yazı, CORS'un nasıl çalıştığını, tipik yapılandırma hatalarını ve doğru savunmayı anlatır.

CORS nasıl çalışır

Bir tarayıcı, farklı bir kaynağa istek attığında sunucu yanıtındaki izin başlıklarına bakar. Sunucu, Access Control Allow Origin başlığıyla hangi kaynağın yanıtı okuyabileceğini, Access Control Allow Credentials başlığıyla da kimlik bilgisiyle erişime izin verilip verilmediğini bildirir. Tarayıcı bu başlıklara güvenerek yanıtı JavaScript'e açar ya da engeller.

Sorun, sunucunun bu izinleri fazla cömert vermesidir. En kritik kombinasyon, sunucunun gelen kaynağı sorgusuz yansıtması ile kimlikli erişime izin vermesinin bir arada olmasıdır.

Tipik CORS yapılandırma hataları

Hata Ne yapıyor Neden tehlikeli
Kaynağı yansıtma Gelen origin'i olduğu gibi Allow Origin yapar Her site güvenilir sayılır
Joker artı kimlik Allow Origin joker, Allow Credentials açık Kimlikli veriyi herkese açar
null kaynağına güven null origin'e izin verir Sandbox iframe ile atlatılır
Zayıf alan eşleştirme Alan adını gevşek karşılaştırır Benzer alan adı ile atlatma

Kaynağı yansıtıp kimlikli erişime izin vermek, pratikte Same Origin korumasını tümüyle kaldırmakla eşdeğerdir.

Gerçek etki

CORS yanlış yapılandırması tek başına bir açık kapı değildir, kurbanın oturumu üzerinden çalışır. Kullanıcı saldırganın sitesindeyken, o site kurbanın tarayıcısı üzerinden hedef API'ye kimlikli istek atar ve yanıtı okur. Etki şunlar olabilir:

  • Hassas veri okuma. Profil, e posta, token gibi bilgiler saldırgan sitesine sızar.
  • Kimlik ve token çalma. Yanıt içindeki oturum ya da API anahtarı ele geçirilebilir, bu da hesap ele geçirmeye gidebilir.
  • Zincirleme saldırı. CORS ile okunan bir CSRF token'ı, CSRF korumasını atlatmakta kullanılabilir.
  • API anahtarı ifşası. Yanıtta dönen gizli anahtarlar saldırgana açılır.

CORS, CSRF ve XSS farkı

Bu üç web açığı sık karıştırılır ama farklıdır. CSRF kurbana istenmeyen bir eylem yaptırır ama yanıtı okuyamaz. CORS yanlış yapılandırması ise saldırganın yanıtı okumasını sağlar. XSS ise kurbanın sitesinde kod çalıştırır. CORS açığı, XSS olmadan da hassas veriyi sızdırabildiği için hafife alınmamalıdır.

Doğru savunma

1. Katı beyaz liste

İzin verilen kaynaklar sunucu tarafında sabit bir listede tutulmalıdır. Gelen kaynak bu listeyle tam eşleşiyorsa izin verilir, aksi halde reddedilir. Gelen origin asla sorgusuz yansıtılmamalıdır.

2. Kimlikli erişimi daraltma

Access Control Allow Credentials yalnızca gerçekten gerekli ve güvenilen kaynaklar için açılmalıdır. Joker Allow Origin ile kimlik bilgisi birlikte asla kullanılmamalıdır, tarayıcılar da bunu yasaklar ama sunucu tarafında da bilinçli engellenmelidir.

3. Tam alan doğrulama

Kaynak karşılaştırması alt dize değil, tam eşleşme olmalıdır. Benzer görünen ama saldırgana ait bir alan adı eşleşmemelidir.

4. null ve gereksiz izinlere kapatma

null kaynağına güvenilmemeli, gerekmeyen metotlar ve başlıklar açılmamalıdır. En az izin ilkesi CORS için de geçerlidir.

KAOS ile CORS taraması

DSET'in yerel yapay zekâ güvenlik motoru KAOS, CORS yapılandırmasını kanıt temelli test eder. Farklı kaynak, null ve alt alan adı vektörleriyle sunucunun izin başlıklarını dener, kaynağı yansıtma ile kimlikli erişim birlikteliğini tespit eder ve bir yapılandırmanın gerçekten hassas veriyi çapraz kaynağa açıp açmadığını kontrollü biçimde doğrular. Yalnızca gerçekten istismar edilebilir yapılandırmayı, yanlış pozitif gürültüsü olmadan raporlar. Böylece güvende sandığınız bir API'nin başka bir sitenin kullanıcı oturumuyla veri okumasına izin verip vermediğini net görürsünüz.

Sık sorulan sorular

Allow Origin joker kullanıyorum ama kimlik bilgisi göndermiyorum, güvende miyim? Kimlikli erişim kapalıysa risk çok daha düşüktür, çünkü saldırgan kurbanın oturumuyla veri okuyamaz. Yine de herkese açık yanıtlarda hassas bilgi bulunmadığından emin olun. Asıl tehlikeli kombinasyon, joker ya da yansıtma ile kimlikli erişimin bir arada olmasıdır.

CORS'u tarayıcı zaten uygulamıyor mu, neden sunucuda uğraşayım? CORS kararını sunucu verir, tarayıcı yalnızca uygular. Sunucu gevşek izin verirse tarayıcı da o izne uyar. Bu yüzden güvenlik sunucu tarafındaki yapılandırmadadır.

CORS açığı XSS kadar tehlikeli mi? Bağlama göre değişir. CORS yanlış yapılandırması, XSS olmadan hassas veriyi çapraz kaynağa sızdırabilir. Kimlikli erişim açıksa etki çok ciddidir. Her ikisi de öncelikli olarak giderilmelidir.

Kaynaklar

Web uygulamanızın ve API'nizin CORS yapılandırmasını, çalışan bir kanıtla test ettirmek için DSET ile iletişime geçin. Ankara Hacettepe Teknokent laboratuvarımızdan sızma testi ve güvenli kod denetimi sağlıyoruz.