MechMK1
2019-10-09 19:44:37 UTC
J'ai toujours fermement cru que l'obfuscation est essentiellement inutile. Le code obscurci n'est pas impossible à lire, mais plus difficile à lire. J'avais la conviction qu'un attaquant suffisamment expérimenté serait en mesure de ramener le code obscurci dans un état plus lisible.
Cependant, OWASP recommande l'utilisation de l'obscurcissement pour les clients mobiles, ce qui me fait me demander s'il y a plus de crédibilité à l'obscurcissement que ce que je lui avais donné.
D'où ma question: l'obfuscation apporte-t-elle un avantage mesurable en matière de sécurité? Plus précisément, un avantage qui l'emporte sur le coût supplémentaire, la complexité et les performances réduites.
Remarque: Quand je dis "obscurcissement", je parle de mesures délibérées prises pour empêcher l'ingénierie inverse. Les optimisations du compilateur, même si elles rendent l'assemblage moins facile à lire, sont effectuées dans le but d'améliorer les performances et non d'empêcher la rétro-ingénierie.
D'après mon expérience, il n'y a pas beaucoup de mesures et de collecte de preuves empiriques dans le monde de la sécurité.C'est surtout beaucoup de "bien ça DEVRAIT fonctionner comme ça", d'expériences anecdotiques et d'extrapolation.Personnellement, je pense que l'obscurcissement du code est plus une tentative de protéger les intérêts commerciaux et les secrets de code que la sécurité.
@SteveSether J'ai pensé de la même manière, mais étant donné que je considère OWASP comme une source crédible, je voulais voir si mon affirmation était peut-être fausse.
Un petit avantage de l'obfuscation est la destruction des informations.Des choses comme la langue parlée, les habitudes de codage, etc. Le processus (finalement le code) peut être re-compris, mais les identifiants sont perdus.Bien que je ne puisse pas penser à une raison légitime à cela.De plus, certaines obscurcissements (par exemple Java à l'époque) peuvent introduire des fonctionnalités dans la sortie qui ne peuvent pas être facilement reconstruites avec la technologie / décompilateurs actuels.Cela rendait Java extrêmement compliqué à décompiler.Ainsi, dissuadant même les utilisateurs expérimentés de déduire le code.C'est une situation d'obscurcissement-vaut-mieux-que-ses-concurrents.
Je trouve fascinant que la possibilité de désobfusquer dépend fortement du style de code.Comme l'importance des noms de variables.Le code pourrait être écrit dans un langage de niveau relativement bas et utiliser des modèles de très haut niveau.Comme les classes orientées objet à peu près au niveau de java, toutes implémentées partiellement autant que nécessaire.En outre, l'utilisation de modèles de conception, couvrant des régions de code encore plus longues.Toute cette structure est principalement exprimée en termes de noms de variables.Deux valeurs du même type peuvent être de classes différentes, exprimées dans le nom.Différentes classes peuvent même être identiques.
"OWASP recommande l'utilisation de l'obscurcissement pour les clients mobiles" - peut-être simplement parce que, par exemple, la minimisation de JavaScript l'obscurcit, mais le véritable objet est simplement de le rendre plus petit, de transférer moins d'informations et d'accélérer le trafic Internet et les temps de chargement des pages Web
@Mawg Pourtant, OWASP ne recommande pas spécifiquement de masquer JavaScript
À quoi sert cette question?La page OWASP liée donne littéralement la menace que l'obfuscation est censée aider à se protéger et de longues descriptions de la menace et des solutions.
Considérez-le comme une serrure sur votre porte d'entrée.Cela n'empêche en aucun cas quelqu'un de s'introduire, mais si la maison voisine n'a pas de serrure ou n'est pas engagée, pourquoi la personne voudrait-elle jouer avec votre porte?S'ils sont suffisamment motivés pour vous cibler, même une clôture électrique ne les arrêtera pas.Une serrure cassée est également défendable devant le tribunal car elle prouve que la personne avait un motif pour l'obtenir plutôt que de pouvoir prétendre qu'elle a été invitée à l'intérieur.
@Mawg La recommandation se trouve dans un encadré intitulé «Comment éviter la« rétro-ingénierie »?».Cette page concerne la rétro-ingénierie, pas les performances.
Je pense que la question de savoir si cela donne un avantage en matière de sécurité est distincte de savoir si elle donne un avantage de sécurité mesurable.Je pense que cela donne un avantage de sécurité, mais je ne sais pas comment mesurer l'avantage.
Véritable obfuscation Javascript: traduisez tout en [JSFuck] (http://www.jsfuck.com/).
@Gloweye Sauf qu'il existe des outils automatisés comme [JSUnFuck] (http://codertab.com/jsunfuck) qui l'inversent complètement
C'est la même chose que si vous aviez deux mêmes voitures garées près l'une de l'autre, mais l'une aura (visiblement) une alarme installée et l'autre non.Si un méchant vient et veut en voler un, lequel pensez-vous qu'il choisira?Bien sûr, s'il veut le concret, il le prendra quand même.C'est juste une bonne pratique qui ne vous coûte généralement rien, alors faites-le;) Lié à JS, je le considère généralement comme une minification plutôt que comme une éducation.Et si la source peut être réduite à la moitié de l'original, c'est vraiment une bonne idée de le faire.
_ "... un avantage qui l'emporte sur le coût supplémentaire, la complexité et les performances réduites." _ - il répond au mauvais côté de votre question, mais j'ajouterai à cela (ou je rappellerai qu'il est inclus dans le "coût", dansoutre l'aspect «performances réduites») les difficultés rencontrées par les utilisateurs lorsque l'obscurcissement lui-même introduit des bogues dans le code.C'est l'un des plus gros problèmes des mesures techniques destinées à faire respecter le droit d'auteur: elles rendent invariablement l'expérience utilisateur plus pauvre.Utilisateurs légitimes, c'est-à-dire.Les personnes qui piratent et contournent la protection contre la copie ne souffrent pas de ces effets néfastes.
Je suis choqué que quiconque considère qu'il est nécessaire de masquer * intentionnellement * le code!