flawopen.com/Désérialisation Java/Sécurité d’ObjectInputStream

ObjectInputStream est-il sûr avec des données non fiables ?

Référence de sécurité Java

En clair

En général, non : readObject() reconstruit des objets Java et peut exécuter leurs méthodes de désérialisation. C’est comme accepter un formulaire dont les pièces jointes exécutent aussi leurs propres consignes. Un flux hostile peut atteindre des classes déjà présentes. Le résultat dépend des classes, bibliothèques, chemins et frontières d’entrée ; chaque appel ne mène pas à une exécution.

RISQUÉ : désérialisation native

// Ne transmettez pas ici des octets contrôlés par un attaquant.
try (var in = new ObjectInputStream(untrustedStream)) {
    Object value = in.readObject();
    handle(value);
}

PLUS SÛR : analyser un type fixe

// Désactivez le typage polymorphe étendu pour les entrées non fiables.
ObjectMapper mapper = new ObjectMapper();
OrderRequest value = mapper.readValue(
    untrustedBytes, OrderRequest.class
);
validate(value);

Comment la faille devient atteignable

Une API, une file, un cache ou un import reçoit des octets contrôlés par l’utilisateur. S’ils atteignent ObjectInputStream.readObject(), la JVM restaure des objets de classes sérialisables du processus. Une chaîne de gadgets est un chemin possible dans le comportement de ces classes, pas une charge utile intégrée à chaque flux. Oracle a documenté CVE-2015-4852 : des attaques sans authentification via WebLogic T3 contre les versions listées. Cela ne rend pas tout usage d’ObjectInputStream accessible à distance.

Si la sérialisation native ne peut être supprimée

✓Préférez JSON ou Protocol Buffers avec schéma explicite ; mappez vers un DTO fixe et validez champs et droits.
✓Sinon, configurez un ObjectInputFilter contextuel avant readObject() ; n’autorisez que les classes exactes nécessaires.
✓Limitez profondeur, références, tableaux et octets selon les entrées valides mesurées. Une liste autorisée ne prévient pas l’épuisement des ressources.
✓N’activez pas le typage polymorphe étendu pour du JSON non fiable : des métadonnées de sous-type arbitraires peuvent recréer des objets.
✓Mettez Java et les dépendances à jour, retirez les bibliothèques inutiles et traitez les flux hérités avec des privilèges et ressources limités.

Question fréquente

ObjectInputFilter rend-il readObject() sûr ?

Il réduit le risque avec une liste étroite et des limites avant la lecture, mais ne constitue pas un assainisseur universel. Les classes autorisées, leur comportement et l’activation effective du filtre comptent ; validation et autorisation restent nécessaires. Évitez la sérialisation native de données contrôlées par l’utilisateur.

Sources primaires

À voir aussi Désérialisation non sécurisée : risques et défense Newtonsoft.Json TypeNameHandling : configuration sûre ? PHP unserialize() et les données non fiables Python pickle.load() : risques des données non fiables Ruby YAML.load est-il sûr ? Versions de Psych et safe_load .NET BinaryFormatter : risques et migration