AWS Hacking öğrenin ve pratik yapın:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
GCP Hacking öğrenin ve pratik yapın: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* [**abonelik planlarını**](https://github.com/sponsors/carlospolop) kontrol edin!
* **Bize katılın** 💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) veya **Twitter'da****bizi takip edin** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
Bir çerezin son kullanma tarihi `Expires` niteliği ile belirlenir. Tersine, `Max-age` niteliği, bir çerezin silinmesine kadar geçen süreyi saniye cinsinden tanımlar. **Daha modern uygulamaları yansıttığı için `Max-age` seçin.**
Bir çerezi alacak olan ana bilgisayarlar `Domain` niteliği ile belirtilir. Varsayılan olarak, bu çerezi veren ana bilgisayara ayarlanır, alt alan adlarını içermez. Ancak, `Domain` niteliği açıkça ayarlandığında, alt alan adlarını da kapsar. Bu, `Domain` niteliğ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.
`Cookie` başlığının gönderilmesi için istenen URL'de bulunması gereken belirli bir URL yolu `Path` niteliği ile belirtilir. Bu nitelik, `/` karakterini bir dizin ayırıcı olarak kabul eder ve alt dizinlerde eşleşmelere de izin verir.
Tablo [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) kaynağından alınmış ve biraz değiştirilmiştir.\
_**SameSite**_ niteliğ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** **nitelikleri 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 **değerlendirilecek ve ardından üst düzey çapraz site POST isteği için Lax** olarak değerlendirilecektir.
* 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 **çerezleri** yanıtından **çalmayı** mümkün kılmak mümkündür (örneği kontrol edin [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/).
* Bu, **TRACE****HTTP** istekleri ile aşılabilir çünkü sunucudan gelen yanıt, gönderilen çerezleri yansıtacaktı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****aşmak** mümkündü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.
Dolayısıyla, `__Host-` ile başlayan çerezlerin korunmasından biri, alt alan adlarından üzerine 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, alt alan adlarından `__HOST-` ile başlayan çerezlerin ayarlanmasının, örneğin başına veya sonuna "=" ekleyerek, ayrıştırıcıyı kandırarak mümkün olduğu sunulmuştur:
Ya da PHP'de çerez adının başına **diğer karakterler ekleyerek**, bunların **alt çizgi** karakterleri ile **değiştirileceği** mümkün olmuştur, bu da `__HOST-` çerezlerini üzerine yazmaya olanak tanır:
Ç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.
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.
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.
Ç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ı belgeyi erişmeniz önerilir.
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.
(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:
Gönderilen çerez başlığındaki sonuç `a=v1; test value; b=v2;` şeklindedir. İlginç bir şekilde, bu, boş bir isim çerezi ayarlandığında çerezlerin manipüle edilmesine olanak tanır; boş çerezi belirli bir değere ayarlayarak diğer çerezleri potansiyel olarak kontrol etme imkanı sağlar:
(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 cookie dizelerini yanlış işler. Birden fazla noktalı virgül içerse bile, çift tırnak içinde bir cookie değerini tek bir değer olarak okurlar; bu, normalde anahtar-değer çiftlerini ayırması gereken bir durumdur:
(Daha fazla detay için [orijinal araştırmaya](https://blog.ankursundara.com/cookie-bugs/) bakın) Sunucuların, özellikle Undertow, Zope ve Python'un `http.cookie.SimpleCookie` ve `http.cookie.BaseCookie` kullananların, çerezleri yanlış analiz etmesi, çerez enjeksiyon saldırıları için fırsatlar yaratır. Bu sunucular, yeni çerezlerin başlangıcını doğru bir şekilde ayırt edemez, bu da saldırganların çerezleri taklit etmesine olanak tanır:
Bu açık, çerez tabanlı CSRF korumasına dayanan web uygulamalarında özellikle tehlikelidir, çünkü saldırganların taklit CSRF-token çerezlerini enjekte etmesine olanak tanır ve bu da güvenlik önlemlerinin aşılmasına neden olabilir. 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 atlamalarına yol açabilir.
* **Çerez**, her seferinde **aynıdır****giriş yaptığınızda**.
* Çı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örüp göremediğinizi kontrol edin.
* Varsa "**beni hatırla**" seçeneğini kontrol edin ve nasıl çalıştığını görün. Varsa ve savunmasız olabileceği düşünülüyorsa, 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.
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.
Eğer saldırı başarıyla gerçekleştirilmişse, o zaman seçtiğiniz bir dizeyi şifrelemeyi deneyebilirsiniz. Örneğin, **user=administrator****şifrelemek** isterseniz.
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.
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'**, **(rator\x00\x00\x00 XOR t) XOR t** = **rator\x00\x00\x00** için geçerli bir imza olacaktır)
Ö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ı anahtar ile ş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" 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.
AWS Hacking öğrenin ve pratik yapın:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
GCP Hacking öğrenin ve pratik yapın: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* [**abonelik planlarını**](https://github.com/sponsors/carlospolop) kontrol edin!
* **💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) katılın ya da **Twitter'da** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)** bizi takip edin.**
* **Hacking ipuçlarını paylaşmak için [**HackTricks**](https://github.com/carlospolop/hacktricks) ve [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github reposuna PR gönderin.**