Le cookie qui était un objet : repérer la désérialisation Java
Le défi
L'application Java de Pennywharf stocke votre session dans un cookie et lui fait confiance au retour. Le cookie n'est ni un token signé ni du JSON : c'est l'objet de session brut, encodé. Cela a son importance, car si le serveur reconstruit un objet directement à partir d'octets envoyés par un client, c'est le client qui choisit ce qui est construit. Décodez le cookie dans le workbench et lisez la signature tout au début. Nommez le format dans lequel ce cookie se trouve réellement.
Ce que tu vas apprendre
- Décoder un blob en base64 et lire ses magic bytes de tête
- Reconnaître ac ed 00 05 comme l'en-tête d'un flux de sérialisation Java
- Expliquer pourquoi désérialiser des octets contrôlés par le client est dangereux
- Lister les signatures en début de blob pour Java, pickle, .NET et PHP
- Énoncer l'alternative sûre : des identifiants de session opaques et des formats ne contenant que des données
Compétences testées
Prérequis
- Savoir ce qu'est le base64
- Savoir que les fichiers et les blobs commencent par une signature
Comment ça marche
Un cookie qui conserve un état peut le faire de deux façons sûres : un identifiant opaque qui pointe vers des données côté serveur, ou un token signé qui ne contient que des données. Il peut aussi le faire de la façon dangereuse, en embarquant l'objet lui-même, sérialisé. Quand le serveur relit ce cookie, il reconstruit un objet directement à partir d'octets envoyés par le client.
Chaque format de sérialisation s'annonce dès le début. Les flux Java commencent par ac ed 00 05 (en base64 : rO0AB). Le décodage de ce cookie montre exactement cela, suivi d'un descripteur de classe. Reconstruire un tel objet exécute des chemins de code choisis par l'attaquant, et avec les bonnes classes présentes, cela devient une exécution de code à distance. Aucune clé n'est en jeu, car rien n'a été chiffré.
Identifier le blob est le premier réflexe : 80 04 / gASV est un pickle Python, AAEAAAD///// est du .NET, O:4: est du PHP.
Erreurs fréquentes
- Le prendre pour un JWT. Il n'y a pas de points ni de découpage en header/payload/signature, et il ne se décode pas en JSON.
- S'arrêter au nom de la classe. Le
com.loomhaus.Sessionlisible est un indice, mais la signatureac ed 00 05est la preuve. - Chercher une clé. Le cookie est encodé, pas chiffré : From Base64 suffit pour tout décoder.
- Répondre
base64. Le base64 est l'enveloppe de transport, pas la nature des octets.
Comment s'en protéger
Ne reconstruisez pas d'objets à partir d'une entrée que le client peut définir.
- Gardez l'état de session côté serveur, derrière un identifiant opaque, aléatoire et impossible à deviner. Le cookie doit porter l'identifiant, jamais l'objet.
- Si l'état doit transiter par le client, utilisez un format ne contenant que des données (JSON), analysé vers des champs connus, et signez-le pour qu'il ne puisse pas être altéré.
- Si un chemin hérité doit absolument désérialiser, utilisez des allowlists strictes de classes autorisées et gardez les bibliothèques de gadgets dangereuses hors du classpath.