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

SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama
SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama

Tüm Kayıtlar

Sitenizi Tarayın

Sitenizi bu zafiyete karşı kontrol edin

Otomatik bir tarama başlatın ve sitenizin etkilenip etkilenmediğini görün — sade dille bulgular ve çözümlerle.

Taramaya Başla
Kategori Güvenlik Yanlış Yapılandırması / Erişim Denetimi
Tipik Önem Derecesi Yüksek
OWASP A01:2021 – Bozuk Erişim Denetimi; A05:2021 – Güvenlik Yanlış Yapılandırması
CWE CWE-942 – Güvenilmeyen Etki Alanlarıyla İzin Verici Çapraz Alan Politikası
İlgili Standartlar W3C CORS Spesifikasyonu (Fetch Standard); RFC 6454 (Origin)
Diğer adları CORS joker karakter yanlış yapılandırması, izin verici CORS politikası, ACAO yanlış yapılandırması
Etkilenen sistemler Web API'leri, REST uç noktaları, SPA'lar, CORS yanıt başlıkları gönderen tüm HTTP sunucuları

Genel Bakış

Aynı Kaynak İlkesi (Same-Origin Policy – SOP), bir kaynaktaki (şema + host + port) JavaScript'in farklı bir kaynaktan gelen yanıtları okumasını engelleyen bir tarayıcı güvenlik mekanizmasıdır. WHATWG Fetch Standard'da tanımlanan Cross-Origin Resource Sharing (CORS) protokolü, bu kısıtlamayı kontrollü biçimde gevşetmek için tasarlanmıştır: bir sunucu, Access-Control-Allow-Origin ve ilgili yanıt başlıklarını ayarlayarak hangi yabancı kaynakların yanıtlarını okuyabileceğini açıkça belirtebilir.

CORS yanlış yapılandırması, bir sunucunun çapraz kaynak erişimini gereğinden geniş tuttuğu durumlarda ortaya çıkar; örneğin istenen kaynağı (origin) doğrulamadan yansıtmak, tüm alt etki alanlarını doğrulama yapmadan güvenmek ya da Access-Control-Allow-Origin: * ile Access-Control-Allow-Credentials: true'yu kimliği doğrulanmış yanıtları açığa çıkaracak biçimde birlikte kullanmak gibi. Bir saldırgan, kurbanın tarayıcısını kendi sitesine yönlendirebilirse sunucunun yanıtlarını kurbanmış gibi okuyabilir ve Aynı Kaynak İlkesi'nin sağlamayı amaçladığı korumayı devre dışı bırakabilir.

Nasıl çalışır?

Tarayıcı çapraz kaynak isteği gönderdiğinde, isteğe bir Origin başlığı ekler. Sunucunun CORS politikası, yanıtın isteği yapan betiğe sunulup sunulmayacağını belirler. Yaygın yanlış yapılandırma kalıpları şunlardır:

  • Origin yansıtma: Sunucu gelen Origin başlığını okuyup Access-Control-Allow-Origin olarak aynen geri döndürür ve bunu Access-Control-Allow-Credentials: true ile birleştirir. Bu durumda saldırgan kontrolündeki bir alan dahil her kaynak fiilen güvenilir sayılır.
  • Joker karakter ile kimlik bilgisi: Access-Control-Allow-Origin: * ve Access-Control-Allow-Credentials: true birlikte döndürülür. Tarayıcılar bu kombinasyonu spesifikasyon gereği redderse de bazı sunucu tarafı çerçeveler bu hatayı farkında olmadan yapar; hatalı yapılandırılmış ters proxy'ler ise başlıkları aşağı akışta değiştirebilir.
  • Zayıf origin doğrulaması: Origin değerinin yalnızca güvenilir bir dize içerip içermediği veya o dizeyle bitip bitmediğinin kontrol edilmesi (örneğin example.com); bu yöntem evil-example.com veya notexample.com gibi değerlerle atlatılabilir.
  • Null origin güveni: Origin: null değerine izin vermek; bu değer, korumalı alandaki (sandboxed) iframe'ler, data URI'leri ve belirli yönlendirmeler tarafından gönderilebilir — bunların hepsi saldırgan tarafından kontrol edilebilir.
  • Keyfi alt etki alanlarına güvenmek: *.example.com'a izin vermek, alt etki alanı ele geçirmesi (subdomain takeover) gibi yollarla ele geçirilmiş bir alt etki alanının örtülü olarak güvenilir sayılması sonucunu doğurabilir.

İstismar, basit bir çapraz site isteği kalıbını izler: saldırgan kendi alanında, hedef API uç noktasına istek gönderen, yanıt gövdesini (oturum belirteçleri, kişisel veriler veya iş açısından kritik bilgiler içerebilir) okuyan ve bu veriyi dışarıya sızdıran JavaScript barındırır. Tarayıcı kurbanın çerezlerini isteğe ekleyeceğinden yanıt tamamen kimlik doğrulamalıdır.

İş etkisi

Kimliği doğrulanmış bir uç noktada başarıyla sömürülen bir CORS yanlış yapılandırması şu sonuçlara yol açabilir:

  • Hesap ele geçirme: Yanıtlarda dönen oturum belirteçlerinin, OAuth tokenlarının veya API anahtarlarının çalınması.
  • Hassas veri ifşası: JSON API'lerinden kişisel verilerin, finansal kayıtların, iç yapılandırma bilgilerinin veya fikri mülkiyetin okunması — GDPR, HIPAA, PCI-DSS ve benzeri düzenlemeler kapsamında doğrudan bir ihlal.
  • Yetki yükseltme: Yalnızca ayrıcalıklı rollere açık iç API'lerde, bir yöneticiyi kötü amaçlı bir sayfayı ziyaret etmeye ikna eden saldırgan yöneticiye özel verileri okuyabilir.
  • İtibar ve düzenleyici zarar: Uygulama katmanı yanlış yapılandırmalarından kaynaklanan veri ihlalleri, düzenleyiciler tarafından giderek artan ölçüde incelenmekte ve önemli mali yaptırımları beraberinde getirmektedir.

Nasıl düzeltilir?

  1. Güvenilen kaynaklar için açık bir izin listesi oluşturun. Gelen Origin başlığını, bilinen ve güvenilen kaynakları içeren sunucu tarafı bir kümeyle tam dize eşleştirmesi kullanarak karşılaştırın. Yalnızca alt dize veya sonek denetimlerine güvenmeyin.
  2. İstek Origin başlığını doğrulama yapmadan hiçbir zaman yansıtmayın. Mantık response.setHeader('Access-Control-Allow-Origin', request.headers.origin) şeklinde herhangi bir denetim olmadan işliyorsa dünyadaki her kaynak güvenilir sayılmış demektir.
  3. Üretim uç noktaları için null origin'e izin vermeyin. Açık ve belgelenmiş bir gereklilik olmadıkça null değerini güvenilmez olarak kabul edin.
  4. Joker karakteri (*) yalnızca tamamen açık, kimlik doğrulaması gerektirmeyen kaynaklar için kullanın. Access-Control-Allow-Origin: * ile Access-Control-Allow-Credentials: true'yu hiçbir zaman birlikte kullanmayın.
  5. Access-Control-Allow-Credentials: true'yu yalnızca kesinlikle gerekli olduğunda ve yalnızca Access-Control-Allow-Origin'de doğrulanmış belirli bir kaynakla birlikte ayarlayın.
  6. Access-Control-Allow-Methods ve Access-Control-Allow-Headers değerlerini uygulamanın gerçekten ihtiyaç duyduğu minimum kümeyle sınırlayın.
  7. Access-Control-Allow-Origin değeri dinamik olarak hesaplandığında Vary: Origin yanıt başlığını ekleyin; böylece önbellekler bir kaynağın yanıtını başka bir kaynağa sunmaz.
  8. Uygulama mantığından bağımsız olarak CORS başlıkları ekleyebilen veya geçersiz kılabilen üçüncü taraf kütüphaneleri ve ters proxy yapılandırmalarını (örn. nginx, API ağ geçitleri) denetleyin.
  9. CORS politikalarını sunucu tarafında uygulayın, istemci tarafı kodda değil. Tarayıcı tarafındaki geçici çözümler bir güvenlik denetimi değildir.

Sensagraph, web uygulamalarının sürekli taranması sırasında izin verici ve yanlış yapılandırılmış CORS politikalarını otomatik olarak tespit eder.

Kaynaklar

Sıkça sorulan sorular

Evet. CORS ön kontrol (preflight / OPTIONS) yalnızca basit olmayan isteklere uygulanır; ancak belirli içerik türlerine sahip basit GET ve POST istekleri doğrudan gönderilir. Sunucunun CORS politikası izin verici ise tarayıcı, kullanılan HTTP yönteminden bağımsız olarak yanıt gövdesini isteği yapan betiğe açar.

Doğası gereği tehlikeli değildir. Joker karakter, açık bir CDN veya herkese açık bir veri seti API'si gibi kimlik doğrulaması gerektirmeyen tamamen kamuya açık kaynaklar için güvenlidir. Kimliği doğrulanmış veya kullanıcıya özgü veriler sunan uç noktalar için kullanıldığında ya da tarayıcı isteğe kimlik bilgilerini (çerezler, HTTP kimlik doğrulaması) eklediğinde tehlikeli hale gelir.

Hayır. Sömürü, kurbanın tarayıcısının saldırgan kontrolündeki bir sayfayı ziyaret etmesini ve çapraz kaynak isteğini başlatmasını gerektirir. CORS önlemleri tarayıcı tarafından uygulanır; bu nedenle sunucudan sunucuya istekler etkilenmez. Saldırı vektörü, kullanıcıları saldırganın sitesine yönlendirmek için sosyal mühendislik veya kötü amaçlı reklamlardır.

CORS, bir tarayıcının sunucunun yanıtını çapraz kaynak JavaScript'e sunup sunmayacağını denetler. CSP ise bir sayfanın hangi kaynakları (betikler, stiller vb.) yüklemesine izin verildiğini denetler. İkisi çapraz kaynak güvenliğinin farklı boyutlarını ele alır ve her ikisinin de doğru yapılandırılması gerekir; biri diğerinin yerini alamaz.

Bir sunucu, isteği yapan kaynağa göre Access-Control-Allow-Origin değerini dinamik olarak belirlediğinde yanıt, kaynağa özgü hale gelir. Vary: Origin başlığı, önbelleklere her kaynak için ayrı yanıt kopyası saklamasını bildirir. Bu başlık olmadan bir önbellek, A kaynağına ait bir yanıtı B kaynağına ait bir isteğe sunabilir ve CORS politikasını sessiz sedasız genişletmiş olur.