CORS (Cross-Origin Resource Sharing) Yanlış Yapılandırmaları



Bu yazıda, CORS (Cross-Origin Resource Sharing) olayını nedir ne değildir? CORS yanlış yapılandırılmasında neler olur? ve bir bypass'a neden olabilecek en yaygın hataları açıklamaya çalışacam. Başlayalım isterseniz.
Ama Corstan önce Javascriptlerle ilgili açıklamam gereken bir olay var. Şöyle ki; Güvenlik nedeniyle, bir alanda çalışan JavaScript'in yalnızca bu alandan verileri okuyabilmesi çok önemlidir. Bu tür kısıtlamalar olmasaydı, bu blogdaki küçük bir JavaScript snippet'i Facebook'a kolayca yeni bir sekme açabilir ve tüm özel mesajlarınızı veya başka herhangi bir içeriği okumamızı sağlayabilirdi.
Bu nedenle, JavaScript'in (ve diğer komut dosyalarının) yalnızca istek göndermesine ve isteğin kaynaklandığı alandaki verileri okumasına izin verilir. Böylece, JavaScript'te barındırıldığı etki alanına bir istek yapan ve verileri okuyan bir işlev yazmak mümkündür.  Veriler doğrudan web sayfasında görüntülenmek yerine JavaScript'te işlenir.
Önbilgiyi verdikten sonra CORS olayını açıklamaya başlayalım. Bununla birlikte, diğer alanlara istek gönderme meşru kullanım durumları vardır. Örneğin, herkesin sorgulamasını sağlayan ve dolayısıyla herhangi bir alanda JavaScript'in kendilerine istek göndermesine izin vermesi gereken genel API'ler vardır. Bu gibi durumlarda, diğer alanlara istek gönderebilmeniz gerekir. Bu isteklere kolay çözüm olarak CORS devreye girmektedir.
Kısacası, CORS, web sunucusu tarafından ayarlanan bir başlıktır. Tam olarak hangi istekleri kendisine göndermesine izin verildiğini düzenler.  [Mozilla'nın MDN web dokümanlarında](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) daha fazla ayrıntı bulabilirsiniz .

Peki Aklımıza gelen soru şu: Bunu bir güvenlik zafiyeti yapan olay ne?

CORS'ları yanlış bir şekilde yapılandırmak kötü niyetli biri tarafından kontrol edilen bir etki alanının etki alanımıza istek göndermesini sağlar. Yolladığı istek ile etki alanımızda ki hassas verileri okuyabilir.

Origin Yansıtma olayı

Tarayıcı her etki alanı isteğinde bulunduğunda (başka bir etki alanına istek) bir başlangıç ??başlığı ekler. Bu başlık, talebin kaynaklandığı alanın değerine sahiptir, hemen hemen başvuru başlığı gibi. https://attacker.com/test.html adresindeki JavaScript isteği yaparsa, değer https://attacker.com olacaktır.
Bazı web siteleri bu değeri doğrudan istek yapmasına izin verilen bir etki alanı olarak ayarlar. Bunu yapmak, CORS'un amacını tamamen geçersiz kılar, çünkü herhangi bir etki alanı artık kendi etki alanımıza istek gönderebilir.
Bu, birkaç etki alanı için bir CORS politikasını otomatikleştirme girişimi ve alanın kendisi için kökenleri yanlış anlamanın bir sonucu olarak ortaya çıkabilir. Bazı durumlarda, güvenlik açığı, geride bırakılan geliştirme sırasında kullanılan temiz bir bypass'tan sağlanılır.

Insufficient regular expression (Yetersiz düzenli ifade)

Yukarıdaki örneğe benzer şekilde, bazı web siteleri yanıtta kullanmadan önce kökeni [normal ifadelere](https://www.computerhope.com/jargon/r/regex.htm) göre kontrol eder . Web sitesi herhangi bir alt etki alanının web sitesine isteklerde bulunmasına izin vermek istiyorsa, şuna benzer bir kontrol gerçekleştirir:


Burada origin ozan.example.com ise sunucu tarafından izin verilen origin olarak devam edecek ve sunucuda çalışacaktır. Şimdi burada saldırı mantığımız şu şekilde; düzenli ifadelerde nokta etkilemiyor. Eğer noktayı belirtmek istiyorsa (\.) kullanması gerekir.. Eğer saldırgan ozanexample.com adlı etki alanını satın alırsa burda da CORS zafiyetinden yararlanabilir.

Üçüncü Parti Uygulamaları ile CORS

Herkesin JavaScript'i yükleyebileceği bir sürü üçüncü taraf alan adı var. JSBin . com ve CodePen.io birçok örnekten sadece ikisidir. Bazen bu alanlar talepte bulunabilecekleri şekilde yapılandırılmıştır. Bu durumda birçok neden olmasına rağmen, tam etki büyük olasılıkla unutulur. Bir saldırgan bu web sitelerine kötü amaçlı JavaScript yükleyebilir ve bu JavaScript daha sonra yanlış yapılandırılmış alandan veri gönderip okuyabilir. 

Amazon S3 Bypass

Yukarıdaki örneğe benzer şekilde, Amazon S3 sunucularında barındırılan uygulamalara bazen izin verilir. Site sahibi, Amazon'da barındırılan ve web sitesiyle etkileşime girmesi gereken bir uygulamaya sahiptir. Bunu yapmak için, işletme sahibi herhangi bir S3 sunucusuna talepte bulunmasına izin vermeye karar verir. Bu durumda, saldırganın yapması gereken tek şey kendi S3 sunucusuna kaydolmak ve kötü niyetli sayfayı barındırmaktır.

Bir yazının daha sonuna geldik. Aklınıza gelen sorular olursa sorabilirsiniz. Eğer eksik kaldığım yer olmuşsa - hatamız olmuşsa Affola. Başka bir yazıda görüşmek üzere...:)

Yorumlar

Bu blogdaki popüler yayınlar

Bazı JavaScript Kütüphaneleri Ve Zafiyetleri

NASA Reflected XSS Write Up

Herşey Bir Tırnakla Başladı