* **Şirketinizi HackTricks'te reklamını görmek istiyorsanız** veya **HackTricks'i PDF olarak indirmek istiyorsanız** [**ABONELİK PLANLARI**]'na göz atın (https://github.com/sponsors/carlospolop)!
* **Katılın** 💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) veya bizi **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)** takip edin.**
* **Hacking püf noktalarınızı paylaşarak PR'lar göndererek HackTricks** (https://github.com/carlospolop/hacktricks) ve [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github depolarına katkıda bulunun.
Çapraz Kaynak Kaynak Paylaşımı (CORS) standardı**sunucuların varlıklarına kimin erişebileceğini** ve **harici kaynaklardan hangi HTTP istek yöntemlerinin izinli olduğunu tanımlamasına olanak tanır**.
**Aynı köken** politikası, bir **kaynağı isteyen sunucunun** ve **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ı etki alanı ve porttan web sayfalarının kaynaklara erişmesine izin verilir.
Bu başlık **çoklu kökenlere**, bir **`null`** değerine veya bir joker **`*`** değerine izin verebilir. Ancak, **hiçbir tarayıcı çoklu kökenleri desteklemez** ve joker `*` kullanımı**sınırlamalara** tabidir. (Joker yalnız kullanılmalıdır ve `Access-Control-Allow-Credentials: true` ile birlikte kullanımına izin verilmez.)
Bu başlık, tarayıcının otomatik olarak bir `Origin` başlığı eklediği bir web sitesi tarafından başlatılan çapraz etki alanı kaynak isteğine sunucu tarafından **verilir**.
**Varsayılan olarak**, çapraz köken istekler, çerezler veya Yetkilendirme başlığı gibi kimlik bilgileri olmadan yapılır. Ancak, bir çapraz etki alanı sunucusu, kimlik bilgileri gönderildiğinde yanıtın okunmasına izin vererek `Access-Control-Allow-Credentials` başlığını**`true`** olarak ayarlayabilir.
Belirli koşullar altında çapraz alan isteği başlatılırken, örneğin **standart olmayan bir HTTP yöntemi** kullanılarak (HEAD, GET, POST dışında herhangi bir şey), yeni **başlıklar** tanıtılarak veya özel bir **Content-Type başlık değeri** kullanılarak, bir ön uçu isteği gerekebilir. Bu ön hazırlık isteği, **`OPTIONS`** yöntemini kullanarak, sunucuyu gelecek çapraz kökenli isteğin niyetleri hakkında bilgilendirir, kullanmayı planladığı HTTP yöntemleri ve başlıklar dahil.
**Çapraz Köken Kaynak Paylaşımı (CORS)** protokolü, bu ön uçu kontrolünü zorunlu kılar, istenilen çapraz kökenli işlemin uygunluğunu doğrulayarak, izin verilen yöntemleri, başlıkları ve kökenin güvenilirliğini kontrol eder. Bir ön uçu isteğine gerek olmadığını belirleyen koşullar hakkında detaylı bilgi için [**Mozilla Developer Network (MDN)**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests) tarafından sağlanan kapsamlı kılavuza başvurun.
**Ön uçu isteğinin olmamasının yanı sıra yanıtın yetkilendirme başlıklarını taşıma gerekliliğini ortadan kaldırmadığını** unutmamak önemlidir. Bu başlıklar olmadan tarayıcı, çapraz kökenli isteğin yanıtını işleme yeteneğinden yoksun kalır.
Aşağıdaki örneği göz önünde bulundurun, `PUT` yöntemini kullanmayı amaçlayan ve `Special-Request-Header` adında özel bir başlık içeren bir ön uçu isteği:
Yanıt olarak, sunucu kabul edilen yöntemleri, izin verilen kaynağı ve diğer CORS politikası ayrıntılarını gösteren başlıklar döndürebilir, aşağıda gösterildiği gibi:
* **`Access-Control-Allow-Headers`**: Bu başlık, gerçek istek sırasında hangi başlıkların kullanılabileceğini belirtir. Sunucu tarafından, istemciden gelen isteklerde izin verilen başlıkları göstermek için ayarlanır.
* **`Access-Control-Expose-Headers`**: Bu başlık aracılığıyla sunucu, basit yanıt başlıklarının yanı sıra yanıtın bir parçası olarak hangi başlıkların açıklanabileceği konusunda istemciyi bilgilendirir.
* **`Access-Control-Max-Age`**: Bu başlık, bir ön uçuş isteğinin sonuçlarının ne kadar süreyle önbelleğe alınabileceğini belirtir. Sunucu, ön uçuş isteği tarafından döndürülen bilgilerin ne kadar süreyle yeniden kullanılabileceğini belirler.
* **`Access-Control-Request-Headers`**: Ön uçuş isteklerinde kullanılan bu başlık, istemcinin gerçek istekte hangi HTTP başlıklarını kullanmak istediğini sunucuya bildirmek için ayarlanır.
* **`Access-Control-Request-Method`**: Bu başlık da ön uçuş isteklerinde kullanılır ve 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 kökenli isteğin kökenini belirtir. Sunucu, gelen isteğin CORS politikasına dayanarak izin verilip verilmeyeceğini değerlendirmek için bunu kullanır.
Genellikle (içerik türüne ve ayarlanan başlıklara bağlı olarak) **GET/POST isteğinde ön uçuş isteği gönderilmez** (isteğin **doğrudan** gönderilir), ancak yanıtın **başlıklarını/gövdesine erişmek istiyorsanız**, buna izin veren bir _Access-Control-Allow-Origin_ başlığı içermelidir.\
1.**`Access-Control-Request-Local-Network`**: Bu başlık, istemcinin isteğine dahil edilir ve sorgunun yerel ağ kaynağına yönelik olduğunu belirtir. Sunucuya isteğin yerel ağdan geldiğini bildirmek için bir işaret olarak hizmet eder.
2.**`Access-Control-Allow-Local-Network`**: Yanıt olarak, sunucular istenen kaynağın yerel ağ dışındaki varlıklarla paylaşılmasına izin verildiğini iletmek için bu başlığı kullanır. Farklı ağ sınırları arasında kaynakların paylaşılmasına yeşil ışık yakarak, kontrollü erişimi sağlarken güvenlik protokollerini korur.
Linux'un **0.0.0.0** IP'sinin bu gereksinimleri atlamak için localhost'a erişmek için çalıştığına dikkat edin çünkü bu IP adresi "yerel" olarak kabul edilmez.
Ayrıca, **Yerel Ağ gereksinimlerini atlamak** mümkündür eğer **yerel bir uç noktanın genel IP adresini** kullanıyorsanız (örneğin yönlendiricinin genel IP'si). Çünkü birkaç durumda, hatta **genel IP'ye** erişiliyorsa, eğer **yerel ağdan** erişiliyorsa erişim sağlanacaktır.
`Access-Control-Allow-Credentials`'ın **`true`** olarak ayarlanmasının ç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 verir, saldırının etkinliğini artırır. Bu olmadan, tarayıcıya istek göndermek yerine kendiniz yapmanın avantajı azalır, çünkü bir kullanıcının çerezlerini kullanmak olanaksız hale gelir.
Kurbanın ağ konumunun kimlik doğrulaması olarak kullanıldığı bir istisna bulunmaktadır. Bu, kurbanın tarayıcısının bir proxy olarak kullanılmasına izin verir, IP tabanlı kimlik doğrulamayı atlayarak iç ağ uygulamalarına erişimi sağlar. Bu yöntem, DNS yeniden bağlama ile benzer etkilere sahip olmasına rağmen daha basit bir şekilde istismar edilebilir.
`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 yönelik kısıtlamalar nedeniyle teorik olarak olası değildir. Bununla birlikte, CORS'u birden fazla URL için etkinleştirmek isteyen geliştiriciler, `Access-Control-Allow-Origin` başlığını dinamik olarak oluşturabilir ve bunu `Origin` başlığının değerini kopyalayarak yapabilir. Bu yaklaşım, özellikle bir saldırganın geçerlilik mantığını aldatarak meşru görünmesi için tasarlanmış bir alan adı kullandığında, zafiyetlere neden olabilir.
Yönlendirmeler veya yerel HTML dosyaları gibi durumlar için belirtilen `null` kökeni, benzersiz bir konuma sahiptir. Bazı uygulamalar, yerel geliştirmeyi kolaylaştırmak için bu kökeni beyaz listeye alır ve yanlışlıkla herhangi bir web sitesinin, bir kum havuzlu iframe aracılığıyla `null` kökenini taklit etmesine izin vererek CORS kısıtlamalarını atlar.
Bir alan adı beyaz listesiyle karşılaşıldığında, saldırganın alan adını beyaz listelenmiş bir alan adına eklemesi veya alt alan devralma güvenlik açıklarını sömürmesi gibi atlatma fırsatlarını test etmek hayati önem taşır. Ayrıca, alan doğrulaması için kullanılan düzenli ifadeler, alan adı adlandırma kurallarındaki ince detayları göz ardı edebilir ve daha fazla atlatma fırsatı sunabilir.
Regex desenleri genellikle alfasayısal, nokta (.), ve kısa çizgi (-) karakterlerine odaklanırken, diğer olasılıkları ihmal eder. Örneğin, tarayıcılar ve regex desenleri tarafından farklı yorumlanan karakterleri içeren bir alan adı, güvenlik kontrollerini atlatmak için kullanılabilir. Safari, Chrome ve Firefox'un alt alanlardaki alt çizgi karakterlerini ele alış şekli, bu tür farklılıkların alan doğrulama mantığını atlatmak için nasıl sömürülebileceğini gösterir.
**Bu atlatma kontrolünün daha fazla bilgi ve ayarları için:** [**https://www.corben.io/advanced-cors-techniques/**](https://www.corben.io/advanced-cors-techniques/) **ve** [**https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397**](https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397)
Geliştiriciler genellikle, bilgi istemek için izin verilen alan adlarını beyaz listeye alarak CORS sömürüsüne karşı koruyucu mekanizmalar uygularlar. Bu önlemlere rağmen, sistemin güvenliği kusursuz değildir. Beyaz listelenen alan adları içinde bile tek bir savunmasız alt alanın bulunması, XSS (Cross-Site Scripting) gibi diğer güvenlik açıklarından dolayı CORS sömürüsüne kapı açabilir.
Örneğin, `requester.com` adlı bir alanın, başka bir alan olan `provider.com`'dan kaynaklara erişimine izin verildiğini düşünelim. Sunucu tarafı yapılandırması şöyle görünebilir:
Bu kurulumda, `requester.com` alt alan adlarının hepsine erişim izni verilmiştir. Ancak, bir alt alan adı, örneğin `sub.requester.com`, bir XSS zafiyeti ile tehlikeye düşerse, bir saldırgan bu zayıflığı kullanabilir. Örneğin, `sub.requester.com`'a erişimi olan bir saldırgan, XSS zafiyetini kullanarak CORS politikalarını atlayabilir ve `provider.com` üzerindeki kaynaklara kötü niyetli bir şekilde erişebilir.
HTTP başlığı enjeksiyonu aracılığıyla sunucu tarafı önbellek zehirlenmesini sömürerek, depolanan Cross-Site Scripting (XSS) zafiyetinin tetiklenebileceği mümkündür. Bu senaryo, bir uygulamanın `Origin` başlığını yasaklı karakterler için temizlemediğinde ortaya çıkar ve özellikle Internet Explorer ve Edge kullanıcıları için bir zafiyet oluşturur. Bu tarayıcılar, (0x0d) karakterini yasal bir HTTP başlık terminatorü olarak işler ve HTTP başlığı enjeksiyonu zafiyetlerine yol açar.
Bu zafiyeti doğrudan sömürmek için bir web tarayıcısının hatalı bir başlık göndermesi mümkün olmasa da, Burp Suite gibi araçlar kullanılarak elle oluşturulmuş bir istek ile zafiyet sömürülebilir. Bu yöntem, sunucu tarafında bir önbelleğin yanıtı kaydetmesine ve yanlışlıkla başkalarına sunmasına neden olabilir. Oluşturulan yük, sayfanın karakter setini UTF-7'ye değiştirmeyi amaçlar. UTF-7, belirli bağlamlarda betik olarak yürütülebilecek şekilde karakterleri kodlayabilme yeteneği nedeniyle XSS zafiyetleri ile sıkça ilişkilendirilen bir karakter kodlamasıdır.
**Not**: Özellikle sunucu tarafı önbellek zehirlenmesi yoluyla HTTP başlık enjeksiyonu zafiyetlerinin sömürülmesi, HTTP başlıkları da dahil olmak üzere tüm kullanıcı tarafından sağlanan girdilerin doğrulanması ve temizlenmesinin kritik önemini vurgular. Bu tür zafiyetleri önlemek için girdi doğrulamasını içeren sağlam bir güvenlik modeli kullanın.
Bu senaryoda, uygun kodlama olmadan özel bir HTTP başlığının içeriğini yansıtan bir web sayfası örneği gözlemlenir. Özellikle, web sayfası, `X-User-id` başlığında bulunan içeriği geri yansıtır; bu içerik kötü amaçlı JavaScript içerebilir. Başlık, yüklenirken JavaScript kodunu yürütmeyi amaçlayan bir SVG resim etiketi içerdiğinde gösterildiği gibi.
Çapraz Kaynak Paylaşımı (CORS) politikaları özel başlıkların gönderilmesine izin verir. Ancak, CORS kısıtlamaları nedeniyle yanıtın tarayıcı tarafından doğrudan işlenmemesi durumunda, böyle bir enjeksiyonun faydası sınırlı gibi görünebilir. Kritik nokta, tarayıcının önbellek davranışını düşünürken ortaya çıkar. `Vary: Origin` başlığı belirtilmediğinde, kötü amaçlı yanıtın tarayıcı tarafından önbelleğe alınması mümkün hale gelir. Sonuç olarak, bu önbelleğe alınmış yanıt, URL'ye doğrudan gezinildiğinde doğrudan render edilebilir, başlangıçtaki istekte doğrudan render yapma ihtiyacını atlayarak. Bu mekanizma, istemci tarafı önbelleğini kullanarak saldırının güvenilirliğini artırır.
Bu saldırıyı göstermek için, bir JavaScript örneği sağlanmıştır; bir JSFiddle gibi bir web sayfası ortamında yürütülmek üzere tasarlanmıştır. Bu betik basit bir eylem gerçekleştirir: belirtilen URL'ye kötü amaçlı JavaScript içeren özel bir başlık içeren bir istek gönderir. Başarılı istek tamamlandığında, hedef URL'ye gitmeye çalışır ve yanıtın `Vary: Origin` başlığının uygun şekilde ele alınmadan önbelleğe alındıysa, enjekte edilen betiğin yürütülmesini tetikleyebilir.
XSSI, aynı köken politikasının (SOP) script etiketi kullanılarak kaynaklar dahil edilirken geçerli olmadığından faydalanarak Cross-Site Script Inclusion olarak da bilinen bir zafiyet türüdür. Bu, betiklerin farklı alanlardan dahil edilebilmesi gerektiği gerçeğinden yararlanır. Bu zafiyet, saldırganın betik etiketi kullanılarak dahil edilen herhangi bir içeriğe erişmesine ve okumasına olanak tanır.
Bu zafiyet, özellikle dinamik JavaScript veya JSONP (JSON ile Dolgulama) söz konusu olduğunda önemli hale gelir, özellikle çerezler gibi ortam yetkilendirme bilgileri kimlik doğrulaması için kullanıldığında. Farklı bir ana bilgisayardan bir kaynak istendiğinde çerezler dahil edilir ve saldırganın erişimine açık hale gelir.
Bu zafiyeti daha iyi anlamak ve azaltmak için web uygulamalarınızda potansiyel XSSI zafiyetlerini belirlemeye ve ele almaya yardımcı olabilecek BurpSuite eklentisini kullanabilirsiniz. [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp) adresinde bulunan bu eklenti, web uygulamalarınızdaki XSSI zafiyetlerini belirlemeye ve ele almaya yardımcı olabilir.
İsteğe bir **`geriçağrı`** **parametresi** eklemeyi deneyin. Belki sayfa verileri JSONP olarak göndermek üzere hazırlandı. Bu durumda sayfa, CORS politikasını atlayacak olan `Content-Type: application/javascript` ile verileri geri gönderecektir.
`Access-Control-Allow-Origin` kısıtlamasını atlatmanın bir yolu, bir web uygulamasından sizin adınıza bir istekte bulunmasını ve yanıtı geri göndermesini istemektir. Ancak, bu senaryoda, son kurbanın kimlik bilgileri farklı bir alan adına yapılan istek nedeniyle gönderilmez.
1. [**CORS-escape**](https://github.com/shalvah/cors-escape): Bu araç, isteğinizi başlıklarıyla birlikte ileten ve aynı zamanda istenen alan adıyla eşleşecek şekilde Origin başlığını sahteleştiren bir proxy sağlar. Bu, CORS politikasını etkili bir şekilde atlar. İşte XMLHttpRequest ile örnek bir kullanım:
2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): Bu araç, istekinizi olduğu gibi iletmek yerine sunucunun belirtilen parametrelerle kendi isteğini yapmasını sağlar.
`e.origin === window.origin` gibi CORS denetimlerini atlatmak için bir iframe oluşturarak ve ondan yeni bir pencere açarak atlatma yapabilirsiniz. Daha fazla bilgi için aşağıdaki sayfaya bakın:
TTL aracılığıyla DNS rebinding, DNS kayıtlarını manipüle ederek belirli güvenlik önlemlerini atlatmak için kullanılan bir tekniktir. Nasıl çalıştığını aşağıda bulabilirsiniz:
4. TTL süresi dolduğunda, kurbanın tarayıcısı yeni bir DNS isteği yapar, bu da saldırganın kurbanın sayfasında JavaScript kodunu yürütmesine olanak tanır.
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 aynı sayfada kalmasına izin veren senaryolarda kullanışlı olabilir.
DNS rebinding'i kötüye kullanmanın hızlı bir yoluna ihtiyacınız varsa, [https://lock.cmpxchg8b.com/rebinder.html](https://lock.cmpxchg8b.com/rebinder.html) gibi hizmetleri kullanabilirsiniz.
Kendi DNS rebinding sunucunuzu çalıştırmak için **DNSrebinder** ([https://github.com/mogwailabs/DNSrebinder](https://github.com/mogwailabs/DNSrebinder)) gibi araçları kullanabilirsiniz. Bu, yerel port 53/udp'nizi açığa çıkararak, buna işaret eden bir A kaydı oluşturarak (örneğin, ns.example.com), ve önceden oluşturulan A alt alan adına işaret eden bir NS kaydı oluşturarak yapılır (örneğin, ns.example.com). ns.example.com alt alan adının herhangi bir alt alanı daha sonra ana bilgisayarınız tarafından çözümlenir.
Daha fazla anlayış ve deneyim için [http://rebind.it/singularity.html](http://rebind.it/singularity.html) adresinde halka açık çalışan bir sunucuyu keşfedebilirsiniz.
DNS rebinding aracılığıyla DNS önbelleği saldırısı, tarayıcıların önbellekleme mekanizmasını atlatmak ve ikinci bir DNS isteği yapmaya zorlamak için kullanılan başka bir tekniktir. Nasıl çalıştığını aşağıda bulabilirsiniz:
2. Önbellekleme savunmasını atlatmak için saldırgan bir hizmet işçisi kullanır. Hizmet işçisi, DNS önbelleğini doldurur ve bu şekilde önbelleğe alınan saldırgan sunucu adını siler.
Hizmet işçisiyle DNS önbelleğini doldurarak, saldırgan DNS çözümleme sürecini manipüle edebilir ve kurbanın tarayıcısını ikinci bir istek yapmaya zorlayabilir, bu sefer istenen saldırganın IP adresine çözülür.
Önbellekleme savunmasını atlatmanın başka bir yolu, DNS sağlayıcısında aynı alt alan adı için birden fazla IP adresini kullanmaktır. Nasıl çalıştığını aşağıda bulabilirsiniz:
3. Tarayıcı saldırganın IP adresini ilk olarak kullanmaya karar verirse, saldırgan, aynı alan adına HTTP istekleri gerçekleştiren bir yük yükleyebilir.
4. Ancak saldırgan, kurbanın IP adresini elde ettikten sonra, kurbanın tarayıcısına yanıt vermeyi durdurur.
6. İkinci IP adresine erişerek, tarayıcı Aynı Köken Politikasını (SOP) atlatır ve saldırgan bu durumu kötüye kullanarak kurbandan bilgi toplayabilir ve dışarı aktarabilir.
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 kötüye kullanabilir ve kurbandan bilgiye erişebilir.
Godaddy veya cloudflare gibi sağlayıcılar, 0.0.0.0 IP'sini kullanmama izin vermedi, ancak AWS route53, biri "0.0.0.0" olan 2 IP'li bir A kaydı oluşturmama izin verdi.
Daha fazla bilgi için [https://unit42.paloaltonetworks.com/dns-rebinding/](https://unit42.paloaltonetworks.com/dns-rebinding/) adresine göz atabilirsiniz.
Önceki atlatma teknikleri hakkında daha fazla bilgiyi ve aşağıdaki aracı nasıl kullanacağınızı [Gerald Doussot - DNS Rebinding Saldırılarının Durumu ve Kökenin Tekliği - DEF CON 27 Konferansı](https://www.youtube.com/watch?v=y9-0lICNjOQ) konuşmasında bulabilirsiniz.
[**`Singularity of Origin`**](https://github.com/nccgroup/singularity), [DNS rebinding](https://en.wikipedia.org/wiki/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 hedeflemek ve hedef makinedeki zayıf yazılımları sömürmek için saldırı yüklerini sunmak için gerekli bileşenleri içerir.
* [https://wicg.github.io/private-network-access/](https://wicg.github.io/private-network-access/): Genel sunucuların dahili sunuculara erişmek istediğinde her zaman bir önceden uçuş isteği gönderilmesini öneren bir teklif
<summary><strong>Sıfırdan kahraman olmak için AWS hackleme öğrenin</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* **Şirketinizi HackTricks'te reklamınızı görmek veya HackTricks'i PDF olarak indirmek istiyorsanız** [**ABONELİK PLANLARI**](https://github.com/sponsors/carlospolop)'na göz atın!
* Özel [**NFT'lerimiz olan**](https://opensea.io/collection/the-peass-family) [**The PEASS Family**](https://opensea.io/collection/the-peass-family) koleksiyonumuzu keşfedin
* **💬 [Discord grubuna](https://discord.gg/hRep4RUj7f) veya [telegram grubuna](https://t.me/peass) katılın veya** bizi **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**'da takip edin.**