mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00

History

Translator 19f4e55921 Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/REA		2024-04-07 03:13:19 +00:00
..
cookie-bomb.md	Translated to Turkish	2024-02-10 18:14:16 +00:00
cookie-jar-overflow.md	Translated to Turkish	2024-02-10 18:14:16 +00:00
cookie-tossing.md	Translated ['pentesting-web/hacking-with-cookies/cookie-tossing.md'] to	2024-04-04 08:57:38 +00:00
README.md	Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/REA	2024-04-07 03:13:19 +00:00

README.md

Çerez Hacking

AWS hacklemeyi sıfırdan kahraman seviyesine öğrenin htARTE (HackTricks AWS Red Team Expert) ile!

HackTricks'ı desteklemenin diğer yolları:

Şirketinizi HackTricks'te reklamınızı görmek istiyorsanız veya HackTricks'i PDF olarak indirmek istiyorsanız ABONELİK PLANLARI'na göz atın!
Resmi PEASS & HackTricks ürünlerini edinin
PEASS Ailesi'ni keşfedin, özel NFT'lerimiz koleksiyonumuz
Katılın 💬 Discord grubuna veya telegram grubuna veya bizi Twitter 🐦 @carlospolopm** takip edin.**
Hacking püf noktalarınızı paylaşarak HackTricks ve HackTricks Cloud github depolarına PR göndererek.

Try Hard Güvenlik Grubu

{% embed url="https://discord.gg/tryhardsecurity" %}

Çerez Özellikleri

Ç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:

Son Kullanma Tarihi ve Max-Age

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.

Alan

Bir çerezi alacak ana bilgisayarlar, Domain özelliği tarafından belirtilir. Varsayılan olarak, bu, çerezi veren ana bilgisayar olarak 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.

Yol

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.

Sıralama Kuralları

Aynı ada sahip iki çerez olduğunda, gönderilecek olan çerez şu kriterlere dayanarak seçilir:

İstenen URL'deki en uzun yolu eşleştiren çerez.
Yollar aynıysa en son ayarlanan çerez.

SameSite

SameSite özelliği, üçüncü taraf alanlarından kaynaklanan isteklerde çerezlerin gönderilip gönderilmeyeceğini belirler.
Üç ayar sunar:
- Strict: Çerezi üçüncü taraf isteklerinde göndermeyi kısıtlar.
- Lax: Üçüncü taraf web siteleri tarafından başlatılan GET istekleriyle çerezin gönderilmesine izin verir.
- None: Çerezi herhangi bir üçüncü taraf alanından göndermeye izin verir.

Çerezleri yapılandırırken, bu özellikleri anlamak, farklı senaryolarda beklenen şekilde davranmalarını sağlamaya yardımcı olabilir.

İstek Türü	Örnek Kod	Çerezler Gönderilirken
Bağlantı	<a href="..."></a>	NotSet*, Lax, None
Önizleme	<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

Invicti tarafından hazırlanan ve hafifçe değiştirilmiş tablo.
SameSite özelliğine sahip bir çerez, oturum gerektiren CSRF saldırılarını azaltır.

*Unutmayın ki Chrome80'den (şubat/2019) itibaren, aynı site ö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/).
Bu değişiklik uygulandıktan sonra, Chrome'da aynı site 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.

Çerez Bayrakları

HttpOnly

Bu, istemcinin çereze erişmesini engeller (Örneğin Javascript aracılığıyla: document.cookie)

Atlatmalar

Eğer sayfa, çerezleri bir isteğin yanıtı olarak gönderiyorsa (örneğin bir PHPinfo sayfasında), XSS'i kötüye kullanarak bu sayfaya bir istek gönderip yanıtından çerezleri çalmak mümkün olabilir (örneği https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/ adresinde bulabilirsiniz).
Bu, sunucudan gelen yanıt olarak TRACE HTTP isteklerini göndererek atlatılabilir (bu HTTP yöntemi mevcutsa). Bu teknik Çapraz Site Takibi olarak adlandırılır.
Bu teknik, JS'den TRACE isteği göndermeyi engelleyen modern tarayıcılar tarafından önlenir. Ancak, IE6.0 SP2 gibi belirli yazılımlarda, bu engeli aşmanın bazı yolları bulunmuştur, örneğin TRACE yerine \r\nTRACE göndermek.
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şma saldırısı gerçekleştirerek HttpOnly çerezlerin üzerine yazılabilir:

{% content-ref url="cookie-jar-overflow.md" %} cookie-jar-overflow.md {% endcontent-ref %}

Bu çerezleri dışarıya çıkarmak için Çerez Kaçırma saldırısını kullanmak mümkündür

Güvenli

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

Çerez Önekleri

__Secure- ile başlayan çerezlerin, HTTPS ile korunan sayfalardan gelen secure bayrağı ile birlikte ayarlanması gerekmektedir.

__Host- ile başlayan çerezler için birkaç koşul karşılanmalıdır:

secure bayrağı ile ayarlanmalıdır.
HTTPS ile korunan bir sayfadan kaynaklanmalıdır.
Alt alanlara iletilmesini engellemek için bir alan belirtmemelidir.
Bu çerezlerin yolu / olarak ayarlanmalıdır.

__Host- ile başlayan çerezlerin süper alanlara veya alt alanlara gönderilmesine izin verilmediğini unutmamak ö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.

Çerezleri Üzerine Yazma

Yani, __Host- ön ekli çerezlerin korunmasından biri, bunların alt alanlardan üzerine yazılmasını engellemektir. Örneğin Çerez Atma saldırıları engellenir. Çerez Parçalanıyor: Web Oturum Bütünlüğü Güvenlik Açıklıkları Ortaya Çıkarılıyor adlı sunumda (makale) alt alanlardan __HOST- ön ekli çerezlerin ayarlanabileceği, örneğin, ayracı kandırarak mümkün olduğu sunuldu, örneğin, başa "=" ekleyerek veya başa ve sona "=" ekleyerek...:

Ya da PHP'de çerez adının başına başka karakterler eklemek mümkün olabilir ve bu karakterlerin alt çizgi karakterleriyle değiştirileceği, böylece __HOST- çerezlerin üzerine yazılmasına izin verilebilir:

Çerez Saldırıları

Özel bir çerez hassas veri içeriyorsa kontrol edin (özellikle bir CTF oynuyorsanız), zira zayıf olabilir.

Çerezlerin Kodunu Çözme ve Manipüle Etme

Ç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ştirmesine ve değiştirilmiş verilerini çerez içine kodlayarak diğer kullanıcıları taklit etmesine olanak tanır.

Oturum Kaçırma

Bu saldırı, bir kullanıcının çerezini çalarak bir uygulama içindeki hesabına izinsiz 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 çerez kullanmaya kandırır. 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.

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

{% content-ref url="cookie-tossing.md" %} cookie-tossing.md {% endcontent-ref %}

Oturum Bağışı

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 işlemler gerçekleştirir.

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

{% content-ref url="cookie-tossing.md" %} cookie-tossing.md {% endcontent-ref %}

JWT Çerezleri

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) de zayıflıklar içerebilir. JWT'yi hacklemek için bağlantılı belgeye erişmek, potansiyel hatalar ve bunları nasıl kullanabileceğiniz hakkında detaylı bilgi için önerilir.

Cross-Site Request Forgery (CSRF)

Bu saldırı, oturum açık olan bir kullanıcıyı, şu anda kimlik doğrulaması yapılan bir web uygulamasında istenmeyen eylemleri gerçekleştirmeye zorlar. Saldırganlar, her istekle otomatik olarak gönderilen çerezleri kullanarak savunmasız siteye saldırabilir.

Boş Çerezler

(Detaylı bilgiler için orijinal araştırmaya bakın) Tarayıcılar, adı olmayan çerezlerin oluşturulmasına izin verir, bu da JavaScript aracılığıyla gösterilebilir.

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 değeri; b=v2; şeklindedir. İlginç bir şekilde, boş bir isim çerezi ayarlandığında diğer çerezlerin kontrol edilmesine olanak tanır, boş çerezi belirli bir değere ayarlayarak diğer çerezleri kontrol etmek mümkün olabilir:

function setCookie(name, value) {
document.cookie = `${name}=${value}`;
}

setCookie("", "a=b"); // Setting the empty cookie modifies another cookie's value

Chrome Hatası: Unicode Yedek Kod Nokta Sorunu

Chrome'da, bir Unicode yedek kod noktası bir set çerezi parçasıysa, document.cookie bozulur ve ardından boş bir dize döndürür:

document.cookie = "\ud800=meep";

Bu, document.cookie'nin boş bir dize çıktısı vermesine neden olarak kalıcı bir bozulmayı gösterir.

Ayrıştırma Sorunları Nedeniyle Çerez Kaçırma

(Daha fazla ayrıntı için orijinal araştırmaya bakın) Java (Jetty, TomCat, Undertow) ve Python (Zope, cherrypy, web.py, aiohttp, bottle, webob) dahil birçok web sunucusu, eski RFC2965 desteğinden dolayı ç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:

RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";

Çerez Enjeksiyonu Güvenlik Açıklıkları

(Sonuçlarıorijinal araştırmada 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, bu da saldırganların çerezleri sahtelemesine olanak tanır:

Undertow, bir tırnak içindeki bir değerden sonra noktalı virgül olmadan hemen yeni bir çerez bekler.
Zope, bir sonraki çerezi ayrıştırmaya başlamak için bir virgül arar.
Python'ın çerez sınıfları, boşluk karakterinde ayrışmaya başlar.

Bu zayıflık, çerez tabanlı CSRF korumasına güvenen web uygulamalarında özellikle tehlikelidir, çünkü saldırganlara sahte CSRF belirteci çerezleri enjekte etme olanağı sağlar ve güvenlik önlemlerini atlayabilir. Sorun, Python'ın çift çerez adlarını işleme şekli tarafından daha da 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.

Ekstra Savunmasız Çerez Kontrolleri

Temel kontroller

Çerez, her giriş yaptığınızda aynı kalı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ı adları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. Eğer varsa ve savunmasız olabilirse, her zaman sadece beni hatırla çerezini kullanın, başka çerez kullanmayın.
Şifrenizi değiştirdikten sonra önceki çerezin hala çalışıp çalışmadığını kontrol edin.

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

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, çok benzer kullanıcı adlarıyla ve algoritmanın nasıl çalıştığını tahmin etmeye çalışın.
Kullanıcı adını bruteforce etmeye çalışın. 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 bruteforce edebilirsiniz çünkü deneyeceğiniz çerezlerden biri "admin"e ait olacaktır.
Padding Oracle deneyin (çerezin içeriğini şifreleyebilirsiniz). Padbuster kullanın.

Padding Oracle - Padbuster örnekleri

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 hangi koşulun hata koşulu olduğunu (geçerli olmayanı) soracaktır.

Daha sonra çerezin şifresini çözmeye başlayacaktır (birkaç dakika sürebilir).

Saldırı başarıyla gerçekleştirildiyse, istediğiniz bir dizeyi şifrelemeyi deneyebilirsiniz. Örneğin, eğer user=admin gibi bir dizeyi şifrelemek isterseniz.

padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator

Bu işlem, içinde user=administrator dizesi bulunan çerezin doğru bir şekilde şifrelenmiş ve kodlanmış halini size verecektir.

CBC-MAC

Belki bir çerez bir değere sahip olabilir ve CBC kullanılarak imzalanabilir. Sonra, değerin bütünlüğü, aynı değeri kullanarak CBC'yi 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.

Saldırı

Kullanıcı adı administ'in imzasını al = t
Kullanıcı adı rator\x00\x00\x00 XOR t'nin imzasını al = t'
Ç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

ECB

Ç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 sahip 2 kullanıcı oluşturun (kullanıcı adı, şifre, e-posta vb.) ve verilen çerezde 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 (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" için çerezi elde edebilirsiniz.

Referanslar

Try Hard Security Group