# Çerez Hacking

{{#include ../../banners/hacktricks-training.md}}

## Çerez Özellikleri

Çerezler, kullanıcının tarayıcısındaki davranışlarını kontrol eden birkaç özellik ile gelir. İşte bu özelliklerin daha pasif bir sesle bir özeti:

### Süre Dolma ve Max-Age

Bir çerezin son kullanma tarihi `Expires` özelliği ile belirlenir. Tersine, `Max-age` özelliği, bir çerezin silinmesine kadar geçen süreyi saniye cinsinden tanımlar. **Daha modern uygulamaları yansıttığı için `Max-age` seçin.**

### Alan

Bir çerezi alacak olan ana bilgisayarlar `Domain` özelliği ile belirtilir. Varsayılan olarak, bu çerezi veren ana bilgisayara ayarlanır, alt alan adlarını içermez. Ancak, `Domain` özelliği açıkça ayarlandığında, alt alan adlarını da kapsar. Bu, `Domain` özelliğinin belirlenmesini daha az kısıtlayıcı bir seçenek haline getirir ve alt alan adları arasında çerez paylaşımının gerekli olduğu senaryolar için faydalıdır. Örneğin, `Domain=mozilla.org` ayarlandığında, `developer.mozilla.org` gibi alt alan adlarında çerezlere erişim sağlanır.

### Yol

`Cookie` başlığının gönderilmesi için istenen URL'de bulunması gereken belirli bir URL yolu `Path` özelliği ile belirtilir. Bu özellik, `/` karakterini bir dizin ayırıcı olarak kabul eder ve alt dizinlerde eşleşmelere de izin verir.

### Sıralama Kuralları

İki çerez aynı isme sahip olduğunda, gönderilmek üzere seçilen çerez:

- İstenen URL'deki en uzun yolu eşleşen çerez.
- Eğer yollar aynıysa, en son ayarlanan çerez.

### SameSite

- `SameSite` özelliği, çerezlerin üçüncü taraf alanlardan gelen isteklerde gönderilip gönderilmeyeceğini belirler. Üç ayar sunar:
- **Strict**: Çerezin üçüncü taraf isteklerinde gönderilmesini kısıtlar.
- **Lax**: Çerezin üçüncü taraf web siteleri tarafından başlatılan GET istekleri ile gönderilmesine izin verir.
- **None**: Çerezin herhangi bir üçüncü taraf alanından gönderilmesine izin verir.

Çerezleri yapılandırırken, bu özellikleri anlamak, farklı senaryolar arasında beklenildiği gibi davranmalarını sağlamaya yardımcı olabilir.

| **İstek Türü** | **Örnek Kod**                   | **Çerezler Ne Zaman Gönderilir** |
| ---------------- | ---------------------------------- | --------------------- |
| Bağlantı         | \<a href="...">\</a>               | NotSet\*, Lax, None   |
| Önceden Yükleme  | \<link rel="prerender" href=".."/> | NotSet\*, Lax, None   |
| Form GET         | \<form method="GET" action="...">  | NotSet\*, Lax, None   |
| Form POST        | \<form method="POST" action="..."> | NotSet\*, None        |
| iframe           | \<iframe src="...">\</iframe>      | NotSet\*, None        |
| AJAX             | $.get("...")                       | NotSet\*, None        |
| Resim            | \<img src="...">                   | NetSet\*, None        |

Tablo [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) kaynağından alınmış ve hafifçe değiştirilmiştir.\
_**SameSite**_ özelliğine sahip bir çerez, **CSRF saldırılarını azaltacaktır**.

**\*Chrome80 (şub/2019) itibarıyla, bir çerez için varsayılan davranış, çerez samesite** **özelliği yoksa lax olacaktır** ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)).\
Bu değişiklik uygulandıktan sonra, **SameSite** **politikası olmayan çerezler Chrome'da** **ilk 2 dakika boyunca None olarak, ardından üst düzey çapraz site POST isteği için Lax olarak** **işlenecektir.**

## Çerez Bayrakları

### HttpOnly

Bu, **istemcinin** çereze erişimini engeller (Örneğin **Javascript** ile: `document.cookie`)

#### **Aşmalar**

- Eğer sayfa, bir isteğin yanıtı olarak çerezleri **gönderiyorsa** (örneğin bir **PHPinfo** sayfasında), XSS'i kötüye kullanarak bu sayfaya bir istek göndermek ve yanıtından **çerezleri çalmak** mümkündür (örneği kontrol edin [https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/](https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/)).
- Bu, **TRACE** **HTTP** istekleri ile aşılabilir çünkü sunucudan gelen yanıt, gönderilen çerezleri yansıtır (bu HTTP yöntemi mevcutsa). Bu teknik **Cross-Site Tracking** olarak adlandırılır.
- Modern tarayıcılar, JS'den TRACE isteği göndermeye izin vermeyerek bu tekniği engeller. Ancak, IE6.0 SP2'ye `TRACE` yerine `\r\nTRACE` göndererek bazı aşmalar bulunmuştur.
- Diğer bir yol, tarayıcıların sıfır/günlük açıklarını istismar etmektir.
- Bir Çerez Jar taşma saldırısı gerçekleştirerek **HttpOnly çerezleri** **üst üste yazmak** mümkündür:

{{#ref}}
cookie-jar-overflow.md
{{#endref}}

- Bu çerezleri dışarı aktarmak için [**Cookie Smuggling**](#cookie-smuggling) saldırısı kullanılabilir.

### Güvenli

İstek, yalnızca güvenli bir kanal üzerinden (genellikle **HTTPS**) iletilirse çerezi **sadece** HTTP isteğinde gönderir.

## Çerez Ön Ekleri

`__Secure-` ile başlayan çerezlerin, HTTPS ile güvence altına alınmış sayfalardan `secure` bayrağı ile birlikte ayarlanması gerekmektedir.

`__Host-` ile başlayan çerezler için birkaç koşulun karşılanması gerekir:

- `secure` bayrağı ile ayarlanmalıdır.
- HTTPS ile güvence altına alınmış bir sayfadan gelmelidir.
- Alt alan adlarına iletilmelerini engellemek için bir alan belirtmeleri yasaktır.
- Bu çerezlerin yolu `/` olarak ayarlanmalıdır.

`__Host-` ile başlayan çerezlerin süper alan adlarına veya alt alan adlarına gönderilmesine izin verilmediğini belirtmek önemlidir. Bu kısıtlama, uygulama çerezlerini izole etmeye yardımcı olur. Bu nedenle, tüm uygulama çerezleri için `__Host-` ön ekinin kullanılması, güvenliği ve izolasyonu artırmak için iyi bir uygulama olarak kabul edilebilir.

### Çerezleri Üst Üste Yazma

Dolayısıyla, `__Host-` ile başlayan çerezlerin korunmasından biri, alt alan adlarından üst üste yazılmalarını engellemektir. Örneğin [**Cookie Tossing saldırılarını**](cookie-tossing.md) önlemek. [**Cookie Crumbles: Web Oturum Bütünlüğü Açıklarını Ortaya Çıkarma**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**makale**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)) konuşmasında, çerezleri ayarlamanın mümkün olduğu gösterilmiştir. \_\_HOST- ile başlayan çerezler, ayrıştırıcıyı kandırarak, örneğin, başına veya başına ve sonuna "=" ekleyerek ayarlanmıştır:

<figure><img src="../../images/image (6) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

Ya da PHP'de çerez adının başına **diğer karakterler ekleyerek**, bu karakterlerin **alt çizgi** karakterleri ile değiştirilmesi sağlanarak `__HOST-` çerezlerini üst üste yazmak mümkündür:

<figure><img src="../../images/image (7) (1) (1) (1) (1).png" alt="" width="373"><figcaption></figcaption></figure>

## Çerez Saldırıları

Özel bir çerez hassas veriler içeriyorsa, bunu kontrol edin (özellikle bir CTF oynuyorsanız), çünkü bu savunmasız olabilir.

### Çerezleri Çözme ve Manipüle Etme

Çerezlerde gömülü hassas veriler her zaman incelenmelidir. Base64 veya benzeri formatlarda kodlanmış çerezler genellikle çözülebilir. Bu zafiyet, saldırganların çerezin içeriğini değiştirmesine ve değiştirilmiş verilerini çereze geri kodlayarak diğer kullanıcıları taklit etmesine olanak tanır.

### Oturum Ele Geçirme

Bu saldırı, bir kullanıcının çerezini çalarak uygulama içindeki hesabına yetkisiz erişim sağlamayı içerir. Çalınan çerez kullanılarak, bir saldırgan meşru kullanıcıyı taklit edebilir.

### Oturum Sabitleme

Bu senaryoda, bir saldırgan bir kurbanı belirli bir çerezi kullanarak giriş yapmaya kandırır. Uygulama giriş yapıldığında yeni bir çerez atamazsa, saldırgan, orijinal çerezi elinde bulundurarak kurbanı taklit edebilir. Bu teknik, kurbanın saldırgan tarafından sağlanan bir çerezle giriş yapmasına dayanır.

Eğer bir **alt alan adında XSS bulduysanız** veya **bir alt alan adını kontrol ediyorsanız**, okuyun:

{{#ref}}
cookie-tossing.md
{{#endref}}

### Oturum Bağışı

Burada, saldırgan kurbanı saldırganın oturum çerezini kullanmaya ikna eder. Kurban, kendi hesabında oturum açtığını düşünerek, saldırganın hesabı bağlamında istemeden eylemler gerçekleştirir.

Eğer bir **alt alan adında XSS bulduysanız** veya **bir alt alan adını kontrol ediyorsanız**, okuyun:

{{#ref}}
cookie-tossing.md
{{#endref}}

### [JWT Çerezleri](../hacking-jwt-json-web-tokens.md)

JWT'deki olası hataları açıklayan bir sayfaya erişmek için önceki bağlantıya tıklayın.

Çerezlerde kullanılan JSON Web Token'lar (JWT) da zafiyetler içerebilir. Potansiyel hatalar ve bunları nasıl istismar edeceğiniz hakkında derinlemesine bilgi için, JWT hacking ile ilgili bağlantılı belgeye erişmeniz önerilir.

### Cross-Site Request Forgery (CSRF)

Bu saldırı, oturum açmış bir kullanıcının, şu anda kimlik doğrulaması yapılmış olduğu bir web uygulamasında istenmeyen eylemleri gerçekleştirmesini zorlar. Saldırganlar, savunmasız siteye her istekte otomatik olarak gönderilen çerezleri istismar edebilir.

### Boş Çerezler

(Başka ayrıntılar için [orijinal araştırmaya](https://blog.ankursundara.com/cookie-bugs/) bakın) Tarayıcılar, isim olmadan çerez oluşturulmasına izin verir, bu da JavaScript ile şu şekilde gösterilebilir:
```js
document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
document.cookie = "b=v2"
```
Gönderilen çerez başlığındaki sonuç `a=v1; test value; b=v2;`. İlginç bir şekilde, bu, boş bir isim çerezi ayarlandığında çerezlerin manipüle edilmesine olanak tanır ve boş çerezi belirli bir değere ayarlayarak diğer çerezleri kontrol etme potansiyeli taşır:
```js
function setCookie(name, value) {
document.cookie = `${name}=${value}`
}

setCookie("", "a=b") // Setting the empty cookie modifies another cookie's value
```
Bu, tarayıcının her web sunucusu tarafından `a` adında ve `b` değerine sahip bir çerez olarak yorumlanan bir çerez başlığı göndermesine yol açar.

#### Chrome Hatası: Unicode Yedek Kod Noktası Sorunu

Chrome'da, eğer bir Unicode yedek kod noktası ayarlanmış bir çerezin parçasıysa, `document.cookie` bozulur ve sonrasında boş bir dize döner:
```js
document.cookie = "\ud800=meep"
```
Bu, `document.cookie`'nin boş bir dize döndürmesine neden olur ve kalıcı bir bozulmayı gösterir.

#### Ayrıştırma Sorunlarından Kaynaklanan Cookie Smuggling

(Daha fazla detay için [orijinal araştırmaya](https://blog.ankursundara.com/cookie-bugs/) bakın) Java (Jetty, TomCat, Undertow) ve Python (Zope, cherrypy, web.py, aiohttp, bottle, webob) gibi birkaç web sunucusu, eski RFC2965 desteği nedeniyle çerez dizelerini yanlış işler. Bir çerez değeri çift tırnak içinde olsa bile, genellikle anahtar-değer çiftlerini ayıran noktalı virgüller içerse bile, bunu tek bir değer olarak okurlar:
```
RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
```
#### Cookie Injection Vulnerabilities

(Check further details in the[original research](https://blog.ankursundara.com/cookie-bugs/)) Sunucuların çerezleri yanlış analiz etmesi, özellikle Undertow, Zope ve Python'un `http.cookie.SimpleCookie` ve `http.cookie.BaseCookie` kullananlar, çerez enjeksiyonu saldırıları için fırsatlar yaratır. Bu sunucular, yeni çerezlerin başlangıcını düzgün bir şekilde ayırt edemez, bu da saldırganların çerezleri taklit etmesine olanak tanır:

- Undertow, alıntılanmış bir değerden hemen sonra bir yeni çerez bekler, noktalı virgül olmadan.
- Zope, bir sonraki çerezi analiz etmeye başlamak için bir virgül arar.
- Python'un çerez sınıfları, bir boşluk karakterinde analiz yapmaya başlar.

Bu zafiyet, çerez tabanlı CSRF korumasına dayanan web uygulamalarında özellikle tehlikelidir, çünkü saldırganların taklit CSRF-token çerezleri enjekte etmesine olanak tanır ve bu da güvenlik önlemlerinin aşılmasına yol açabilir. Sorun, Python'un tekrar eden çerez adlarını ele almasıyla daha da kötüleşir; burada son gerçekleşme, önceki olanları geçersiz kılar. Ayrıca, güvensiz bağlamlarda `__Secure-` ve `__Host-` çerezleri için endişeleri artırır ve çerezlerin taklit edilme eğiliminde olan arka uç sunuculara iletilmesi durumunda yetkilendirme aşımına yol açabilir.

### Cookies $version

#### WAF Bypass

According to [**this blogpost**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), arka ucu çerezi analiz etmek için eski bir mantık kullanmaya zorlamak amacıyla çerez niteliği **`$Version=1`** kullanmak mümkün olabilir, bu da **RFC2109**'dan kaynaklanmaktadır. Ayrıca, **`$Domain`** ve **`$Path`** gibi diğer değerler, çerezin arka uç üzerindeki davranışını değiştirmek için kullanılabilir.

#### Cookie Sandwich Attack

According to [**this blogpost**](https://portswigger.net/research/stealing-httponly-cookies-with-the-cookie-sandwich-technique) çerez sandviçi tekniğini kullanarak HttpOnly çerezleri çalmak mümkündür. İşte gereksinimler ve adımlar:

- Görünüşte işe yaramaz bir **çerezin yanıtta yansıtıldığı** bir yer bulun
- **Değeri `1` olan `$Version`** adında bir çerez oluşturun (bunu JS'den bir XSS saldırısı ile yapabilirsiniz) daha spesifik bir yol ile böylece başlangıç konumunu alır (bazı çerçeve dilleri bu adımı gerektirmez)
- **Yansıtılan çerezi oluşturun** ve değeri **açık çift tırnak** bırakan ve belirli bir yol ile böylece önceki çerezin (`$Version`) ardından çerez veritabanında konumlanacak şekilde
- Sonra, meşru çerez sırada bir sonraki olacaktır
- **Değeri içinde çift tırnağı kapatan bir sahte çerez oluşturun**

Bu şekilde, kurban çerezi yeni çerez versiyon 1 içinde sıkışacak ve her yansıtıldığında yansıtılacaktır.
```javascript
document.cookie = `$Version=1;`;
document.cookie = `param1="start`;
// any cookies inside the sandwich will be placed into param1 value server-side
document.cookie = `param2=end";`;
```
### WAF bypasses

#### Cookies $version

Önceki bölüme bakın.

#### Alıntı dizgesi kodlaması ile değer analizini atlama

Bu ayrıştırma, çerezler içindeki kaçış karakterlerini çözmek için kaçış değerlerini geri almayı gösterir, böylece "\a" "a" olur. Bu, WAF'ları atlamak için yararlı olabilir:

- `eval('test') => forbidden`
- `"\e\v\a\l\(\'\t\e\s\t\'\)" => allowed`

#### Çerez adı kara liste atlaması

RFC2109'da **virgülün çerez değerleri arasında ayırıcı olarak kullanılabileceği** belirtilmiştir. Ayrıca **eşittir işaretinden önce ve sonra boşluklar ve sekmeler eklemek mümkündür**. Bu nedenle, `$Version=1; foo=bar, abc = qux` gibi bir çerez, `"foo":"bar, admin = qux"` çerezini oluşturmaz, bunun yerine `foo":"bar"` ve `"admin":"qux"` çerezlerini oluşturur. İki çerez nasıl oluşturulduğuna ve admin'in eşittir işaretinden önce ve sonra boşluğun nasıl kaldırıldığına dikkat edin.

#### Çerez bölme ile değer analizini atlama

Son olarak, farklı arka kapılar, farklı çerez başlıklarında geçen farklı çerezleri bir dize içinde birleştirebilir:
```
GET / HTTP/1.1
Host: example.com
Cookie: param1=value1;
Cookie: param2=value2;
```
Bu, bu örnekte olduğu gibi bir WAF'ı atlamayı mümkün kılabilir:
```
Cookie: name=eval('test//
Cookie: comment')

Resulting cookie: name=eval('test//, comment') => allowed
```
### Ekstra Hassas Çerez Kontrolleri

#### **Temel kontroller**

- **Çerez** her seferinde **giriş yaptığınızda** **aynıdır**.
- Çıkış yapın ve aynı çerezi kullanmayı deneyin.
- Aynı çerezi kullanarak 2 cihazda (veya tarayıcıda) aynı hesaba giriş yapmayı deneyin.
- Çerezin içinde herhangi bir bilgi olup olmadığını kontrol edin ve değiştirmeyi deneyin.
- Neredeyse aynı kullanıcı adıyla birkaç hesap oluşturmaya çalışın ve benzerlikleri görebiliyor musunuz kontrol edin.
- Varsa "**beni hatırla**" seçeneğini kontrol edin ve nasıl çalıştığını görün. Varsa ve hassas olabileceğini düşünüyorsanız, her zaman başka bir çerez olmadan **beni hatırla** çerezini kullanın.
- Önceki çerezin şifreyi değiştirdikten sonra bile çalışıp çalışmadığını kontrol edin.

#### **Gelişmiş çerez saldırıları**

Eğer çerez giriş yaptığınızda aynı (veya neredeyse aynı) kalıyorsa, bu muhtemelen çerezin hesabınızdaki bir alanla (muhtemelen kullanıcı adıyla) ilişkili olduğu anlamına gelir. O zaman şunları yapabilirsiniz:

- Çok **benzer** kullanıcı adlarına sahip birçok **hesap** oluşturmaya çalışın ve algoritmanın nasıl çalıştığını **tahmin** etmeye çalışın.
- **Kullanıcı adını brute force** etmeyi deneyin. Eğer çerez yalnızca kullanıcı adınız için bir kimlik doğrulama yöntemi olarak kaydediliyorsa, o zaman "**Bmin**" kullanıcı adıyla bir hesap oluşturabilir ve çerezin her bir **bitini brute force** edebilirsiniz çünkü deneyeceğiniz çerezlerden biri "**admin**"e ait olan olacaktır.
- **Padding** **Oracle** denemesi yapın (çerezin içeriğini şifreleyebilirsiniz). **padbuster** kullanın.

**Padding Oracle - Padbuster örnekleri**
```bash
padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# When cookies and regular Base64
padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf

# If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example:
padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2
```
Padbuster birkaç deneme yapacak ve size hangi durumun hata durumu olduğunu soracaktır (geçerli olmayan).

Daha sonra çerezi şifrelemeye başlayacaktır (bu birkaç dakika sürebilir).

Eğer saldırı başarıyla gerçekleştirilmişse, o zaman seçtiğiniz bir dizeyi şifrelemeyi deneyebilirsiniz. Örneğin, **encrypt** **user=administrator** istiyorsanız.
```
padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator
```
Bu yürütme, içinde **user=administrator** dizesi bulunan çerezi doğru bir şekilde şifrelenmiş ve kodlanmış olarak verecektir.

**CBC-MAC**

Belki bir çerez bazı değerlere sahip olabilir ve CBC kullanılarak imzalanabilir. O zaman, değerin bütünlüğü, aynı değerle CBC kullanılarak oluşturulan imzadır. IV olarak null vektör kullanılması önerildiğinden, bu tür bir bütünlük kontrolü savunmasız olabilir.

**Saldırı**

1. Kullanıcı adı **administ** için imzayı al = **t**
2. Kullanıcı adı **rator\x00\x00\x00 XOR t** için imzayı al = **t'**
3. Çerezde değeri **administrator+t'** olarak ayarla (**t'** geçerli bir imza olacaktır **(rator\x00\x00\x00 XOR t) XOR t** = **rator\x00\x00\x00**

**ECB**

Eğer çerez ECB kullanılarak şifrelenmişse, savunmasız olabilir.\
Giriş yaptığınızda aldığınız çerez her zaman aynı olmalıdır.

**Nasıl tespit edilir ve saldırılır:**

Neredeyse aynı verilere (kullanıcı adı, şifre, e-posta vb.) sahip 2 kullanıcı oluşturun ve verilen çerez içinde bir desen keşfetmeye çalışın.

Örneğin "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" adında bir kullanıcı oluşturun ve çerezde herhangi bir desen olup olmadığını kontrol edin (çünkü ECB her bloğu aynı anahtarla şifrelediğinden, kullanıcı adı şifrelendiğinde aynı şifrelenmiş baytlar görünebilir).

Kullanılan bir bloğun boyutunda bir desen olmalıdır. Yani, bir grup "a" nın nasıl şifrelendiğini bilerek bir kullanıcı adı oluşturabilirsiniz: "a"\*(bloğun boyutu)+"admin". Ardından, çerezden bir "a" bloğunun şifrelenmiş desenini silebilirsiniz. Ve "admin" kullanıcı adının çerezine sahip olacaksınız.

## Referanslar

- [https://blog.ankursundara.com/cookie-bugs/](https://blog.ankursundara.com/cookie-bugs/)
- [https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd](https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd)
- [https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie)

{{#include ../../banners/hacktricks-training.md}}