Nous avons plusieurs applications Javae 6 (fichiers .war) que nous devons protéger contre l'ingénierie inverse, mais il ne semble pas y avoir de nombreuses options disponibles.
J'aime l'idée d'un fichier crypté de .jar (SJAR) utilisé dans le JARCRYPT / JINSTALLER Produits, mais il n'est pas clair que Jarcrypt / Jinstaller fonctionnera dans une application Javaee 6. serveur comme Glassfish3.1. Les fichiers SJAR cryptés doivent être déchiffrés par une bibliothèque natale à l'aide d'un chargeur de classe personnalisé, donc apparemment, je devrais ajouter un chargeur de classe personnalisé à Glassfish.
Quelqu'un a-t-il utilisé les technologies Jinstaller / Jarcrypt? Fonctionnent-ils dans un serveur d'applications?
J'ai aussi examiné l'obscurcissement, mais pour les applications Javaee, il y a beaucoup de problèmes. Je devrais laisser tous les services Web et les recherches JNDI. Utilisation de choses comme A.B.C.MYCLASS.Class (c'est-à-dire pour créer des enregistreurs log4j) est problématique. La lecture des fichiers journaux devient difficile. Et pour tous ces problèmes, l'obfuscation ne fait qu'à partir de rien pour sécuriser notre code.
J'ai essayé proguard, mais apparemment, il ne peut pas gérer le Javaee 6 bibliothèques .
Y a-t-il d'autres alternatives ou sont-ils à propos de toutes les options que j'ai?
Merci.
4 Réponses :
Expédiez-vous ces applications à des tiers qui l'exécuteront sur leur infrastructure? Ensuite, le cryptage ne vous aidera pas du tout, car le JVM ne peut pas exécuter de bytecode crypté, et Il est trivial à Récupérez les fichiers de classe chargée d'une application en cours d'exécution .
Jetez un coup d'œil à Guardit pour Java - À ce jour, je n'ai eu aucune expérience avec elle, mais au moins le fournisseur affirme qu'il est spécifiquement conçu pour protéger les applications Web Java.
Si vos applications fonctionnent sur Tomcat, vous auriez pu les avoir compilées au code natif. Ou ont-ils besoin d'un serveur d'application Java EE complet?
La prévention est en fait impossible. Le mieux que vous puissiez espérer, c'est d'élever légèrement la barrière qui en résultera en grande partie, c'est une miss placée se sentir bien facteur Sécurité à travers Obscurity est Aucune sécurité du tout . Les produits qui prétendent faire cela sont en train de colporter huile de serpent de silicium
J'ai travaillé sur la protection du logiciel depuis deux ans et j'ai évalué la plupart des solutions européennes sur le marché (désolé, nous évitons les solutions américaines ...).
Il y a quatre techniques que nous avons considérées comme des solutions de protection: - Obfuscation - Chiffrement - Compilation au code natif - Transcodage
Vous connaissez probablement la plupart de ces techniques à l'exception du transcodage.
Obfuscation nécessite beaucoup de travail pour ce qui est, à la fin, une mauvaise protection. Mais vous pouvez combiner Obfuscation et avec toutes les autres techniques.
cryptage est assez facile à casser (il n'y a pas de solution pour stocker la clé dans une zone de sécurité; même avec un dongle, il est facile de récupérer). En outre, il existe un travail pour voler des classes déchiffrées de la mémoire (ou, plus directement, la clé de cryptage).
La plupart des développeurs Java pensent que la compilation du code natif offre une bonne protection ... mais cela ne fournit pas du tout une protection; Depuis plus de 20 ans, il a été possible de renverser le code natif et il existe des ingénieurs inversés très qualifiés pour le faire. Il existe également de bons compilateurs inversés au langage C pour vous aider ...
Enfin, il y a transcodage (dont il y a très peu d'informations sur Internet). C'est la seule protection efficace contre les ingénieurs inversés qualifiés. C'est une douleur à la pause car elle nécessite des années de travail. Il n'est pas impossible mais exige un très long temps .. En outre, chaque fois qu'un nouveau patch est libéré, vous devez redémarrer à nouveau l'ingénierie inverse car à chaque version, le code est totalement différent. Y a-t-il un inconvénient? Oui, performance. Mais il peut être combiné à toutes les autres techniques et il n'y a pas de limitations de déploiement (serveur d'applications, génération de classe dynamique, etc.) ou des limitations Java (réflexion, etc.).
Il n'y a pas de balle d'argent. Chaque solution peut être utilisée en fonction de votre cible. Protéger contre un gouvernement ou contre les écritures Kiddies n'est pas la même chose ... Choisissez une solution par rapport aux avantages et aux inconvénients, et plus important encore, des limitations relatives (telles que Jarcryp et Obfuscation sur la demande Web).
Pour répondre à la question sur JARCRYP (et d'autres solutions effectuant un cryptage), il est possible de demander à CIFECIO (fournissant Jinstaller / Jarcryp) pour vous donner un chargeur de classe de classe d'applications que vous utiliser.
Transcodage fonctionne avec tous les serveurs d'applications.
Obfuscation de fichier de guerre à l'aide de Proguard vous aidera à chiffrer votre dossier de guerre dans une large mesure. Pour plus de détails, visitez le lien http: //bratonfire.blogspot .in / 2012/01 / war-objet-obfuscation-with-proguard.html
Bien que ce lien puisse répondre à la question, il est préférable d'inclure les parties essentielles de la réponse ici et de fournir le lien pour référence. Les réponses uniquement uniquement peuvent devenir invalides si la page liée change.
Avez-vous reçu la réponse de votre question? ce sera gr8 si vous pouvez le poster ici