Journal Proteger ses .class

Posté par  .
Étiquettes : aucune
0
11
avr.
2004
Cher journal,
Jusqu'a présent je ne mettais jamais posé la question de comment empecher l'acces aux fichiers .class de mes applets java, car de toute facon je m'en fichais pas mal.

Mais supposons que mon site heberge une applet qui doit rester accessible via la page web, mais pas par son lien direct, afin d'empecher les eventuels download et décompilage (oui car si c'est un module d'administration ce serait embetant que la source soit visible...)

Quelqu'un peut il m'eclairer ??
  • # Re: Proteger ses .class

    Posté par  (site Web personnel) . Évalué à 3.

    le navigateur, il ne fait que suivre le lien direct qui est sur la page web pour télécharger l'applet, donc la réponse est clairement et définitivement non.
    • [^] # Re: Proteger ses .class

      Posté par  . Évalué à -2.

      C'est bien ce qu'il me semblait...

      Mais vu la facilité déconcertant avec laquelle on peut décompiler un binaire java, l'espoir de voir un site sécurisé via une applet java est donc nul ?
      • [^] # Re: Proteger ses .class

        Posté par  (site Web personnel) . Évalué à 4.

        Et un programme securisé en opensource ca n'existe pas ?
        Il ne faut pas penser securité par "cacher les infos", mais par "securiser les infos".
        • [^] # Re: Proteger ses .class

          Posté par  . Évalué à -1.

          Bah dans l'immédiat je visualise malgrès tout très mal dans le cas de mon applet.

          Si mon applet dispose d'un code genre

          if (password.getValue.equals("blabla"))
          //mettre a jour la base, avec les mot de passes de connexion en dur dans le code
          else
          //vous netes pas autorisé a modifier la base


          Bah le décompilage du .class rend l'acces de ma base totalement libre, les chaines de connexions etant dedans.
          L'acces aux fichiers par un applet est très restreint, une solution possible magrès tout a base de fichier locaux contenant les mots de passes est elle envisageable ?


          Comment y remedier ?
          • [^] # Re: Proteger ses .class

            Posté par  (site Web personnel) . Évalué à 2.

            acceder a tes mots de passes (cryptés, hashé, ce que tu veux) via JDBC, ou tout simlpement via un fichier posé quelquepart en http.
            C'est crypté, donc ca va etre tres dur de retrouver le pass originel. (Tu est root de ta machine, mais meme en ayant acces au /etc/shadow ou passwd, tu mettras un temps ENORME avant de retrouver le moindre pass)
            • [^] # Re: Proteger ses .class

              Posté par  . Évalué à 0.

              L'algorithme de cryptage etant dès lors visible, seul la solution du hashage est envisageable non ? Un hashage md5 eviterait la création d'un algorithme de decryptage basé sur celui de cryptage
              • [^] # Re: Proteger ses .class

                Posté par  . Évalué à 2.

                Complètement. Les mots de passe stockés en MD5 ou SHA1, c'est super courant, et ça marche plutôt pas mal.
            • [^] # Re: Proteger ses .class

              Posté par  . Évalué à 1.

              oui enfin ça dépend... beaucoup de gens ont des mots de passe bidon. Lorsque j'était en IUT il y a quelques années, c'était le grand jeux de cracker les mots de passe (ils n'utilisaient pas shadow à l'époque). Beaucoup de mot de passe ne tenait pas longtemps.
              Un jour un copain est venu me dire de changer de mot de passe alors que je le trouvais super bien à l'époque.
  • # Re: Proteger ses .class

    Posté par  . Évalué à 1.

    Tu ne peux pas empêcher qu'on récupère tes .class, en revanche je crois que tu peux utiliser un truc appelé obfuscateur de code qui rendra ton .java illisible après décompilation. Le .class fonctionnera quant à lui de façon normale.

    A vérifier.
    • [^] # Re: Proteger ses .class

      Posté par  (site Web personnel) . Évalué à 1.

      Il me semble que les obfuscateurs de code rende illisible le "code source", le bye-code décompilé, quant à lui, est toujours "pas très lisible"...

      L'utilisation de cryptage me semble la meilleure solution pour les données sensibles.

      Axel
  • # Re: Proteger ses .class

    Posté par  (site Web personnel) . Évalué à 1.

    Et tu ne peux pas modulariser ton code en 2 parties style client/serveur avec la partie serveur restant sur ton serveur avec les infos confidentielles et la partie cliente communiquant avec le serveur ?
    • [^] # Re: Proteger ses .class

      Posté par  . Évalué à -1.

      Oui c'est une idée.
      Mais bon comme j'ai dit au début de ce journal, je n'ai pas de code, c'etait juste une idée qui me passait par la tete, a savoir comment on sécurise une applet java
      • [^] # Re: Proteger ses .class

        Posté par  . Évalué à 2.

        Par definition, un programme (en Java ou autre), s'executant du coté client (c'est à dire sur une machine qu'on ne maitrise pas) ne peut pas etre sécurusé.....
        • [^] # Re: Proteger ses .class

          Posté par  . Évalué à 4.

          Tsss faut pas dire ça, ça fait au mois 5ans que microsoft essaye de le faire croire à ses clients :D
  • # Re: Proteger ses .class

    Posté par  . Évalué à 2.

    Mais supposons que mon site heberge une applet qui doit rester accessible via la page web, mais pas par son lien direct, afin d'empecher les eventuels download et décompilage (oui car si c'est un module d'administration ce serait embetant que la source soit visible...)

    Ben si ton hébergeur le permet (cela consomme beaucoup de ressources), tu peux peut-être envisager d'écrire une servlet plutôt qu'une applet ...

    Sinon, effectivement, ton navigateur suit un lien exactement de la même façon que l'utilisateur le fait lorsqu'il clique sur un lien. D'ailleurs, le serveur web n'aura aucun moyen de faire la différence. Pour aller même un peu plus loin, il n'y a aucune raison valable pour que l'utilisateur ne puisse pas voir ce qui fonctionne sur sa propre machine. Si tu en arrives à buter sur ce genre de problème, il est problable que ton projet entier souffre d'une erreur de conception ...

    D'ailleurs, moi personnellement, les sites dynamiques, je les développe toujours à l'ancienne mode: CGI, en langage C, voire C++ à la limite. Mon application a l'avantage de tenir entièrement dans un seul tout petit fichier exécutable, et très rapide de surcroît (appréciable dans ce domaine où un programme qui s'exécute doit être éphémère). Bon c'est difficile à mettre en place chez un hébergeur, mais sur un Apache perso, en en milieu professionnel, cela remplit parfaitement ses fonctions.
    • [^] # Re: Proteger ses .class

      Posté par  . Évalué à 1.

      Mouais ... servlet et applet, rien à voir :)
      • [^] # Re: Proteger ses .class

        Posté par  . Évalué à 3.

        Le point commun, c'est que ce sont toutes les deux des applications Java fonctionnant sur le web, la première du coté serveur, la seconde du coté client.

        Et justement, sauf à vouloir faire du closed source, je ne vois pas pourquoi une routine qui doit rester confidentielle devrait s'exécuter coté client. C'est plutôt au serveur de calculer le résultat, puis de le livrer tout fait avec l'applet qui l'exploite au client.
  • # Re: Proteger ses .class

    Posté par  (site Web personnel) . Évalué à -1.

    wééé les hash md5 wééé les requetes HTTP pour aller prendre les infos sur le web... mais ca ne résout rien du tout, tant que la personne peut décompiler le code et sniffer les paquets qui sortent à l'aide d'un simple tcpdump pour récuperer les infos (oui meme si elles sont cryptées, de toute facon ya le code java décompilé, tout bien comme il faut avec Jad ( http://kpdus.tripod.com/jad.html(...) ) pour le décrypter)

    Bon alors le monde est-il aussi mauvais ?

    NON !

    comme suggéré plut haut, les obfuscateurs de code débarquent à la rescousse

    http://www.acm.org/crossroads/xrds4-3/codeob.html(...)

    apres le choix de l'obfuscateur est délicat, que est le mieux ? où trouver des "benchmark" d'obfuscateurs ? existe-t-il un dé-obfuscateur pour tel ou tel obfuscateur ? est-ce vraiment impossible de comprendre qqch avec le passage de tel obfuscateur et après décompilation avec JaD ?

    bref, après, c'est quand même un peu de boulot :)

    bonne chance
    • [^] # Re: Proteger ses .class

      Posté par  . Évalué à 1.

      The Jad main features:

      * Enhanced readability of the generated source code.
      * Ability to comment Java source code with JVM bytecodes. Useful for verification and educational purposes.
      * Full support for inner and anonymous classes.
      * Fast decompilation and simple setup.
      * Automatic conversion of identifiers garbled by Java obfuscators into valid ones.
      * Free for non-commercial use. If you would like to use Jad for commercial purposes, please contact me for conditions.
      • [^] # Re: Proteger ses .class

        Posté par  (site Web personnel) . Évalué à 1.

        oui c'est bien pour cela qu'il faut les tester les obfuscateurs, un obfuscateurs qui se limiterais à ca (ie Automatic conversion of identifiers garbled by Java obfuscators) n'est pas un bon candidat pour protéger son code...

        c'est pas parce que tu trouves le mot "obfuscators" dans les caractéristiques de Jad que tout de suites les obfuscateurs, c'est mort. Comme d'hab c'est plus facile de faire chier (écrire un obfuscateur) qui de trouver les parades (ce que fait Jad sur un léger détail)

        enfin, bref
  • # Histoires de loi de la jungle. Tarzan viens me sauver !!!

    Posté par  . Évalué à 2.

    Topic off cela me rapelle une discussion suréaliste avec 2 développeurs flash/Director.
    Alors on parle de décompilation de swg, de fla ...
    Puis de director leur joujou favorie, puis de lingo.
    Là, ils me sorte que cela serait bien de laissé tombé le actionScript pour tout faire en lingo ...
    Et puis je leur demande s'ils ont essayer Java.
    2 mots sur Java.
    Et là surprise, ils me disent Java est "OpenSource" car tu peux décompilé tes prog en en ByteCode.
    Je leur répond que un java n'est pas construit en source ouverte, mais c'est vrai qu'il y a bouquin très complet qui explique ce que Java est, et d'autres pour expliquer le ByteCode.
    Et que décompiler des applications ne peut etre fait que pour besoin d'interopérabilité surtout si l'auteur est pas en accord avec cette acte.
    Et là, ils m'invoquent la loi de la jungle "on peut donc on fait".

    Et là, j'ai pensé à ma bonne vieille GPL.
    Quel impact peut avoir la GPL avec ce genre d'utilisateurs de "base".

    Disons aussi que j'ai été mis au courant chez un grand opérateur historique de violation de copyright. En gros, utilisation de menu dynamique d'un chinois en javascript qui le vendait pour des solutions commercial. Je dois dire que j'étais assez mal a l'aise et que j'ai protesté dans le vide.

    C'était toujours la même hatitude "on peut donc on fait".

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.