Cookies Hacking
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Cookies, kullanıcının tarayıcısındaki davranışlarını kontrol eden birkaç özellik ile gelir. İşte bu özelliklerin daha pasif bir sesle açıklaması:
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.
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.
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.
İki çerez aynı adı taşıdığında, gönderilmek üzere seçilen çerez:
İstenen URL'deki en uzun yolu eşleştiren çerez.
Yollar aynıysa en son ayarlanan çerez.
SameSite özelliği, çerezlerin üçüncü taraf alan adlarından gelen isteklere 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 adı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.
Request Type | Example Code | Cookies Sent When |
Link | <a href="..."></a> | NotSet*, Lax, None |
Prerender | <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 |
Image | <img src="..."> | NetSet*, None |
Tablo Invicti kaynağından alınmış ve biraz değiştirilmiştir. SameSite özelliğine sahip bir çerez, CSRF saldırılarını azaltacaktır.
*Chrome80 (şubat/2019) itibarıyla, bir çerezin samesite özelliği olmayan varsayılan davranışı lax olacaktır (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.
Bu, istemcinin çereze erişimini engeller (Örneğin Javascript ile: document.cookie)
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://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şma yöntemleri bulunmuştur.
Diğer bir yol, tarayıcıların sıfır/günlük açıklarını istismar etmektir.
Bir Çerez Kavanozu taşma saldırısı gerçekleştirerek HttpOnly çerezlerini aşmak mümkündür:
Bu çerezleri dışarı aktarmak için Cookie Smuggling saldırısı kullanılabilir.
İstek, çerezi yalnızca güvenli bir kanal üzerinden (genellikle HTTPS) iletilirse gönderecektir.
__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 iletimini engellemek için bir alan adı 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 ekini kullanmak, 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ı önlemek. Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) 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 izin vermektedir:
Özel bir çerez hassas veriler içeriyorsa, bunu kontrol edin (özellikle bir CTF oynuyorsanız), çünkü bu savunmasız olabilir.
Ç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.
Eğer bir alt alan adında XSS bulduysanız veya bir alt alan adını kontrol ediyorsanız, okuyun:
Cookie TossingBurada, 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:
Cookie TossingJWT'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'yi hackleme 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 bakın) Tarayıcılar, isim olmadan çerezlerin 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;. İ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:
Bu, tarayıcının her web sunucusu tarafından a adında ve b değerinde bir çerez olarak yorumlanan bir çerez başlığı göndermesine yol açar.
Chrome'da, bir Unicode yedek kod noktası ayarlanmış bir çerezin parçasıysa, document.cookie bozulur ve sonrasında boş bir dize döner:
Bu, document.cookie'nin boş bir dize döndürmesine neden olur ve kalıcı bir bozulmayı gösterir.
(Daha fazla detay için orijinal araştırmaya 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 değer içerse bile, çift tırnak içinde bir cookie değerini tek bir değer olarak okurlar; bu değerler genellikle anahtar-değer çiftlerini ayıran noktalı virgülleri içermelidir:
(Check further details in theoriginal research) Sunucuların çerezleri yanlış analiz etmesi, özellikle Undertow, Zope ve Python'un http.cookie.SimpleCookie ve http.cookie.BaseCookie kullananlar, çerez enjeksiyon 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 yeni bir ç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 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 kullanmaya çalışın.
Aynı çerezi kullanarak 2 cihazla (veya tarayıcıyla) aynı hesaba giriş yapmayı deneyin.
Çerezde 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 kontrol edin.
Varsa "beni hatırla" seçeneğini kontrol edin ve nasıl çalıştığını görün. Varsa ve savunmasız olabilecekse, 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.
Çerez giriş yaptığınızda aynı (veya neredeyse) 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 etmeye çalışın. 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
Padbuster birkaç deneme yapacak ve sizden hangi durumun hata durumu olduğunu (geçersiz olan) soracaktır.
Daha sonra çerezi deş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.
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. Bu durumda, değerin bütünlüğü, aynı değerle CBC kullanılarak oluşturulan imzadır. IV olarak sıfır vektörü kullanılması önerildiğinden, bu tür bir bütünlük kontrolü savunmasız olabilir.
Saldırı
Kullanıcı adı administ için imzayı al = t
Kullanıcı adı rator\x00\x00\x00 XOR t için imzayı al = t'
Ç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)
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ı 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'i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
