Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Consultant
    Inscrit en
    juillet 2013
    Messages
    2 091
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 091
    Points : 67 434
    Points
    67 434
    Billets dans le blog
    2

    Par défaut 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 ».


    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.

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

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

    Et vous ?

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

    Voir aussi :

    JavaFX SDK Early Access disponible pour le JDK 11 et un miroir GitHub du projet OpenJFX mis en place
    Java SE 8 : les mises à jour publiques seront disponibles jusqu'à décembre 2020 minimum pour les fonctionnalités non commerciales
    Java : proposition en open source pour Mission Control, l'outil de profilage et d'analyse des performances d'Oracle
    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
    Tutoriel : La sérialisation binaire en Java
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre confirmé Avatar de emixam16
    Homme Profil pro
    Doctorant en sécurité
    Inscrit en
    juin 2013
    Messages
    143
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Aube (Champagne Ardenne)

    Informations professionnelles :
    Activité : Doctorant en sécurité

    Informations forums :
    Inscription : juin 2013
    Messages : 143
    Points : 561
    Points
    561

    Par défaut

    Ç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... [/TROLL]

  3. #3
    Membre éprouvé Avatar de supergeoffrey
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2010
    Messages
    611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2010
    Messages : 611
    Points : 1 266
    Points
    1 266

    Par défaut

    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).
    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.
    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.
    Pensez à marquer vos tickets comme résolus.
    Pensez aussi aux pour les réponses pertinantes

    Quand une discution est résolue depuis un moment pour revenir dessus, il est mieux d'en crée une nouvelle avec un lien vers l'autre car :
    • Elle sera en haut du forum, elle sera donc plus visible
    • Une discussion résolue, on ne passe pas dessus pour aider, on passe dessus si on a le même problème
    • Tu demandes surement à tes clients de faire le même

  4. #4
    Membre éprouvé
    Profil pro
    Inscrit en
    juin 2006
    Messages
    1 285
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 1 285
    Points : 1 164
    Points
    1 164

    Par défaut

    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

  5. #5
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 233
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 233
    Points : 3 175
    Points
    3 175
    Billets dans le blog
    12

    Par défaut

    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+
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  6. #6
    Membre émérite
    Inscrit en
    juin 2009
    Messages
    809
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 809
    Points : 2 397
    Points
    2 397

    Par défaut

    Citation Envoyé par supergeoffrey Voir le message
    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!

  7. #7
    MikeRowSoft
    Invité(e)

    Par défaut

    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.
    ASCII, ANSI, etc... ?

    Ç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".

    • 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...
    Injection de codes malicieux ?

    Citation Envoyé par AoCannaille Voir le message
    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...
    Dernière modification par MikeRowSoft ; 29/05/2018 à 12h44.

  8. #8
    Modérateur

    Profil pro
    Inscrit en
    septembre 2004
    Messages
    11 576
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 11 576
    Points : 19 650
    Points
    19 650

    Par défaut

    Citation Envoyé par emixam16 Voir le message
    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 Voir le message
    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 Voir le message
    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.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  9. #9
    Membre éprouvé Avatar de atha2
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2007
    Messages
    664
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : janvier 2007
    Messages : 664
    Points : 1 149
    Points
    1 149

    Par défaut

    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.

  10. #10
    Membre expérimenté
    Avatar de kedare
    Homme Profil pro
    Senior System Reliability Engineer
    Inscrit en
    juillet 2005
    Messages
    1 525
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Espagne

    Informations professionnelles :
    Activité : Senior System Reliability Engineer

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 525
    Points : 1 685
    Points
    1 685

    Par défaut

    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


    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.

  11. #11
    Membre du Club Avatar de _champy_
    Homme Profil pro
    Chef de projet progiciel patrimoine route/tram/aeroport
    Inscrit en
    novembre 2017
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projet progiciel patrimoine route/tram/aeroport
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2017
    Messages : 25
    Points : 68
    Points
    68

    Par défaut

    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"

  12. #12
    Membre du Club Avatar de _champy_
    Homme Profil pro
    Chef de projet progiciel patrimoine route/tram/aeroport
    Inscrit en
    novembre 2017
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projet progiciel patrimoine route/tram/aeroport
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2017
    Messages : 25
    Points : 68
    Points
    68

    Par défaut

    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.

  13. #13
    Modérateur

    Profil pro
    Inscrit en
    septembre 2004
    Messages
    11 576
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 11 576
    Points : 19 650
    Points
    19 650

    Par défaut

    Citation Envoyé par _champy_ Voir le message
    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.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  14. #14
    Membre averti
    Inscrit en
    juin 2010
    Messages
    507
    Détails du profil
    Informations forums :
    Inscription : juin 2010
    Messages : 507
    Points : 445
    Points
    445

    Par défaut

    Citation Envoyé par AoCannaille Voir le message
    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

  15. #15
    Futur Membre du Club Avatar de vivid
    Profil pro
    Inscrit en
    février 2006
    Messages
    67
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2006
    Messages : 67
    Points : 8
    Points
    8

    Par défaut

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

  16. #16
    Membre expérimenté
    Homme Profil pro
    Développeur tout-terrain
    Inscrit en
    juin 2004
    Messages
    330
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur tout-terrain
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juin 2004
    Messages : 330
    Points : 1 475
    Points
    1 475

    Par défaut

    Citation Envoyé par vivid Voir le message
    Je rigole... MAIS java est une horreur en soi
    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 ?

  17. #17
    Membre à l'essai
    Inscrit en
    juillet 2007
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : juillet 2007
    Messages : 8
    Points : 16
    Points
    16

    Par défaut RMI = RPC en Java

    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.

  18. #18
    Membre habitué
    Profil pro
    Inscrit en
    février 2007
    Messages
    190
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2007
    Messages : 190
    Points : 153
    Points
    153

    Par défaut

    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.

  19. #19
    Membre extrêmement actif
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2015
    Messages
    1 105
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2015
    Messages : 1 105
    Points : 2 632
    Points
    2 632

    Par défaut

    Citation Envoyé par AoCannaille Voir le message
    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 ?
    "If the revolution ain't gon' be televised
    Then fuck, I'll probably miss it" - Aesop Rock

  20. #20
    Membre émérite
    Inscrit en
    juin 2009
    Messages
    809
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 809
    Points : 2 397
    Points
    2 397

    Par défaut

    Citation Envoyé par Grogro Voir le message
    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.

Discussions similaires

  1. Réponses: 9
    Dernier message: 21/07/2013, 08h21
  2. Récupérer le code d'une erreur Oracle
    Par etoileDesNeiges dans le forum SQL
    Réponses: 6
    Dernier message: 04/10/2007, 11h22
  3. Signification d'une erreur Oracle
    Par L_latifa dans le forum Oracle
    Réponses: 6
    Dernier message: 05/04/2006, 14h18
  4. Activer une servlet Java à partir d'outils Oracle
    Par valauga dans le forum Oracle
    Réponses: 1
    Dernier message: 09/03/2006, 17h32
  5. [C#] Erreur Oracle avec une requete paramétrée
    Par gael.mases dans le forum C#
    Réponses: 1
    Dernier message: 02/12/2005, 11h39

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo