Journal Proteger ses .class

Posté par cho7 le 11 avril 2004 à 22:40.

Étiquettes : aucune

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 Jérôme (site web personnel) le 11 avril 2004 à 22:44. É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 cho7 le 11 avril 2004 à 22:50. É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 Jylam / jylam.lnxsce (site web personnel) le 11 avril 2004 à 22:57. É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 cho7 le 11 avril 2004 à 23:05. É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 Jylam / jylam.lnxsce (site web personnel) le 11 avril 2004 à 23:10. É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 cho7 le 11 avril 2004 à 23:19. É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 Larry Cow le 12 avril 2004 à 00:49. É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 JMVF le 13 avril 2004 à 11:57. É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 Franck le 11 avril 2004 à 23:00. É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 Axel R. (site web personnel) le 15 avril 2004 à 15:46. É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 heltem (site web personnel) le 12 avril 2004 à 00:43. É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 cho7 le 12 avril 2004 à 01:40. É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 Pascal le 12 avril 2004 à 02:25. É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 Black Fox le 12 avril 2004 à 06:40. É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 Obsidian le 12 avril 2004 à 12:17. É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 Là Yop le 12 avril 2004 à 18:57. Évalué à 1.
  
  Mouais ... servlet et applet, rien à voir :)
  - [^] # Re: Proteger ses .class
    
    Posté par Obsidian le 13 avril 2004 à 12:31. É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 Damien Lespiau (site web personnel) le 12 avril 2004 à 13:52. É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 account le 13 avril 2004 à 10:06. É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 Damien Lespiau (site web personnel) le 14 avril 2004 à 17:39. É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 Samaty Tramo le 12 avril 2004 à 15:39. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.