CORS yanlış yapılandırma güvenlik açıkları, son derece hafife alınmış bir güvenlik açığı sınıfıdır. Hassas bilgi açıklamasından SSRF saldırılarını kolaylaştırmaya kadar değişen bir etki ile, bu müşteri tarafı güvenlik açığı her zaman güvenlik testinizin bir parçası olmalıdır.
Bu makalede, gelişmiş CORS yanlış yapılandırma güvenlik açıklarının tanımlanmasını ve sömürülmesini araştıracağız. Ayrıca, dahili ana bilgisayarlardan okuma yanıtlarını okuma gibi çapraz orijin kaynak paylaşımını yanlış yapılandırmalarını silahlandırmamıza yardımcı olabilecek birkaç saldırı vektörünü de inceleyeceğiz!
Hadi dalalım!
Bugünün uygulamaları giderek daha karmaşık hale geliyor ve çoğu üçüncü taraf kökenlerine işlev görmesi için bağlantı gerektiriyor. Örneğin, hedefinizde bir uygulaması olabilir app.example.com ve bir API api.example.com Arka uçlara bağlanmak için. Varsayılan olarak, tarayıcılar bu çapraz orijin taleplerini aynı orijin politikası (SOP) aracılığıyla kısıtlar.
Aynı Origin Politikası (SOP)
SOP, bir kökenteki belgelerin veya komut dosyalarının başka bir kaynaktan kaynaklarla nasıl etkileşime girebileceğini sınırlar. Ancak hedef uygulamanız (app.example.com) hala API’ya yeni HTTP bağlantıları oluşturması gerekiyor (api.example.com). Cors burada devreye giriyor.
Çapraz Origin Kaynak Paylaşımı (CORS)
Bir CORS politikası, geliştiricilerin SOP kısıtlamalarını seçici olarak gevşetmelerine ve kontrollü çapraz orijin taleplerine izin vermelerini sağlar. Bu, Access-Control-Allow-Origin Ve Access-Control-Allow-Credentials Yanıt başlıkları. Yukarıda belirtilen iki Cors başlığının yanı sıra, geliştiricilerin çapraz orijin istekleri ile gönderilmesine izin verilen istek başlıklarını veya HTTP yöntemlerini dikte etmesine izin veren birkaç kişi daha vardır.
Erişim-Kontrol-Ilaz-Origin
. Access-Control-Allow-Origin Hangi üçüncü taraf kökenlerinin kaynağınıza erişmesine izin verildiğini beyan etmenizi sağlar.
Çapraz orijin istekleri gönderdiğinizde, web tarayıcınız otomatik olarak ekler Origin HTTP isteğinizde başlık isteyin. Web sunucuları bu istek başlığını okuyabilir ve orijinini bir izin listesine göre kontrol edebilir.
Kökeniniz beyaz listeye alınmışsa, kökeni Access-Control-Allow-Credentials Web tarayıcısına, bu üçüncü taraf menşeli çapraz orijin taleplerinin izin verildiğini belirten yanıt üstbilgisi.
Başarılı bir çapraz orijin isteği örneği
Aksi takdirde, isteğinizi CORS yanıt başlıklarını içermeyen bir isteğinizi reddeder.
Uçuş öncesi istekleri
Web tarayıcıları ayrıca kimlik bilgilerini içeren gerçek istekten önce bir ‘uçuş öncesi’ isteği gönderme eğilimindedir. Uçuş öncesi talebin ana işi, orijin gerçek isteği göndermeyi önlemek (ve sunucu tarafındaki istenmeyen değişiklikleri tetiklemek) için bir bağlantı kurmaya yetkili olup olmadığını doğrulamaktır.
Önlük istekleri ile pratikte CORS’a genel bakış
Wildcard Origin
Joker karakter (*) herhangi bir menşe izin vermek için belirtilebilir. Bu seçenek ile birlikte kullanılamaz Access-control-allow-credentials: true. Bu makalenin ilerleyen saatlerinde, bu senaryonun neden genellikle göz ardı edilemez davranışların bir göstergesi olduğunu öğreneceğiz.
Null kökenli
Sıkı bir köken veya joker belirlemenin yanı sıra, ‘null‘Anahtar kelime aynı zamanda geçerli bir CORS Politikası Direktifidir. Bu önerilmese de, bazı sunucular yine de Access-Control-Allow-Origin.
Tarayıcınız Origin Başlık isteyin null Hiyerarşik olmayan bir şemadan talepte bulunurken data: veya file:) veya kum havuzu belgelerinden.
Bu makalenin ilerleyen saatlerinde, bu senaryoyu nasıl sömürülebilir bir saldırı vektörüne dönüştüreceğini araştıracağız.
Erişim-Kontrol-Ille-Credtients
. Access-Control-Allow-Credentials Başlık, başarılı bir CORS sömürü saldırısı yapan veya kıran yanıt üstbilgisidir. Bu başlık, sunucunun çapraz orijin isteğinde kimlik bilgilerini iletip iletmeyeceğini belirler. Etkinleştirildiğinde, tarayıcı oturum kimlik bilgilerini ileteceğinden, kimlik doğrulamalı bir kullanıcı olarak ormanlık bir istekte bulunabilmeliyiz.
Kimlik bilgileri şunları içerebilir:
Özetlemek gerekirse, geliştiriciler CORS politikasını aşırı izin verdiğinde, CORS’un hassas bilgi açıklamalarına dönüşebileceğimiz yanlış yapılandırma güvenlik açıklarına yol açabilir. Nasıl olduğunu keşfedelim!
CORS yanlış yapılandırma güvenlik açıkları, aşırı izin veren CORS politikalarından kaynaklanır ve güvenilmeyen kökenlerin (örneğin bir saldırganın web sitesi) güvenilir kökenlerden (örneğin hedefiniz) verileri bağlamasına ve getirmesine izin verir.
CORS yanlış yapılandırma güvenlik açıklarını görselleştirmemize daha iyi yardımcı olmak için basit bir örneğe bakalım!
Savunmasız bir kod snippet örneği
Yukarıdaki şekilde, profil faturalandırma verilerini döndüren tek bir API yolu fark edebilirsiniz. Ek olarak, başlangıç isteği herhangi bir talepte sağlanırsa CORS başlıkları da iade edilir. Geliştiricinin bu durumda yaptığı bir hata, Origin istek başlığının uygunsuz doğrulanmasıdır.
Doğrulamayı tamamen atlamak ve yanıtı almak için güvenilir bir siteyi içeren bir başlangıçtan basit bir istek gönderebiliriz:
GET /api/account/billing HTTP/2
Host: api.example.com
Origin: https://attacker.comCORS yanlış yapılandırma güvenlik açıklarını belirlemek her zaman bir CORS politikasının belirlenip belirlenmediğini kontrol etmekle başlar. Daha sonra, kimlik bilgisi yönlendirme etkinleştirilirse not almalıyız.
Bir hedefin CORS’u destekleyip desteklemediğini test etmek için en belirgin yaklaşım, önce olası güvenilir bir kökene sahip bir talep göndermektir. Origin: Başlık isteyin ve CORS politikası yansımalarının yanıtı inceleyin. Mevcut bir kez, potansiyel doğrulama kusurları arayarak başlayabiliriz.
UÇ! Öyle Access-Control-Allow-Credentials katılmak false? Bir kimlik doğrulama duvarının arkasına hassas verileri almak, kimlik bilgilerini manuel olarak geçirmenizi gerektirir ve gerçekçi sömürü senaryolarını olası hale getirir. Herhangi bir güvenlik açığı raporu göndermeden önce her zaman bir kavram kanıtı bulmaya çalışın!
Basit bir savunmasız kod snippet’inin başka bir örneğine bakalım:
Savunmasız bir kod snippet örneği
Yukarıdaki snippet’i analiz ederek gözlemleyebiliriz Hat 7 Geliştiricinin, gelen orijin istek başlığının yetersiz doğrulanmasını gerçekleştirmesi. Bu basit CORS yanlış yapılandırma kırılganlığından yararlanmak, sadece kökenimizi güvenilir bir kökene sahip olmamızı gerektirir.
Uygulamada, bu konsept kanıtımızı şu konularda barındırmamız gerektiği anlamına gelir: trusted-origin.attacker.com.
GET /api/account/billing HTTP/2
Host: api.example.com
Origin: https://trusted-origin.attacker.com
Cookie: ...
Mağdur, Kavram Kanıtı sayfasını ziyaret ettikten sonra, üçüncü taraf kökenimizden bir HTTP talebi, kurban adına API uç noktasının içeriğine erişecektir. Bu basit CORS yanlış yapılandırma sorunu artık yüksek şiddetli duyarlı bilgi açıklamasına dönüştürülmüştür.
Hala orijinal talepler yapmak için zayıf doğrulamaları aktif olarak atlayacağımız daha gelişmiş durumlara geçelim!
Zayıf Regex patern doğrulamalarını atlamak
CORS yanlış yakınlaştırmalarını önlemenin doğru yolu, izin verilen kökenlerin katı bir beyaz listesini korumaktır. Bununla birlikte, uygulama içindeki çapraz orijin talepleri genellikle her zaman öngörülebilir olmadığından, geliştiriciler çalışmalarını basitleştirme ve yalnızca kaynağın bir kısmını doğrulama eğilimindedir ve buna dayanarak, CORS başlıklarını yansıtmayacağına karar verirler.
Yukarıdaki kod snippet’inde, ince bir yük değişikliğinin doğrulamayı atlamamıza ve gevşek bir şekilde tükenmiş bir Regex deseni nedeniyle sunucu CORS başlıklarını döndürmemize izin verebileceğini gözlemleyebiliriz: https://examplexcom
İşte deneyebileceğiniz daha fazla potansiyel baypas listesi:
# Basic payload list
* # Non-exploitable case
null
https://attacker.com
# More advanced list
https://example.comattacker.com
https://example.com.attacker.com
https://example.computer
https://attacker.comexample.com
https://examplecom
https://localhostexample.com # In case 'localhost' is whitelisted
https://subdomain-takeover.example.com # In case of a subdomain takeover
# Special characters (browser-specific payloads)
https://example.com%attacker.com # Requires setting up a wildcard so that all subdomains resolve for attacker.com
https://[email protected] # Requires setting up a wildcard so that all subdomains resolve for attacker.com
https://example.com`.attacker.com # Safari-only - Requires setting up a wildcard so that all subdomains resolve for attacker.comUÇ! Bu URL Doğrulama Bypass hile sayfası By Portswigger, daha gelişmiş kalıp tabanlı doğrulamaları atlamanıza yardımcı olacak yararlı bir kaynaktır!
Null kökenli
Belirli durumlarda, beyaz liste ile karşılaşacaksınız. null direktif. Daha önce belgelediğimiz gibi, web tarayıcıları null Yerel dosyalardan veya kum havuzu belgelerinden yapılan HTTP isteklerinin kaynağı.
Aşağıdaki kavram kanıtı, esasen bir HTTP isteği göndermenize izin verecektir. null Origin:
Savunmasız uygulama şu şekilde yanıt verirse:
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: truePotansiyel olarak hassas kullanıcı verilerini ortaya çıkararak kimlik bilgileriyle kum havuzu isteğine izin verilecektir.
Beyaz liste üçüncü taraf kökenleri
Test amacıyla, bulut tabanlı kodlama platformlarının (geçici olarak) beyaz liste olması durumunda. Bu nedenle, yaygın olarak kullanılan web geliştirme platformlarını test etmek ve herhangi bir kişinin beyaz liste olup olmadığını görmek her zaman iyi bir fikirdir.
İşte tanınmış üçüncü taraf ana bilgisayarların küçük bir listesi:
https://github.io
https://stackblitz.com
https://codepen.io
https://jsfiddle.netYukarıdaki kökenlerden herhangi biri beyaz liste ise, konsept kanıtınızı aynı platformda barındırmanız gerekir.
CORS ile yalnızca iç kaynaklara erişme
İlginç bir şekilde, CORS yanlış yapılandırmaları bazı bağlamlarda SSRF saldırılarına yükseltilebilir. Bir saldırganın sadece iç kaynakların yanıtlarını toplamak için kavramın kanıtını oluşturduğunu ve kurbana gönderdiğini varsayalım.
Bu senaryo, saldırganın, ihtiyaç duymadan bile dahili bir ana bilgisayarın yanıtını okumasına izin verecektir. Access-Control-Allow-Credentials etkinleştirilmiş.
CORS yanlış yakınlaştırmalarının etkisini hafife almak üzücü bir hata olabilir. Bu basit müşteri tarafı güvenlik açığı türü, bu makalede belgelediğimiz gibi birkaç ciddi risk getirebilir.
Yani, Cors’un yanlış yapılandırma güvenlik açıkları hakkında yeni bir şey öğrendiniz … şu anda, becerilerinizi test etme zamanı! Savunmasız laboratuvarlarda pratik yaparak başlayabilir veya … Intigriti’deki 70+ genel hata ödül programlarımıza göz atabilirsiniz ve belki de bir sonraki gönderiminizde bir ödül kazanın!
Bugün Intigriti’de hacklemeye başlayın