Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Insecure Deserialization

hacking

Définition

L'insecure deserialization est une vulnérabilité catégorisée dans l'OWASP Top 10 qui englobe tous les cas où une application désérialise des données sans validation suffisante, permettant à un attaquant de manipuler des objets sérialisés pour modifier la logique applicative, escalader des privilèges, ou exécuter du code arbitraire. Elle est distincte mais reliée aux attaques de désérialisation avec gadget chains. Au-delà des RCE via gadget chains (voir Deserialization Attack), l'insecure deserialization couvre : la manipulation de cookies et tokens de session sérialisés (modifier le rôle, l'ID utilisateur, ou l'expiration dans un cookie PHP sérialisé), les injections via des objets Java/PHP désérialisés qui modifient l'état de l'application, et les attaques de type substitution d'objet (remplacer un objet d'un type par un objet d'un type compatible mais avec des propriétés différentes). Un exemple courant en PHP : une application stocke dans un cookie l'objet utilisateur sérialisé O:4:'User':2:{s:4:'name';s:5:'Alice';s:4:'role';s:4:'user';}. L'attaquant modifie ce cookie (sans signature/MAC) vers O:4:'User':2:{s:4:'name';s:5:'Alice';s:4:'role';s:5:'admin';} — si l'application désérialise et fait confiance à ce cookie, l'attaquant est maintenant admin. Des sessions Rails basées sur des cookies marshalisés (avant Rails 5.2 avec encryption obligatoire), des tokens JWT sans validation d'algorithme, et des paramètres de cache Ruby Marshal ont été exploités de cette manière.

Fonctionnement

Identification : rechercher des cookies ou paramètres encodés qui ressemblent à des objets sérialisés : base64 commençant par 'rO0AB' (Java), 'O:' (PHP), '\x80\x04' (Python pickle), gzip/deflate d'objets. Décodage et manipulation : base64 -d cookie.txt | python3 -c 'import pickle,sys; print(pickle.loads(sys.stdin.buffer.read()))'. Modifier les propriétés, re-sérialiser, re-encoder. Soumettre le cookie modifié. Si pas de MAC/signature, l'application accepte les modifications.

Exploitation offensive

Les applications legacy PHP et Ruby on Rails qui stockent des états dans des cookies sérialisés sans signature sont particulièrement vulnérables. Des applications d'e-commerce ont été compromises en modifiant des prix dans des cookies de panier sérialisés. Des escalades de privilèges sur des panels admin ont été réalisées en modifiant le rôle dans un cookie de session.

Détection et mitigation

Signer cryptographiquement tous les données sérialisées avec un HMAC (Rails secret_key_base, token de signature JWT). Ne jamais faire confiance aux objets sérialisés sans validation de leur intégrité. Utiliser des formats de sérialisation sans support d'exécution de code (JSON au lieu de pickle/Marshal). Implémenter des filtres de désérialisation (Java ObjectInputFilter) pour les cas où la désérialisation native est nécessaire.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis