* **Şirketinizi HackTricks'te reklamınızı görmek istiyorsanız** veya **HackTricks'i PDF olarak indirmek istiyorsanız** [**ABONELİK PLANLARI**](https://github.com/sponsors/carlospolop)'na göz atın!
* [**PEASS Ailesi'ni**](https://opensea.io/collection/the-peass-family) keşfedin, özel [**NFT'lerimiz**](https://opensea.io/collection/the-peass-family) koleksiyonumuz
* **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.**
Çerezler, kullanıcının tarayıcısındaki davranışlarını kontrol eden birkaç özellikle birlikte gelir. İşte bu özelliklerin bir özetini daha pasif bir sesle açıklayanlar:
Bir çerezin son kullanma tarihi, `Expires` özelliği tarafından belirlenir. Buna karşılık, `Max-age` özelliği bir çerezin silineceği süreyi saniye cinsinden tanımlar. **Daha modern uygulamaları yansıttığı için `Max-age`'i tercih edin.**
Bir çerezi alacak ana bilgisayarlar, `Domain` özelliği tarafından belirtilir. Varsayılan olarak, bu, çerezi veren ana bilgisayara ayarlanır, alt alanlarını içermez. Ancak, `Domain` özelliği açıkça belirlendiğinde, alt alanları da kapsar. Bu, `Domain` özelliğinin belirtilmesini, alt alanlar arasında çerez paylaşımının gerektiği senaryolar için daha az kısıtlayıcı bir seçenek haline getirir. Örneğin, `Domain=mozilla.org` ayarlanarak, çerezlerin `developer.mozilla.org` gibi alt alanlarda erişilebilir olmasını sağlar.
`Path` özelliği, gönderilen URL'de bulunması gereken belirli bir URL yolunu gösterir. Bu özellik, `/` karakterini bir dizin ayırıcı olarak kabul eder, alt dizinlerde eşleşmelere izin verir.
Tablo [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) tarafından ve hafifçe değiştirilmiştir.\
_Bir **SameSite** özelliğine sahip çerez, oturum gerektiren CSRF saldırılarını**önleyecektir**._
**\*Unutmayın ki Chrome80'den (şubat/2019) itibaren, bir çerezin samesite özelliği olmayan bir çerezin varsayılan davranışı 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, **Chrome'da SameSite politikası olmayan çerezlerin****ilk 2 dakika boyunca None** olarak **işlem göreceğini ve ardından üst düzey çapraz site POST isteği için Lax** olarak işlem göreceğini **unutmayın.**
* Eğer sayfa, isteklerin yanıtı olarak çerezleri gönderiyorsa (örneğin bir **PHPinfo** sayfasında), XSS'yi kötüye kullanarak bu sayfaya bir istek gönderip yanıttan çerezleri **çalmak mümkün olabilir** (örneği [https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/](https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/) adresinde bulabilirsiniz).
* Bu, sunucudan gelen yanıt olarak **TRACE****HTTP** istekleriyle atlatılabilir (bu HTTP yöntemi mevcutsa). Bu teknik **Cross-Site Tracking** olarak adlandırılır.
* Bu teknik, **modern tarayıcılar tarafından JS'den TRACE** isteği göndermeye izin verilmeyerek önlendi. Ancak, IE6.0 SP2 gibi belirli yazılımlarda `\r\nTRACE` yerine `TRACE` göndererek bu kısıtlamaları atlatan bazı yöntemler bulunmuştur.
* Başka bir yol, tarayıcıların sıfır/gün açıklarının sömürülmesidir.
* Bir Çerez Kavanozu taşması saldırısı gerçekleştirerek **HttpOnly çerezlerin üzerine yazılabilir**:
`__Host-` ile başlayan çerezlerin süper alanlara veya alt alanlara 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-` önekini kullanmak, güvenliği ve izolasyonu artırmak için iyi bir uygulama olarak düşünülebilir.
Çerezlere gömülmüş hassas veriler her zaman incelenmelidir. Base64 veya benzer formatlarda kodlanmış çerezler genellikle çözülebilir. Bu zayıflık, saldırganların çerez içeriğini değiştirip modifiye ettikleri verileri tekrar çereze kodlayarak diğer kullanıcıları taklit etmelerine olanak tanır.
Bu saldırı, bir kullanıcının çerezini çalarak bir uygulamadaki hesabına izinsiz erişim sağlamayı içerir. Çalınan çerez kullanılarak, bir saldırgan meşru kullanıcıyı taklit edebilir.
Bu senaryoda, bir saldırgan bir kurbanı belirli bir çerez kullanmaya ikna eder. Uygulama giriş yaptıktan sonra yeni bir çerez atamazsa, saldırgan, orijinal çereze sahip olarak kurbanı taklit edebilir. Bu teknik, kurbanın saldırgan tarafından sağlanan bir çerezle giriş yapmasına dayanır.
Burada, saldırgan kurbanı saldırganın oturum çerezini kullanmaya ikna eder. Kendi hesabına giriş yaptığına inanan kurban, aslında saldırganın hesabı bağlamında yanlışlıkla işlemler gerçekleştirir.
Potansiyel JWT hatalarını açıklayan bir sayfaya erişmek için önceki bağlantıya tıklayın.
Çerezlerde kullanılan JSON Web Token'lar (JWT) de zayıflıklar içerebilir. Potansiyel hatalar ve bunları nasıl sömürüleceği hakkında detaylı bilgi için, JWT'yi hacklemekle ilgili belgeye erişmek önerilir.
Bu saldırı, oturum açmış bir kullanıcıyı, mevcut kimlik doğrulama yapılmış bir web uygulamasında istenmeyen eylemleri gerçekleştirmeye zorlar. Saldırganlar, her istekle otomatik olarak gönderilen çerezleri sömürebilirler.
(Daha fazla detay için [orijinal araştırmaya](https://blog.ankursundara.com/cookie-bugs/) bakın) Tarayıcılar, ismi olmayan çerezlerin oluşturulmasına izin verir, bu JavaScript ile aşağıdaki gibi gösterilebilir:
The result in the sent cookie header is `a=v1; test value; b=v2;`. Intriguingly, this allows for the manipulation of cookies if an empty name cookie is set, potentially controlling other cookies by setting the empty cookie to a specific value:
(Daha fazla ayrıntı 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) dahil birçok web sunucusu, eski RFC2965 desteğinden kaynaklanan çerez dizelerini yanlış işler. Çift tırnakla çevrili bir çerez değeri, normalde anahtar-değer çiftlerini ayıran noktalı virgüller içerse bile tek bir değer olarak okunur:
(Sonuçları[orijinal araştırmada](https://blog.ankursundara.com/cookie-bugs/) kontrol edin) Sunucuların, özellikle Undertow, Zope ve Python'ın `http.cookie.SimpleCookie` ve `http.cookie.BaseCookie` kullanarak çerezleri yanlış ayrıştırması, çerez enjeksiyon saldırıları için fırsatlar yaratır. Bu sunucular yeni çerezlerin başlangıcını düzgün bir şekilde sınırlamazlar, saldırganlara çerezleri sahtelemelerine olanak tanır:
Bu zayıflık, çerez tabanlı CSRF korumasına güvenen web uygulamalarında özellikle tehlikelidir, çünkü saldırganlara sahte CSRF belirteci çerezleri enjekte etmelerine ve güvenlik önlemlerini atlamalarına olanak tanır. Sorun, Python'ın yinelenen çerez adlarını işleme şekli tarafından kötüleştirilir, burada son oluşum öncekileri geçersiz kılar. Ayrıca, güvensiz bağlamlarda `__Secure-` ve `__Host-` çerezleri için endişeleri artırır ve çerezlerin sahteciliğe duyarlı arka uç sunucularına iletilmesi durumunda yetkilendirme atlamalarına yol açabilir.
* **Çerez**, her **giriş** yaptığınızda **aynı** olmalıdır.
* Çıkış yapın ve aynı çerezi kullanmaya çalışın.
* Aynı çerezi kullanarak aynı hesaba 2 cihazda (veya tarayıcıda) giriş yapmaya çalışın.
* Çerezde herhangi bir bilgi olup olmadığını kontrol edin ve değiştirmeye çalışın.
* Neredeyse aynı kullanıcı adıyla birkaç hesap oluşturun ve benzerlikleri görebilir misiniz kontrol edin.
* Varsa "**beni hatırla**" seçeneğini kontrol edin ve nasıl çalıştığını görün. Varsa ve savunmasız olabilirse, her zaman sadece **beni hatırla** çerezini kullanın, başka bir çerez olmadan.
* Şifrenizi değiştirdikten sonra önceki çerezin hala çalışıp çalışmadığını kontrol edin.
Eğer giriş yaptığınızda çerez aynı kalıyorsa (veya neredeyse aynı), bu muhtemelen çerezin hesabınızın bir alanıyla ilişkili olduğu anlamına gelir (muhtemelen kullanıcı adı). O zaman şunları yapabilirsiniz:
* Çok sayıda **hesap** oluşturun ve kullanıcı adları çok **benzer** olsun ve algoritmanın nasıl çalıştığını**tahmin** etmeye çalışın.
* **Kullanıcı adını brute force** deneyin. Eğer çerez sadece kullanıcı adınız için bir kimlik doğrulama yöntemi olarak kaydediyorsa, o zaman "**Bmin**" kullanıcı adıyla bir hesap oluşturabilir ve çerezinizin her bir **bitini** brute force edebilirsiniz çünkü deneyeceğiniz çerezlerden biri "**admin**"e ait olacaktır.
Belki bir çerez bir değere sahip olabilir ve CBC kullanılarak imzalanabilir. Sonra, değerin bütünlüğü, aynı değeri kullanarak CBC kullanarak oluşturulan imza olacaktır. IV olarak bir nul vektörü kullanılması önerildiği için, bu tür bütünlük kontrolü savunmasız olabilir.
1. Kullanıcı adı**administ**'in imzasını al = **t**
2. Kullanıcı adı**rator\x00\x00\x00 XOR t**'nin imzasını al = **t'**
3. Çerezde değeri **administrator+t'** olarak ayarla (**t'**, **(rator\x00\x00\x00 XOR t) XOR t**'nin geçerli bir imzası olacaktır = **rator\x00\x00\x00**
Örneğin "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" adında bir kullanıcı oluşturun ve çerezde herhangi bir desen olup olmadığını kontrol edin (ECB, her bloğu aynı anahtarla şifrelediği için, kullanıcı adı şifrelendiğinde aynı şifrelenmiş baytlar görünebilir).
Bir desen olmalıdır (kullanılan blok boyutunda). Bu nedenle, bir grup "a"nın nasıl şifrelendiğini bildiğinizde, "a"\*(blok boyutu)+"admin" şeklinde bir kullanıcı adı oluşturabilirsiniz. Sonra, "a" bloğunun şifrelenmiş desenini çerezden silebilirsiniz. Ve kullanıcı adı "admin"in çerezine sahip olabilirsiniz.
* **Şirketinizi HackTricks'te reklamını görmek istiyorsanız** veya **HackTricks'i PDF olarak indirmek istiyorsanız** [**ABONELİK PLANLARINI**](https://github.com/sponsors/carlospolop) kontrol edin!
* [**The PEASS Family'yi**](https://opensea.io/collection/the-peass-family) keşfedin, özel [**NFT'lerimiz**](https://opensea.io/collection/the-peass-family) koleksiyonumuzu
* 💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) katılın veya bizi Twitter'da 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)** takip edin.**