La sérialisation en Java, une « horrible erreur » ? Oracle prévoit de la supprimer

La sérialisation en Java, une « horrible erreur » ? Oracle prévoit de la supprimer
car elle serait la source de bon nombre de problèmes de sécurité

Oracle prévoit de supprimer la prise en charge de la fonctionnalité de sérialisation / désérialisation des données du langage Java. C'est ce qu'a révélé Mark Reinhold, l'architecte en chef de la plateforme Java chez Oracle.

Pour information, la sérialisation est un mécanisme introduit dans les tout débuts de Java (JDK 1.1), en 1997. Ce mécanisme permet d’écrire des données présentes en mémoire (un objet par exemple) dans un format de données binaires, permettant alors de rendre persistant l’élément via un stockage disque, une transmission réseau ou autre. La désérialisation est l'activité réciproque qui permet d'utiliser l'objet sous sa forme originale. Java fournit donc un certain nombre d’outils permettant de sérialiser ou désérialiser de manière transparente et indépendante du système.

En raison de sa commodité, un grand nombre de langages de programmation prennent en charge cette fonctionnalité, mais pour Java, elle a été ces dernières années impliquée dans de nombreuses failles de sécurité. C'est ce qui motive d'ailleurs Oracle à vouloir la supprimer maintenant. L'ajout du support de la sérialisation à Java en 1997 était une « horrible erreur », affirme Mark Reinhold, alors qu'il explique qu'au moins un tiers - peut-être même la moitié - des vulnérabilités Java impliquent la sérialisation.

Pour comprendre les propos de l'architecte en chef du JDK chez Oracle, revenons d'abord au problème de sécurité de la sérialisation en Java. Notons avant d'aller plus loin que les attaques via des opérations de sérialisation sont connues depuis des années, sous une forme ou une autre. Elles sont toutefois devenues un problème sérieux après des découvertes faites par des chercheurs en 2015. D'abord à la conférence AppSec Californie en janvier 2015, deux chercheurs - Chris Frohoff et Gabriel Lawrence - ont présenté leurs travaux et des outils pour exploiter des mécanismes de sérialisation et les utiliser à des fins malveillantes.

En novembre 2015, des chercheurs de FoxGlove Security vont plus loin et révèlent qu'un certain nombre de bibliothèques Java chargées par défaut par les serveurs applicatifs (WebSphere, Jboss, WebLogic, etc.) sont vulnérables à des attaques par désérialisation. Et parmi ces bibliothèques se trouve Apache Commons Collections, un module Java très populaire.

Pour information, Apache Commons est un projet de la fondation Apache, dont le but est de fournir un ensemble de bibliothèques réutilisables et open source pour Java. Elles sont de ce fait, largement employées dans bon nombre de projets open source en Java. Apache Commons se décompose en un nombre important de modules, dont les utilisés sont Commons Collections, Commons DBCP, Commons IO, Commons Lang, Commons Logging et Commons Pool.

Fin 2015, en dehors d'Apache Commons Collections, plusieurs dizaines d'autres bibliothèques ont été déclarées vulnérables, ce qui a nécessité la mobilisation des organisations telles qu'Apache, Oracle, Cisco, Red Hat, Jenkins, VMWare et IBM, entre autres, qui ont publié des correctifs de sécurité pour leurs produits. Malgré cela, la sérialisation continue d'être une source importante de problèmes de sécurité pour la plateforme. Ce qui conduit Mark Reinhold aujourd'hui à penser que c'était une « horrible erreur ».

https://www.developpez.com/public/im.../javasec02.png

L'équipe Java d'Oracle travaille donc actuellement sur la suppression de la prise en charge de la sérialisation. Toutefois, il ne s'agit pas de la supprimer complètement puisqu'il sera fourni aux développeurs un système de plug-in pour prendre en charge les opérations de sérialisation via un nouveau framework. Précisons aussi que la suppression de cette fonctionnalité est un objectif à long terme, donc la date de sa finalisation n'est pas encore définie. Mais jusqu'à ce qu'Oracle la supprime, les entreprises et les chefs de projet qui ne veulent pas qu'un développeur ou module appelle des fonctions de sérialisation ou désérialisation peuvent empêcher cela via un "filtre de sérialisation" qui a été ajouté dans Java en 2016 pour bloquer toutes ces opérations.

:fleche: En savoir plus sur la vulnérabilité de sérialisation en Java

Source : Mark Reihnold, architecte en Chef du JDK chez Oracle

Et vous ?

:fleche: Que pensez-vous de la décision d'Oracle ?
:fleche: Utilisez-vous souvent la sérialisation en Java ? Est-ce une horrible erreur ?
:fleche: Les plateformes telles que .NET, Ruby et autres sont-elles déjà protégées contre ces attaques ?

Voir aussi :

:fleche: JavaFX SDK Early Access disponible pour le JDK 11 et un miroir GitHub du projet OpenJFX mis en place
:fleche: Java SE 8 : les mises à jour publiques seront disponibles jusqu'à décembre 2020 minimum pour les fonctionnalités non commerciales
:fleche: Java : proposition en open source pour Mission Control, l'outil de profilage et d'analyse des performances d'Oracle
:fleche: JDK 11 : trois nouveautés sont prévues ainsi que la suppression de JAVA EE, JavaFX et CORBA, dans le cadre des mises à jour semestrielles
:fleche: Tutoriel : La sérialisation binaire en Java

Ça serait une bonne chose que Java modifie la manière dont est gérée la sérialisation car c'est effectivement une passoire d'un point de vue sécurité.

Mais aller jusqu'à supprimer une fonctionnalité si basique, cela me semble une très mauvaise idée.

Si les gens doivent sérialiser leurs objets manuellement ou utiliser des bibliothèques tierces (plus ou moins supportées), ça pourrait faire fuir beaucoup de gens de Java. La sérialisation c'est très simple à faire manuellement mais cela ne signifie pas que tout le monde soit près à le faire.

Par ailleurs, puisque énormément de code utilise la sérialisation, supprimer son support c'est rendre tous ces codes incompatibles avec les futures versions de JAVA

Bref, ce serait vraiment aller contre le sens du progrès.

[TROLL] Mais cela ne m'étonne pas d'Oracle, qui à l'habitude de changer l'or en plomb...:weird: [/TROLL]

Citation:

---

Que pensez-vous de la décision d'Oracle ?

---

Oui ça sert à rien, il existe des format tierce (JSON, XML) pour sérialiser des objets, et aussi des SGBD (et son équivalent pour le NoSql).

Citation:

---

Utilisez-vous souvent la sérialisation en Java ? Est-ce une horrible erreur ?

---

Non. C'est pas très compliqué à écrire. Mais c'est plus dur à maintenir.

Citation:

---

Les plateformes telles que .NET, Ruby et autres sont-elles déjà protégées contre ces attaques ?

---

J'en sais rien. Mais utiliser des standards permet de migrer plus facilment d'une plateforme à une autre.

je pense que la serialisation dans Java ne servait a rien. Mieux vaut serialiser en XML ou json ou meme dans sqlite, c'est bien mieux. Je pense que leur decision de le mettre dans une librairie est la meilleure chose à faire

EDIT: +1 pour supergeoffrey

Bonjour,


La sérialisation Java n'est certe par parfaite:

• Incompatibilité de sérialisation/désérialisation des objets entre les différentes versions de la JVM
• Interopérabilité avec les autres langages quasi inexistante (ex: Sérialiser un objet Java, puis le récupérer dans un programme C#)
• Vitesse de sérialisation/désérialisation plus lente et poids des objets plus élevés que ceux des technos plus récentes (gRPC ou Thrift Compact)

Par contre il y a tellement de librairies qui reposent sur la sérialisation Java qu'il sera difficile de s'en passer, RMI en fait parti.


A+

Citation:

---

Envoyé par supergeoffrey

Oui ça sert à rien, il existe des format tierce (JSON, XML) pour sérialiser des objets

---

J'ai l'impression de vivre dans un autre monde... Sérialiser en mode texte? sérieusement? à quoi ça peut servir un truc aussi gourmand?
Je ne suis pas dans le web, donc je ne sais pas l'utilité que vous avez de la sérialisation, mais personnellement on l'utilise soit entre applications sur la même machine, soit sur le réseau en radio.
En local, sur les petits objets pourquoi pas, mais dès que ça part sur du réseau, faire passer du texte est horriblement inefficient...

On utilise surtout google protocol buffer pour ça. ça marche plutôt bien.

Le binaire il n'y a que ça d'efficace!

Citation:

---

Pour information, la sérialisation est un mécanisme introduit dans les tout débuts de Java (JDK 1.1), en 1997. Ce mécanisme permet d’écrire des données présentes en mémoire (un objet par exemple) dans un format de données binaires, permettant alors de rendre persistant l’élément via un stockage disque, une transmission réseau ou autre. La désérialisation est l'activité réciproque qui permet d'utiliser l'objet sous sa forme originale. Java fournit donc un certain nombre d’outils permettant de sérialiser ou désérialiser de manière transparente et indépendante du système.

---

:weird: ASCII, ANSI, etc... ?

Citation:

---

Ça serait une bonne chose que Java modifie la manière dont est gérée la sérialisation car c'est effectivement une passoire d'un point de vue sécurité.

Mais aller jusqu'à supprimer une fonctionnalité si basique, cela me semble une très mauvaise idée.

---

Soit c'est une variable public qui gène une donnée "globale ou public". Soit c'est une variable private ou protected qui peut transmettre aisément à du non autorisé ou c'est une histoire de certificat /chiffrement comme les certificats réseaux (

Oui, l'adresse MAC réseau n'est pas forcément fixe à un HW.)...

Je crois qu'ils auront des soucis qu'a l'accès de l'information de façon "public".

Citation:

---

• Incompatibilité de sérialisation/désérialisation des objets entre les différentes versions de la JVM

---

C'est donc un " dump " de la mémoire de la JVM... :weird:
Injection de codes malicieux ?

Citation:

---

Envoyé par AoCannaille

google protocol buffer

---

Utilisable dans un cluster de plusieurs machines constituant une machine massivement parallèle ? (calcul)
Relié de façon natif des barrettes mémoires en réseau... :weird::?

Citation:

---

Envoyé par emixam16

Par ailleurs, puisque énormément de code utilise la sérialisation, supprimer son support c'est rendre tous ces codes incompatibles avec les futures versions de JAVA

---

Ah bah oui mais y'a pas de magie, hein. C'est une faille de sécurité ambulante, parce que ça fonctionne comme ça au lieu de fonctionner autrement. Du coup, ben, si tu casses pas la fonctionnalité existante, tu gardes les failles de sécurité comme elles sont. Logique.

Citation:

---

Envoyé par AoCannaille

J'ai l'impression de vivre dans un autre monde... Sérialiser en mode texte? sérieusement? à quoi ça peut servir un truc aussi gourmand?

---

Même chose que la science, ça sert à marcher, b****** ! (Euh, je crois que c'est, "brelan de dames".)

Citation:

---

Envoyé par AoCannaille

On utilise surtout google protocol buffer pour ça. ça marche plutôt bien.

---

Honnêtement, dès que je veux faire de la communication un peu lourde, j'utilise protocol buffer, oui. Les quelques pourcents économisés ont de la valeur à mes yeux.

Mais la différence fondamentale c'est que protocol buffer il faut lui configurer un modèle, le compiler, vérifier sa validité, le lier aux classes, etc. Il ne marche pas tout seul, il demande du travail.

XML et JSON marchent tout seul pour une utilisation simpliste, et ne demandent pas beaucoup de boulot quand on les connaît bien pour une utilisation plus universelle. Sensiblement moins de boulot que protocol buffer en tout cas.

C'est à ça que ça sert un protocole texte, lourdingue et universel. Ça marche, b******. Rien de plus ni de moins. Même raison pour laquelle le web est ce qu'il est. En principe ça devrait paraître tout autant ridicule tout ce texte dans le protocole le plus Universel de la planète. Et c'est lui qui c'est imposé. Parce que lui, il marche.

Pour avoir pas mal travaillé avec des protocoles binaires, un des gros avantages de la sérialisation textuelle, c'est sa rapidité de debug, on voit tout de suite ou est le problème.

Sinon, on n'est pas obligé d'utiliser json/xml pour sérialiser rapidement des données, en java il existe Preon (présentation), une lib qui fait très bien le travaille (et qui permet de spécifier au bit près le mapping sur les champs de la structure) et si on a besoin interopérabilité, on peut utiliser le format BSON (format de stockage de MongoDB), qui s'il n'est pas normalisé, est populaire.

C'est la même chose dans tout les languages, il faut pas "deserializer" des données qui ne sont pas sûre (Never Trust User Input).

Exemple avec Python: https://docs.python.org/3.6/library/pickle.html

Citation:

---

Warning The pickle module is not secure against erroneous or maliciously constructed data. Never unpickle data received from an untrusted or unauthenticated source.

---

Le principe même de la serialization n'est pas sûr car on peut potentiellement bypasser les vérifications qui sont normalement faite a la construction et l'objet pour y passer tout ce qu'on veut.

Citation:

---

XML et JSON marchent tout seul pour une utilisation simpliste, et ne demandent pas beaucoup de boulot quand on les connaît bien pour une utilisation plus universelle. Sensiblement moins de boulot que protocol buffer en tout cas.

---

Surtout que si on cherche java serialization XML sur Google.fr on tombe la dessus https://ydisanto.developpez.com/tuto...ation/partie2/ :) La sérialisation XML est déjà prévu ...

En JSON bon d'accord faut un com.google.gson.Gson

Cela fait longtemps que je n'ai pas fait de Java mais si le problème est l’origine de la source de données pourquoi supprimer la sérialisation ?

Plus le temps passe plus j'ai l'impression qu'Oracle veut tuer Java, un jour il sortirons un langage propriétaire implémentant tout ce qu'il aurons supprimer de Java avec un outils de conversion OracleIKVM, très très chère.

Comme on dit chez nous "dans le cul lulu" :)

Citation:

---

Le principe même de la serialization n'est pas sûr car on peut potentiellement bypasser les vérifications qui sont normalement faite a la construction et l'objet pour y passer tout ce qu'on veut.

---

Tu veut dire que lors de la dé sérialisation un bloc mémoire est créer ,valoriser, et que l'instance résultant est le pointeur vers cette adresse (dans cas oui c'est critique) ?

J'ai un sérieux doute à ce sujet , dans mon esprit je penchait plutôt pour une construction de l'objet par introspection, en instanciant la classe via son constructeur et en invoquant les accesseurs des propriétés.

Déduction faite de l'impossibilité de sérialisé des objets avec un seul constructeur comportant des arguments, mais je ne suis pas expert Java.

Citation:

---

Envoyé par _champy_

Cela fait longtemps que je n'ai pas fait de Java mais si le problème est l’origine de la source de données pourquoi supprimer la sérialisation ?

---

Parce que l'écosystème Java foisonne de bibliothèques tierces qui nous aident à faire du travail qu'elles savent faire à notre place. Et certaines utilisent la sérialisation. D'autres offrent des outils pour s'en servir.

À cause de cela, si tu fais un projet un tant soit peu sérieux et sur lequel tu n'as pas pris à cœur de tout implémenter toi-même, alors tu as très certainement de nombreuses parties de ton code qui utilisent la sérialisation/désérialisation de manière plus ou moins prévisible ou évidente.

Et tu as aussi plusieurs classes dans ton classpath, venant de bibliothèques tierces dont tu te sers ou récupère en dépendance transitive, qui sont sérialisables, donc désérialisables, et qui permettent de décrire un comportement complexe et exécutable, comportement qui bien sûr va être exécuté à un moment ou à un autre, soit parce que cette classe définit qu'à la désérialisation elle exécute le comportement qu'elle représente, soit parce qu'une bibliothèque, quelque part, va reconnaître cette classe et se dire que si on a récupéré un comportement, c'est bien sûr pour l'exécuter. Les erreurs de sécurité ne manquent pas.

Bref un petit malin n'a plus qu'à envoyer une requête à ton site web, avec dedans un cookie qui contient la sérialisation d'un objet qui représente le fait d'effacer la base de données, et ta base de données est effacée. Merci la sérialisation !

En général, les systèmes de sérialisation/désérialisation qui n'ont pas ce problème, c'est ceux qui disent à la désérialisation, quelle classe on veut désérialiser. Il n'y a donc pas de classe qui représente un comportement qui tienne, ou s'il y en a une, c'est seulement de manière attendue et encadrée par le développeur qui la demande.

Citation:

---

Envoyé par AoCannaille

J'ai l'impression de vivre dans un autre monde... Sérialiser en mode texte? sérieusement? à quoi ça peut servir un truc aussi gourmand?
Je ne suis pas dans le web, donc je ne sais pas l'utilité que vous avez de la sérialisation, mais personnellement on l'utilise soit entre applications sur la même machine, soit sur le réseau en radio.
En local, sur les petits objets pourquoi pas, mais dès que ça part sur du réseau, faire passer du texte est horriblement inefficient...

On utilise surtout google protocol buffer pour ça. ça marche plutôt bien.

Le binaire il n'y a que ça d'efficace!

---

Non mais cherche pas les dev web ... les mecs te serialize des images en texte genre c'est normal

Je rigole... MAIS java est une horreur en soi :arf:

Citation:

---

Envoyé par vivid

Je rigole... MAIS java est une horreur en soi :arf:

---

On pourrais appliquer ta remarque à de nombreux langages informatiques existants... Et dont pas des moindres....
Quand à la sérialisation, y'a pas qu'en JAVA que c'est utilisé... Doit on la supprimer dans tous les langages ?

Ou l'améliorer tout bêtement, ce serait pas mieux ?

Bonjour,

Les problèmes de sécurité lors de la sérialisation proviennent de la librairie de Apache commons-collections qui en fait "trop" et qui est vulnérable à certains objets sérialisé piégés.
https://foxglovesecurity.com/2015/11...-vulnerability

La sérialisation/désérialisation est une façon en java de passer les paramètres en RMI comme le protocole encore plus ancien Remote Procedure Call (RPC) et aussi CORBA.

Le protocole RMI ou EJB permet de passer efficacement les valeurs des attributs de la classe en binaire.
La taille des échanges est faible à comparer à XML ou JSON.

Le principal problème est que :
- c'est du Java vers du Java et pas pour d'autre langage
- c'est assez difficile à débugger
- difficile à simuler pour des tests de performances
- difficile à répartir la charge entre plusieurs instances

Il faut aussi considérer les objets sérialisés comme des objets à faible durée de vie (un échange réseau) et pas pour du stockage.

Je pense que le protocole RMI/EJB est à utiliser entre 2 applications locales et de confiance.
Il n'est pas adapté pour les échanges entre des applications distantes et ne doit pas être utiliser si on passe par Internet.

Effectivement, RMI est plutôt du passé (comme CORBA).

Un protocole binaire qui peut remplacer efficacement RMI et qui est plus ouvert est le gRPC de Google
https://grpc.io/

Sinon, on utilise aussi JSON pour les échanges entre applications surtout avec des langages différents.

Cordialement
Vincent DAB.

Si j'ai bien compris la dernière conférence de R. Forax, la sérialisation Java empêche les champs 'final' d'être de vraie constante.

Citation:

---

Envoyé par AoCannaille

J'ai l'impression de vivre dans un autre monde... Sérialiser en mode texte? sérieusement? à quoi ça peut servir un truc aussi gourmand?
Je ne suis pas dans le web, donc je ne sais pas l'utilité que vous avez de la sérialisation, mais personnellement on l'utilise soit entre applications sur la même machine, soit sur le réseau en radio.
En local, sur les petits objets pourquoi pas, mais dès que ça part sur du réseau, faire passer du texte est horriblement inefficient...

On utilise surtout google protocol buffer pour ça. ça marche plutôt bien.

Le binaire il n'y a que ça d'efficace!

---

Et moi de vivre dans un tout autre monde que toi, parce que je n'imaginerais pas sérialiser autrement qu'en json ou en xml, sans doute parce que j'ai trop l'habitude de REST et de SOAP. Il y a sans doute une histoire de "golden hammer" dans nos perceptions respectives.

Ce que tu dis est intéressant en tout cas et j'irai découvrir Protocol Buffers dès que j'aurais un peu de temps libre. Je me demandais justement à la lecture de l'article qui sérialise réellement en binaire. Dans quels contextes tu utilises cela ? Comment tu fais pour débuguer ensuite ? Le gain de performance parait indiscutable, mais quelle est la lourdeur du développement ? Comment tu fais pour communiquer tes DTO sérialisés en binaire à d'autres langages ?

Citation:

---

Envoyé par Grogro

Ce que tu dis est intéressant. Je me demandais justement à la lecture de l'article qui sérialise réellement en binaire. Dans quels contextes tu utilises cela ? Comment tu fais pour débuguer ensuite ? Le gain de performance parait indiscutable, mais quelle est la lourdeur du développement ? Comment tu fais pour communiquer tes DTO sérialisés en binaire à d'autres langages ?

---

Comme je disais dans mon post, je l'utilise pour faire de la communication interlogiciels (et donc inter-languages) sur des sockets, soit dans la même machine, soit à distance.

En s'appuyant sur google protocol buffer, nous n'avons jamais eu besoin de débugguer du binaire, le débugger du langage recepteur (ou emmeteur) permet de voir ce qu'il se passe.
Comment cela fonctionne? De manière assez classique (et selon moi indispensable), pour discuter entre logiciels, on commence par décrire une interface dans un langage propre à protobuf mais très clair et plutôt souple.

Ensuite, on compile cette interface qui va générer des classes objets et utilitaires dans chacun des langages utilisés. On précède chaque objet qu'on envoie d'un message qui annonce le type de l'objet qui suit, ensuite il n'y a plus qu'a appeler le bon constructeur avec les octets reçus. La suite est de la POO classique.

La seule vrai contrainte est donc qu'on est toujours dépendant de la version de l'interface et cela nécessite régulièrement de compiler l'interface et les clients/serveurs.
Le système est assez souple pour résister à certains changements d'interfaces, comme l'ajout de champs dans les objets ou leur suppression. ça devient plus complexe quand un champs garde le même nom mais change radicalement de type.

De toute façon, selon moi, une interface propre devrait toujours avoir cette rigueur, et se baser sur un fichier texte et devoir en faire de la rétro-ingénierie pour l'utiliser est , selon moi encore, très pierre-à-feux et pas très industriel comme process.

Mais je comprend bien que si les performances ne sont pas un problème, ou si on est pas maitre de l'interface et que de l'autre coté du tuyau il y a des changements fréquents non documentés, un format autoporteur est nécessaire. Je pense juste que c'est crado ^^

Edit : dans tout ça, je me permet de préciser qu'effectivement je n'ai jamais utilisé la sérialisation java incluse de base... et que je ne l'ai jamais vue utilisée non plus.

Citation:

---

Envoyé par AoCannaille

Mais je comprend bien que si les performances ne sont pas un problème, ou si on est pas maitre de l'interface et que de l'autre coté du tuyau il y a des changements fréquents non documentés, un format autoporteur est nécessaire. Je pense juste que c'est crado ^^

---

Oui mais voilà, la vraie vie c'est souvent crado et on a pas toujours la totale maitrise de toutes les couches du SI. Et plus on creuse le merdier, plus on se rend compte à quel point c'est sale. Mais ça fonctionne (la plupart du temps). ^^

Merci pour tes précisions techniques en tout cas. Tel que tu le décris, Protocol Buffers n'a pas l'air plus lourd à déployer que du SOAP.

Citation:

---

Envoyé par Grogro

Oui mais voilà, la vraie vie c'est souvent crado et on a pas toujours la totale maitrise de toutes les couches du SI. Et plus on creuse le merdier, plus on se rend compte à quel point c'est sale. Mais ça fonctionne (la plupart du temps). ^^

---

C'est peut être l'avantage de taffer dans le militaire 8-)

Citation:

---

Merci pour tes précisions techniques en tout cas. Tel que tu le décris, Protocol Buffers n'a pas l'air plus lourd à déployer que du SOAP.

---

De rien :-)
Les seules conditions dans lesquelles j'ai utilisé du SOAP et du REST était pour des web services sous JBOSS (j'ai l'impression que c'était il y a une éternité). Effectivement, Eclipse bien configuré (ce qui n'était pas donné non plus), facilitait pas mal le boulot. Avec protobuf, le seul truc "fastidieux", c'est le méga switch case à l'entrée et a la sortie du tuyaux... rien d'insurmontable non plus.

je suis assez surpris:
1) ah bon il y a des applications qui font de la Serialization sur du réseau non-local/privé?
2) quand bien même, si on a peur d'intrusions, qu'est ce qui empêche d'authentifier des MarshalledObjects (ou de passer par un canal authentifié)?
En partant à la retraite j'ai quitté un projet java (gros matériel scientifique) qui doit être opérationnel en 2020 sur une durée de 20 ans .(avec une multitude d'ordis qui s'échangent en local, et à toute vitesse, des tonnes d'objets).. tout à coup j'ai des sueurs froides ....

Citation:

---

Envoyé par professeur shadoko

1) ah bon il y a des applications qui font de la Serialization sur du réseau non-local/privé?

---

Ben oui... Pour une appli web, supposons que tu aies besoin de conserver une donnée avec une certaine permanence côté client. Ben tu la sérialises dans un cookie, problème réglé. Qu'est-ce qui pousserait à penser à faire autrement ?

Citation:

---

Envoyé par professeur shadoko

2) quand bien même, si on a peur d'intrusions, qu'est ce qui empêche d'authentifier des MarshalledObjects (ou de passer par un canal authentifié)?

---

Ben rien ne t'empêche de le faire, d'ailleurs je dirais que c'est indispensable si tu décides d'avoir un mécanisme de ce genre (je vois pas, par contre, ce que ça peut changer si c'est un canal authentifié. Tu penses qu'un pirate ne songeras pas à prendre un compte client chez toi pour te pirater ?)

Le problème c'est que les objets marshallés, c'est pas toi qui t'en occupes, c'est les bibliothèques dont tu te sers. Et elles étaient à des kilomètres de s'imaginer qu'on pourrait s'en servir dans un contexte où il faudrait vérifier qui demander à désérialiser quoi. Du coup, ben, elles ne le font pas.

Les failles de ce genre que l'on connaît, ont bien entendu été corrigées dans des versions plus récentes maintenant que rétrospectivement ça a l'air évident pour tout le monde une fois qu'on le sait. Mais, quid de ceux qui ne mettent pas à jour, et surtout, ça montre que les failles de ce genre peuvent arriver comme un rien. Il y a aussi toutes celles qu'on ne connaît pas.

Citation:

---

Envoyé par professeur shadoko

En partant à la retraite j'ai quitté un projet java (gros matériel scientifique) qui doit être opérationnel en 2020 sur une durée de 20 ans .(avec une multitude d'ordis qui s'échangent en local, et à toute vitesse, des tonnes d'objets).. tout à coup j'ai des sueurs froides ....

---

Sans maintenance, en Java ou ailleurs, ce genre de choses n'existent plus... Pour les applications non connectées, on avait pas à s'inquiéter de faille de sécurité, et le matériel très robuste et durable faisait qu'on n'était pas tenu de mettre régulièrement à jour. C'est fini tout ça. À la rigueur, la partie durable peut toujours se réinventer... Mais l'aspect faille de sécurité potentielle, non. Pas à un époque où on sait trouver des failles comme Spectre ou Meltdown.

Bonjour tout le monde,
J'ai lu tous vos différents posts avec beaucoup d’intérêt.
Tout d'abord, je suis novice dans le domaine de la sérialisation. Je travaille actuellement sur un projet en swing et nous sérialisions au début les objets via JAXB pour les avoir en XML. Le problème était que certains utilisateurs s’amusaient à changer les données stockées en XML car totalement lisibles via un logiciel tel que notepad++. Puis ils nous appelaient pour se plaindre que le fichier n'était plus accepté par l'application (rien d’anormal surtout s'ils suppriment une partie d'une balise...). Nous avons réfléchi à plusieurs solutions et au lieu de chiffrer les objets sérialisés en XML, nous avons choisi de les sérialiser en octet.
Sachant que pour désérialiser les objets nous avons besoin de la classe de celui-ci, je ne vois pas comment il pourrait y avoir un danger ?
Après mon cas est différent mon projet n'est pas ouvert à internet donc les risques de piratage sont plus que minimes.
Je ne vois pas en quoi cette pratique est néfaste surtout que niveau lourdeur du code il n'y a pas photo ça reste extrêmement simple par rapport à l'XML ou JSON ou autres (à mon avis). À part pour le débogage, je ne vois pas vraiment de côté négatif (dans mon cas en tout cas).
Après je n'ai pas le recul de la plupart d'entre vous. Je suis donc preneur de tout conseil ou remarque^^....

Bonjour Badshade23,

Si ta sérialisation n'est utilise que pour la persistance, le XML était effectivement une solution viable, son seul problème étant que ce n'est pas idiot-proof :mouarf:
Tu peux bricoler ton fichier pour limiter la part d'idiot, le nommer *.data par exemple, ou *.<nom de ton logiciel>, tu auras déjà 80% des idiots qui, s'il ne suffit pas de double cliquer, n'y toucheront plus. Peut-être également le rendre fichier caché.

Tu peux sinon effectivement sérialiser en binaire. Avec google protocol buffer, au lieux d'envoyer les octets dans une socket, tu le fait dans un fichier et le tour est joué.

Tu peux aussi te renseigner sur sqlite. C'est une base de donnée relationnelle sous forme de fichier (donc contenu binaire) et qui avec les outils adapté est "débogable". Le commun des mortel ne pouvant pas y toucher. C'est utilisé par exemple par firefox pour enregistrer préférences et personnalisations.

Par contre, en fonction de ton architecture actuelle, ça demandera sans doute plus d'effort que la sérialisation binaire.

C'est sur pour "l'idiot-proof" :mouarf: :mouarf:.
J'ai déjà changé l'extension mais bon ça ne change malheureusement rien .
Je connaissais pas google protocol buffer j'ai vu qu'il était mentionné dans les commentaires précédents.
Quant à SqlLite j'en ai déjà entendu parler mais plus pour Android.
Mais sa ne change pas le fait que je ne comprends pas où serait la faille de sécurité sachant que pour désérialiser les objets nous avons besoin de la classe de celui-ci?