MechMK1
2019-10-09 19:44:37 UTC
Ich habe immer fest daran geglaubt, dass Verschleierung im Wesentlichen nutzlos ist. Verschleierter Code ist nicht unmöglich zu lesen, nur schwerer zu lesen. Ich war der Überzeugung, dass ein ausreichend erfahrener Angreifer den verschleierten Code wieder in einen besser lesbaren Zustand versetzen kann.
OWASP empfiehlt jedoch die Verwendung der Verschleierung für mobile Clients. Ich frage mich daher, ob die Verschleierung glaubwürdiger ist, als ich ihr gegeben habe.
Daher meine Frage: Gibt die Verschleierung einen messbaren Sicherheitsvorteil? Insbesondere ein Vorteil, der die zusätzlichen Kosten, die Komplexität und die reduzierte Leistung überwiegt.
Hinweis: Wenn ich "Verschleierung" sage, spreche ich von absichtlichen Maßnahmen zur Verhinderung von Reverse Engineering. Compiler-Optimierungen werden durchgeführt, um die Leistung zu verbessern und nicht das Reverse Engineering zu verhindern, obwohl sie die Lesbarkeit der Baugruppe beeinträchtigen.
Nach meiner Erfahrung werden in der Sicherheitswelt nicht viele Messungen und empirische Beweise gesammelt.Es ist meistens eine Menge "gut, es sollte so funktionieren", anekdotische Erfahrungen und Extrapolation.Persönlich denke ich, dass es bei der Verschleierung von Code mehr um den Versuch geht, Geschäftsinteressen und Codegeheimnisse zu schützen, als um Sicherheit.
@SteveSether Ich dachte genauso, aber da ich OWASP als glaubwürdige Quelle betrachte, wollte ich sehen, ob meine Behauptung vielleicht falsch war.
Ein kleiner Vorteil der Verschleierung ist die Zerstörung von Informationen.Dinge wie gesprochene Sprache, Codierungsgewohnheiten usw. Der Prozess (letztendlich Code) kann neu verstanden werden, aber Identifikatoren gehen verloren.Obwohl ich mir keinen legitimen Grund dafür vorstellen kann.Zusätzlich kann eine Verschleierung (z. B. Java früher) Funktionen in die Ausgabe einführen, die mit der aktuellen Technologie / Dekompilierern nicht einfach wiederhergestellt werden können.Dies machte das Entkompilieren von Java unerträglich umständlich.So können selbst erfahrene Benutzer nicht auf den Code schließen.Das ist eine Situation, in der Verschleierung besser ist als die Konkurrenz.
Ich finde es faszinierend, dass die Möglichkeit der Deobfuscation stark vom Codestil abhängt.Zum Beispiel, wie wichtig die Variablennamen sind.Der Code könnte in einer relativ niedrigen Sprache geschrieben sein und sehr hohe Muster verwenden.Wie objektorientierte Klassen, die ungefähr auf Java-Ebene liegen, werden alle teilweise so oft wie nötig implementiert.Auch die Verwendung von Entwurfsmustern, die sich über noch längere Codebereiche erstrecken.All diese Strukturen werden hauptsächlich in Variablennamen ausgedrückt.Zwei Werte desselben Typs können unterschiedlichen Klassen angehören, ausgedrückt im Namen.Verschiedene Klassen können sogar gleich sein.
"OWASP empfiehlt die Verwendung der Verschleierung für mobile Clients" - möglicherweise nur, weil beispielsweise die Minimierung von JavaScript diese verschleiert, aber das eigentliche Ziel besteht darin, sie zu verkleinern, weniger Informationen zu übertragen und den Internetverkehr und die Ladezeiten von Webseiten zu beschleunigen
@Mawg OWASP empfiehlt jedoch nicht ausdrücklich, JavaScript zu verschleiern
Wofür ist diese Frage eigentlich?Die verlinkte OWASP-Seite gibt buchstäblich die Bedrohung an, dass die Verschleierung zum Schutz vor und ausführliche Beschreibungen sowohl der Bedrohung als auch der Lösungen beitragen soll.
Betrachten Sie es als ein Schloss an Ihrer Haustür.Es verhindert in keiner Weise, dass jemand hereinbricht, aber wenn das nächste Haus kein Schloss hat oder nicht besetzt ist, warum sollte die Person dann mit Ihrer Tür herumspielen wollen?Wenn sie ausreichend motiviert sind, um auf Sie abzuzielen, wird sie selbst ein elektrischer Zaun nicht aufhalten.Ein kaputtes Schloss kann auch vor Gericht verteidigt werden, da es beweist, dass die Person ein Motiv hatte, es zu bekommen, anstatt behaupten zu können, dass sie eingeladen wurde.
@Mawg Die Empfehlung befindet sich in einem Feld mit dem Titel "Wie verhindere ich" Reverse Engineering "?".Auf dieser Seite dreht sich alles um Reverse Engineering, nicht um Leistung.
Ich denke, ob es einen Sicherheitsvorteil bietet, ist unabhängig davon, ob es einen messbaren Sicherheitsvorteil bietet.Ich glaube, es gibt einen Sicherheitsvorteil, aber ich weiß nicht, wie ich den Nutzen messen soll.
Echte Javascript-Verschleierung: Übersetzen Sie alles in [JSFuck] (http://www.jsfuck.com/).
@Gloweye Außer dass es automatisierte Tools wie [JSUnFuck] (http://codertab.com/jsunfuck) gibt, die dies vollständig umkehren
Es ist das gleiche, als hätten Sie zwei gleiche Autos nahe beieinander geparkt, aber eines hat (sichtbar) Alarm installiert und das andere nicht.Wenn ein Bösewicht kommt und einen von ihnen stehlen will, welchen wird er wohl wählen?Natürlich, wenn er das Konkrete will, wird er es trotzdem nehmen.Es ist nur eine gute Praxis, die dich normalerweise nichts kostet, also tu es;) Im Zusammenhang mit JS betrachte ich sie normalerweise eher als Minifizierung als als Verschleierung.Und wenn die Quelle auf die Hälfte des Originals reduziert werden kann, ist es wirklich eine gute Idee, dies zu tun.
_ "... ein Vorteil, der die zusätzlichen Kosten, die Komplexität und die reduzierte Leistung überwiegt." _ - Es geht um die falsche Seite Ihrer Frage, aber ich werde das ergänzen (oder daran erinnern, dass es in "Kosten" enthalten ist, inZusätzlich zum Aspekt "reduzierte Leistung" treten die Schwierigkeiten auf, die Benutzer haben, wenn die Verschleierung selbst Fehler in den Code einführt.Dies ist eines der größten Probleme bei technischen Maßnahmen zur Durchsetzung des Urheberrechts: Sie beeinträchtigen die Benutzererfahrung ausnahmslos.Legit Benutzer, das heißt.Menschen, die herumhacken und den Kopierschutz umgehen, leiden nicht unter solchen negativen Auswirkungen.
Ich bin schockiert, dass irgendjemand es jemals für notwendig halten würde, Code * absichtlich * zu verschleiern!