Devrions-nous protéger le code source de l'application Web contre le vol par des hôtes Web par le biais de l'obscurcissement?
Vaut-il la peine de masquer un code source d'application Web Java afin que l'hôte Web ne puisse pas faire un mauvais usage du code ou même voler votre entreprise? Si oui, comment cela devrait-il être traité? Comment nous obscurcissons?
Nous sommes une nouvelle start-up qui lance un produit sur le marché. Comment pouvons-nous protéger le code source de notre produit/application Web?
Un hébergeur malveillant peut faire bien plus que simplement voler votre code. Ils peuvent le modifier pour introduire des portes dérobées, ils peuvent voler les données de vos clients et ruiner toute votre entreprise. La confiance doit exister entre vous et l'hôte.
À propos du code source. Si l'attaquant essaie d'accéder à votre code source, il - va accéder à votre code source, obscurci ou non, compilé ou interprété.
Il y a est une valeur dans l'obscurcissement de votre code, en ce que vous le rendrez probablement un peu plus difficile à obtenir par l'attaquant opportuniste occasionnel. Mais si votre hôte est là pour vous, il vous aura.
La solution? La loi. Signez un contrat avec eux et acceptez une forme de SDA .
Eh bien, cela appelle trois commentaires:
Vous ne pouvez pas protéger les secrets avec l'obscurcissement de code. Pas vraiment. L'obscurcissement de code fonctionne d'une manière ou d'une autre contre des attaquants non motivés, mais il n'est pas fort. S'il y a une valeur commerciale à le traverser, alors cela se produira.
Si vous ne faites pas confiance à votre service d'hébergement, recherchez un autre service d'hébergement. Si le secret de votre code est important et vaut plus de quelques centaines de dollars, alors vous devez utiliser votre propre matériel: vous louez un espace de baie isolé, avec des serrures et des gardes, et vous y exécutez votre propre machine.
Votre code existe en tant que code compilé (octet) sur les serveurs, mais aussi en tant que code source dans vos systèmes de développement et dans les têtes de vos développeurs. Cela ne peut pas être que secret. Comme on dit, un million de dollars est toujours suffisant pour percer des secrets, ne serait-ce qu'en soudoyant l'un des individus qui en a été informé.
(Dans ce dernier cas, cela pourrait être votre plan: vous voudrez peut-être voir un plus gros concurrent simplement vous racheter.)
La protection contre l'ingénierie inverse et le vol de votre propriété intellectuelle est normalement assurée par des moyens légaux et non techniques.
Non, ça n'en vaut pas la peine. Personne ne veut voler votre code. Un millier de millions SaaS ont été lancés par des particuliers et des entreprises utilisant un hébergement tiers d'une description ou d'une autre, et à peu près aucun d'entre eux ne s'est retrouvé en concurrence avec eux-mêmes après avoir le code pour leurs produits volés par leurs hôtes.
Alors, devriez-vous masquer votre code? Bien sûr, si cela vous fait vous sentir mieux. Pas de mal. Protégez-vous votre adresse IP contre une menace valide? Non, pas vraiment. C'est une sorte de version pour développeur Web d'un chapeau en papier d'aluminium.
Quoi que vous fassiez, ne perdez pas beaucoup de temps et d'énergie à y penser. Prenez la décision de masquer ou non, puis passez à vous inquiéter de l'atténuation des menaces réelles.
En fin de compte, vous êtes le seul à pouvoir faire cette évaluation des risques. Si vous dormez mieux en obscurcissant votre code, allez-y.
Personnellement, cela ne me dérangerait pas. Les services d'hébergement Web réputés sont dans le domaine de l'hébergement Web et non dans celui du vol de code source. S'ils volent votre code, ils devraient tout de même l'installer, vendre le service, trouver des clients et repousser le procès que vous intenteriez contre eux. C'est trop d'efforts pour eux avec trop de risques pour trop peu de récompense.
L'obfuscation est inefficace contre un attaquant déterminé, cela ne fait que le rendre un peu plus difficile. Si vous avez une raison particulière de vous méfier de votre hébergeur, obtenez-en une autre.
Si vous voulez simplement être en sécurité, obtenez un accord de non-divulgation et d'autres garanties juridiques qui vous permettent de poursuivre votre hôte s'il abuse des choses.
Si vous ne leur faites toujours pas confiance, même avec ces garanties légales, procurez-vous des serveurs dédiés que vous pouvez contrôler et chiffrer de sorte que le fournisseur d'hébergement ne puisse pas accéder aux données à moins qu'ils ne piratent le serveur d'exploitation.
Si vous craignez que quelqu'un ait un accès physique à vos serveurs, configurez votre propre centre de données ou verrouillez-le physiquement dans un boîtier dans une installation colocalisée avec surveillance de la propriété physique.
Utiliser simplement un NDA devrait cependant être suffisant avec n'importe quel fournisseur d'hébergement réputé.
Je ne m'embêterais pas.
Deux raisons:
Les langages interprétés à l'exécution ne peuvent vraiment pas être entièrement protégés de cette façon. Pour l'obscurcir complètement, vous devez également l'obscurcir à partir du runtime, il n'y aurait alors aucun moyen de l'exécuter. L'obscurcissement rend la tâche légèrement plus ennuyeuse. Cela peut également rendre le débogage et le déploiement plus longs pour votre propre personnel.
Très peu d'applications contiennent vraiment le genre de code de sauce secret que les gens auraient vraiment du mal à voler. Il est beaucoup plus facile d'obtenir une liste de fonctionnalités et certains entrepreneurs et de dire "faire quelque chose comme ça" que de copier fonction par fonction avec les applications les plus courantes.
Vous devez prendre des précautions pour vous protéger, mais pas pour les raisons ou contre la menace que vous imaginez.
Tout d'abord, si vous ne pouvez pas faire confiance à votre hébergeur, obtenez un nouveau hébergeur. Il n'y a plus rien à dire à ce sujet.
Deuxièmement, même si vous pensez que la propriété intellectuelle dans l'application Web que vous avez créée est précieuse, vous êtes probablement la seule. Voleriez-vous le site Web de votre concurrent? Probablement pas; ça ne vaudrait pas la peine. En règle générale, les gens ne sont pas intéressés à voler votre site. Généralement, le coût de personnalisation du site de quelqu'un d'autre pour répondre à vos propres besoins se rapproche ou dépasse le coût de sa construction vous-même.
Enfin, vous devriez vous inquiéter que les attaquants récupèrent votre code et l'utilisent pour vous attaquer. Mots de passe enregistrés, bases de données utilisateur, erreurs de programmation et vulnérabilités - votre code présente probablement une cible juteuse pour les attaquants malveillants. Cela est particulièrement vrai si votre code est mal écrit ou si votre service est populaire.
L'obscurcissement de votre code n'est pas une solution et n'aiderait pas de toute façon. Mais de bonnes pratiques de sécurité, notamment le respect du principe du moindre privilège, devraient vous aider. Séparez votre accès afin de compromettre un système ou un composant ne donne pas à votre attaquant toute l'application dans un petit ensemble soigné. Plus les éléments de votre entreprise sont indépendants et déconnectés, moins un attaquant peut accrocher en une seule fois.
J'ai de nombreuses applications Web hébergées en ligne. Certains codes sont précieux, oui. Cependant, je n'ai rien obscurci car même s'il est volé, personne d'autre ne peut le maintenir. Ils finiront par arracher leurs cheveux. Je l'ai essayé avec quelqu'un qui voulait vraiment mon logiciel. Il ne pouvait pas l'installer, le comprendre ni en tirer quoi que ce soit, alors comment pourrait-il trouver des clients et le vendre comme mentionné ci-dessus.
La valeur réside dans les données et dans le soutien que vous apportez et qui gardent le client satisfait.
Toutes mes applications de bureau peuvent être décompilées d'une manière ou d'une autre. Je pense que VB6 était le seul qui ne pouvait pas être décompilé. Personne ne pouvait les maintenir car j'utilise un codage délicat et des noms de variables délicats.
Il n'y a aucun intérêt en matière de sécurité à tenter de masquer un code côté client. Un attaquant suffisamment déterminé va contourner toutes les méthodes d'obscurcissement que vous lui lancez.
Si le code est vraiment important, conservez-le du côté des entreprises. Considérez tout code côté client public et accessible à tous.
Lorsque vous ne faites pas confiance à votre hébergeur pour ne pas voler vos données, vous devez rechercher un hébergeur plus fiable ou vous héberger vous-même.
Vous ne leur confiez pas seulement votre code de programme, vous confiez également toutes vos données et les données de tous vos utilisateurs. Lorsque vous supposez que votre hébergeur est suffisamment malveillant pour voler votre programmation, ils sont également suffisamment malveillants pour voler vos données utilisateur et les vendre au plus offrant. Données que vous avez probablement promis de protéger en vertu d'une politique de confidentialité.
Lorsque vous arrivez à la conclusion que vous ne faites confiance à aucun hébergeur mais que l'hébergement vous coûte trop cher, vous avez la possibilité d'acheter votre propre serveur physique et de laisser quelqu'un d'autre l'héberger, mais 1. chiffrez entièrement son système de fichiers afin qu'il ne puisse pas clonez les disques durs pendant la maintenance et 2. assurez-vous que toutes les communications réseau sont cryptées afin qu'ils ne puissent pas détecter le trafic.
Le monde est à l'envers, la vraie valeur n'est généralement pas dans le code de l'application. C'est dans les données client que le code est utilisé pour recueillir/modifier. Dans de nombreuses applications Web, le code est sécurisé et les données se trouvent souvent en clair sans aucune protection simple. C'est l'un des problèmes que PCI DSS, HIPAA et d'autres normes de sécurité des données sont censés résoudre.
En supposant que votre hébergeur est malveillant, l'accès aux données client détruira votre entreprise beaucoup plus rapidement que l'obtention de votre code.
Outre le problème de la sécurité par l'obscurité, l'obfuscation du code peut également introduire des problèmes de sécurité et devra être vérifiée au même niveau ou à un niveau supérieur à votre base de code habituelle.
Vous ne pouvez pas obscurcir suffisamment votre code ou vos données pour les sécuriser. Si vous le pouviez, votre code et vos données seraient même inutilisables pour vous.
La sécurité par l'obscurité ne fonctionne que tant que le secret de votre obscurcissement reste intact. Les secrets ne restent jamais secrets. C'est la base de la plupart des systèmes de droits numériques et, à ce jour, tous ont été piratés.
Sur une note plus technique, si vous utilisez un langage interprété (Perl, PHP) ou un langage interprété par bytecode (Java), envisagez d'utiliser les outils de compilation natifs inclus pour eux. Beaucoup de ces langages de haut niveau incluent un outil pour sortir une version C/C++ de vos scripts ou compiler en natif pour votre matériel. Avoir une version compilée en mode natif supprime la nécessité de conserver votre arborescence source sur vos serveurs distants et offre également une amélioration significative des performances.
L'obfuscation ne cache ni ne modifie jamais votre code, il le modifie simplement dans un autre format dans lequel il peut le traiter,
Ex: si vous voulez masquer le nom de votre classe MyHomePage mon être changé en M4Page De même, une méthode addWidgets () sera nommée dans un autre, et le nom de la fonction peut également être changé, pas la fonctionnalité donc si je souhaite appeler la méthode à partir de votre code obscurci, je peux facilement l'implémenter ...
Non.
De toute évidence: vous prévoyez d'investir du temps dans un soi-disant la sécurité par l'obscurité La technologie.
Ce n'est pas une bonne idée!
Pour protéger votre idée contre les licences de tiers, vous pouvez les publier sous une licence publique telle que GNU GPL , creative commons ou autres.
La sécurité par obscurité n'est pas mauvaise si ce n'est pas seulement la chose sur laquelle vous comptez. L'utilisation de l'obfuscation pour protéger votre code ne fonctionnera pas, mais l'utilisation de l'obfuscation avec d'autres licences n'est pas mauvaise.