vaut la peine d'obscurier l'application Web Java? et pourquoi?
8 Réponses :
non. Le code est stocké sur le serveur où des utilisateurs externes (espérons-le) n'ont pas accès à celui-ci. Vous voudrez peut-être obfusquer le JavaScript si vous estimez que cela vaut la peine (minimale) Protection IP.
La meilleure chose à-faire est donc donc assurez-vous que votre sécurité du serveur est à zéro et que vous n'avez pas accès à vos annuaires d'applications (ce qui ne devrait pas arriver de toute façon).
Gouteux utilisateurs externes sont les seuls auxquels nous devons nous inquiéter. rouleau oculaire
Mauvais choix de mots, peut-être :)
J'ajouterais que vous devriez avoir une bonne justification, car l'obfuscation fera de déboguer plus fort.
Peut-être que nous avons besoin d'obfuscation pour protéger des hôtes Web volant notre code ou même toute notre entreprise, non?
Le seul scénario sur lequel vous obtiendrez une application Web Java est si vous avez donné au code à vos clients pour exécuter leurs serveurs. Sinon, c'est juste une perte de temps et une complexité supplémentaire.
Obfuscation est dans le but de rendre plus difficile la peine de décompiler votre code d'octet et d'obtenir un code utile. Pour ce faire, ils doivent avoir accès à vos fichiers de classe, quelque chose qui n'existe que lorsque vous les livrez à vos clients, pas quand ils l'accédent à distance.
Peut-être que nous avons besoin d'obfuscation pour protéger des hôtes Web volant notre code, non?
@ user01, il y a beaucoup de mesures de sécurité mieux et plus importantes que vous devez prendre pour protéger le code hébergé. Si vous êtes inquiet des tiers hosters à ce niveau, vous devriez honnêtement vous héberger.
Merci. Donc, vous voulez dire que je ne devrais pas être tellement sceptique à ce sujet, c'est une question de confiance? Aussi pourriez-vous s'il vous plaît indiquer ou souligner que les autres mesures de sécurité doivent être prises pour la protection?
@ user01, c'est vraiment un sujet pour un autre site Stackexchange (Security.stackexchange.com). Mais dans ce contexte brisant au serveur de production d'exécution pour voler le code source, c'est l'un des scénarios les moins probables - si l'objectif est d'obtenir un code source. Votre référentiel de contrôle source est la vraie cible d'un tel attaquant.
imo, no.
Il y a deux étuis principaux pour l'obfuscation:
Le problème est que l'obfuscation n'entraîne que des tentatives à sens du cœur de l'ingénierie inverse. Une tentative sérieuse réussira toujours. Ce n'est vraiment pas si difficile de décompiler un fichier JAR obscurci et il y a beaucoup d'outils pour le faire.
Pour les cas d'utilisation ci-dessus, de meilleures alternatives à l'obfuscation sont les suivantes:
Bien sur. Vous pouvez décompiler un pot obscurposé. En fait, c'est la même chose qu'un pot "normal". Mais c'est à peine lisible ...
Il est suffisamment lisible pour un pirate informatique déterminé avec un modicum de compétences pour pouvoir comprendre exactement ce qu'il fait et comment cela le fait.
#include
@Antoine: Ce n'est pas Java. Un décompiler Java n'apportera pas gratuitement une couche de merde de préprocesseur Bizarre C à sa sortie.
@Antoine Claval: Vraiment? C'était la chose la plus facile que j'ai jamais vue dans ma vie (sauf pour JVM Bytecode) Pastebin.com/lnp22xt2
Peut-être que nous avons besoin d'obfuscation pour protéger des hôtes Web volant notre code, non?
Vous trouverez peut-être les réponses à Obfuscez-vous votre code Java commercial? < / a> pertinent.
vaut la peine d'obscurcer l'application Web Java?
Cela dépend
et pourquoi?
Si vous licenciez votre application Web à installer sur le site de votre client et que vous ne voulez pas que votre client réutilise votre code en décompilant, il * , alors
c'est. Si vous servez votre application Web et l'installation n'est disponible que de vous, je dirais Ce n'est pas en vaut la peine. Mieux serait d'augmenter votre sécurité nette.
* Voir Stephen C Commentaire
L'obfuscation n'empêchera pas un client de décompiler votre code. Même s'ils ne sont pas entièrement réussi à décompiler pour un code source Java utilisable, ils peuvent probablement comprendre tout secret que vous essayez de vous cacher dans le code.
Peut-être que nous avons besoin d'obfuscation pour protéger des hôtes Web volant notre code, non?
est-ce une bonne idée d'obscurier votre code secondaire serveur ? Je donnerais un oui non qualifié oui.
La réalité est que le Utilisateur final est un seul groupe qui pourrait avoir des plans néfastes. Trop souvent Les employés internes , qu'ils soient Si vous gérez des informations qui nécessitent un mot de passe pour accéder, vous avez un droit pour tirer parti de chaque outil à votre disposition afin de protéger ces informations.
Cela inclut la protection contre les deux externes et interne personnes. Les entreprises perdent toutes les données et la propriété intellectuelle tout de temps en raison de personnes internes avec trop d'accès. Si ces personnes ont intentionnellement volé les informations ou Il suffit de perdre le contrôle de leurs ordinateurs dus au pirate informatique Les attaques sont immatérielles.
Ainsi, encore une fois, oui une étape consiste à obscurcir dans l'espoir de quiconque acquiert que les fichiers binaires ont du mal à déterminer la manière dont votre application fonctionne. Bien sûr, vous devriez aller plus loin en sécurisant les serveurs qu'il vit; et pas seulement Production , mais tout le chemin du retour à Contrôle source .
Vous criminalisez les gens avant de faire des crimes. Bien qu'il soit vrai que beaucoup de tentatives d'intrusion proviennent de la source interne, le code obscurcissant est la mauvaise solution pour donner trop d'accès aux employés. L'obfuscation est plus susceptible d'ennuyer l'administration légitime et de pas empêcher les internes malveillants de causer des ravages. Si vous ne voulez pas que quiconque lise vos fichiers, utilisez le contrôle d'accès du système de fichiers du système d'exploitation et permet aux personnes de s'exécuter mais de ne pas lire l'exécutable.
@Lie Ryan: Obfuscation n'est qu'un outil à la ceinture. Les ACL sont également critiques, mais le fait est qu'un non-dev va pouvoir atteindre le code; L'obfuscation fournira au moins une certaine défense. En ce qui concerne les criminalisant avant de faire un crime. Je préfère supprimer toute tentation et / ou sa capacité avant de découvrir qu'une personne "de confiance" a planté du code, copiée de code et / ou de données, etc. mais, hé, Si vous voulez croire que l'espionnage d'entreprise n'existe pas, alors plus de pouvoir. Heck, il y a quelques semaines, j'ai rencontré un gars qui avait une copie de son code source de concurrents. Je me demande comment il l'a eu.
@Chris, probablement du référentiel de contrôle source ou d'un ordinateur portable de développeur. Je doute fortement qu'ils ont décompilé le code d'octet glané d'une application Web de production. Au moins, cela semble être un vecteur improbable pour une attaque.
@Yishai: essayez ceci. Allez dans une entreprise, découvrez qui est son administrateur réseau. Offrez-lui 5K $ US pour une copie de leur site Web local, dites-lui que vous n'avez même pas besoin des données. En quelques jours, vous l'aurez presque certainement, zippé, prêt à partir.
Bien sûr, le moins susceptible de vous procurer une version emprisonnée est la suivante: attendez qu'un emploi soit affiché par la société en question, demandez-le, obtenez le travail. Copiez-le vous-même. Quitter.
Voici une lecture intéressante: Infoworld.com / D / Security-Central / ...
@Chrisllivelivement: Si vous êtes si inquiet de la sécurité de votre fichier compilé, dans le schéma de sécurité Linux / Unix (bit octal), il est possible / trivial d'autoriser un utilisateur à "exécuter" un programme sans lui permettre de lui permettre de lui permettre "Lire" le programme? Si vos comptes non-Devs n'ont aucune capacité de «lire» votre programme, vous n'avez pas besoin de rendre la vie difficile pour la DevTeam en raison de l'obfuscation. Je suis sûr que cela était aussi possible dans ACL. Tout ce qu'ils verront, c'est un fichier, et ils peuvent l'exécuter, mais ils ne peuvent pas l'ouvrir dans un éditeur de texte / hexagone ou de la copier.
@Chrislielivement: Comme il a été souligné, celui que vous devriez mieux connaître est l'équipe de développeur, qui a pleinement accès au code sous forme source dans le référentiel. Contrairement aux administrateurs quotidiens qui n'ont pas besoin de gâcher la source et dont le privilège de lecture, vous pouvez révoquer sans réduire leur efficacité, vous ne pouvez pas vraiment révoquer le privilège de DevTeam pour lire le référentiel (car sinon, les Devs ne seront pas être capable de travailler).
@Lie Ryan Comment l'obscurcissement d'une vie binaire compilée est-elle difficile pour les développeurs? Ce sont les seuls à regarder le code, de toute façon, et ils ont la source. Les seules personnes qui seront gênées par une binaire obscurcie sont celles qui n'ont pas accès à la source.
@David Lively, Java obscurposé, Java est beaucoup plus difficile à déboguer lorsqu'un problème se produit dans la production, car la trace de la pile n'est pas rendable au code source réel. Il y a des moyens autour de cela, mais cela rend la vie difficile.
@Chris animé, le résultat alternatif de cette expérience implique l'arrestation, l'heure de prison et quelques problèmes avec les perspectives de travail futures. Mais mon point global est si vous pouvez payer un SYS-admin pour envoyer au-dessus du code d'octet, vous pouvez payer une personne ayant accès au référentiel source du code. Obfuscation ne vous a pas nécessairement acheté.
@Yishai: Oui, vous pouvez également l'obtenir depuis un développement; Mais en obscurci, vous venez de limiter la piscine de personnes avec accès. Et il y a d'autres moyens de surveiller les stations de développement.
@Chris: Le problème est un employé interne ayant trop d'accès; la solution consiste à limiter leur accès. L'obfuscation est un tir dans la mauvaise direction.
@Lie Ryan: Il y a des menaces internes et externes. Cela aide à un aspect -> celui de trop d'accès a été acquis. En outre, à basculer que le bit de sécurité ne fait rien pour protéger les fichiers de personnes dont la responsabilité est de contrôler ce très peu.
@Chris: Et pourquoi cette situation est-elle pire que les personnes dont le travail consiste à exécuter l'Obfuscator sur le programme? Pourquoi donneriez-vous une personne non approuvée le privilège de définir les bits «Lire»? De même, pourquoi laisseriez-vous une personne non approuvée à obscurcir le programme?
Peut-être que nous avons besoin d'obfuscation pour protéger des hôtes Web volant notre code, non?
absolument oui.
Si votre processus de développement est correct, seuls les fichiers de support et certains fichiers de support (balises et feuilles de style, par exemple) doivent être sur le serveur. Il n'y a pas de bonne raison pour pas Obfuscate binaires dans n'importe quel environnement de production.
D'autres ici ont dit que cela crée des problèmes pour le personnel. Les seules personnes qui devraient être conscientes ou préoccupées par le contenu de vos fichiers binaires sont des développeurs - et ils ont la source, ils ne devraient donc pas être préoccupés par des objets compilés autour des objets compilés.
La seule raison pour laquelle je peux voir que quiconque n'a pas accès à la source serait intéressé par le contenu du binaire serait ingénierie inverse - et personne de votre personnel ne devrait avoir aucun intérêt pour ingénierie inverse de votre propre produit, Sauf si ils n'ont pas accès à la source. Cela signifie qu'ils ne sont pas effacés pour ce code, ou vous l'avez perdu, ce qui signifie que votre système de contrôle source est nul ou manque totalement. C'est une conversation complètement différente.
J'ai déjà entendu des exemples pratiques d'obfuscation côté serveur causant leur développement ou des difficultés administratives.
Peut-être que nous avons besoin d'obfuscation pour protéger des hôtes Web volant notre code, non?