Braucht der Web-Frontend-JS-Code Schutz? So schützen Sie Web-Front-End-JS-Code

Muss der Web-Front-End-JS-Code geschützt werden?

Dies erfordert eine detaillierte Analyse der konkreten Situation.
1. Wenn Sie nur eine einfache Funktion schreiben, z. B. ein Webseiten-Bildkarussell oder einen Laufschrifteffekt usw. Das erfordert keinen Schutz.
2. Wenn Sie einen großartigen Spezialeffekt sorgfältig entwerfen und den Spezialeffektcode, an dessen Implementierung Sie so hart gearbeitet haben, vor der willkürlichen Verwendung durch andere schützen möchten, sollten Sie diesen JS-Code schützen!
3. Wenn es auf der Seite wichtige Funktionen gibt, die durch JS-Code gesteuert werden, wie z. B. Transaktionslogik, Konto- und Passwortinformationen, Privatsphäre und sogar Kommunikation mit Remote-Servern oder Datenbanken usw., dann der entsprechende JS-Code sollte Schutz sein, JS-Code-Diebstahlschutz sollte durchgeführt werden!
Andernfalls kann es zu ernsthaften Problemen kommen, z. B. zur Analyse und zum Angriff durch Hacker. Sicherheitsrelevante Belange müssen stets im Keim erstickt und nicht dem Zufall überlassen werden. Es sei denn, es spielt für dich überhaupt keine Rolle.

Wie schützt man Web-Front-End-JS-Code?
1. Verpackung und Komprimierung
Manche Leute denken, dass Verpackung und Komprimierung der Schutz von JS-Code sind. Wie es scheint, kann eine Verpackung zumindest bis zu einem gewissen Grad Schutz bieten. Der Zweck der Verpackung und Komprimierung besteht jedoch nicht darin, den JS-Code zu schützen, sondern darin, die Verwendung zu erleichtern, die Codegröße zu reduzieren, die Verwendung zu erleichtern und die Übertragung zu erleichtern. Beispielsweise kann die modulare Programmierung 200 JS-Dateien erzeugen, wenn Sie „script src“ verwenden, um jede einzeln zu referenzieren ... das ist eine Art Folter, sei es für den Agenten oder das Netzwerkladen (der Browser wird es auch tun). sei wütend! x_x).
Ähnlich wie bei der Webpacket- und Gulp-Verpackung können diese mehreren JSs in einer Datei zusammengefasst werden, und Wagenrückläufe, Zeilenvorschübe und Leerzeichen können gelöscht werden, um eine Codekomprimierung zu erreichen. Es gibt auch einige einfache Verschleierungsoperationen: Ändern langer Variablennamen kurze Variablennamen in einem einheitlichen Stil usw. Anschließend wird schließlich eine Datei generiert. Die Gesamtmenge an Code wird reduziert, die Lesbarkeit ist schlecht und die Verwendung ist einfacher. Gleichzeitig glauben einige Leute, dass dadurch auch der Schutz des JS-Codes erreicht wird. Tatsächlich ist der Code natürlich nicht geschützt: Die Lesbarkeit ist immer noch dieselbe, aber die Codemenge ist größer. Solange Sie den Code mit etwas Geduld lesen, werden Sie feststellen, dass der Code immer noch leicht zu verstehen ist , und es gibt überhaupt nicht viel Sicherheit.
2. Verschleierung und Verschlüsselung
Um den Front-End-JS-Code zu schützen, müssen Verschleierung und Verschlüsselung kombiniert werden.
Eine Verschlüsselung des JS-Quellcodes allein ist nicht möglich, geschweige denn die sogenannte irreversible JS-Verschlüsselung. Denn wenn der Code auf der Browserseite ausgeführt wird, muss er entschlüsselt und in den ursprünglichen Code zurückversetzt werden, bevor er von der JS-Engine des Browsers erkannt und ausgeführt werden kann. Nach der Entschlüsselung ist der vollständige ursprüngliche JS-Code vorhanden. Dies ist sehr unsicher und es gibt viele Möglichkeiten, den ursprünglichen JS-Code anzuzeigen.
Die Verschleierung von JS-Code wird von vielen Entwicklern als eine Low-End-Methode zum Schutz von JS-Code angesehen und scheint weniger sicher zu sein als die Verschlüsselung von JS-Quellcode. Tatsächlich gibt es mehrere Ebenen der Verschleierung. Zum Beispiel relativ einfache Zeichensuche und String-Ersetzung, zufälliges Einfügen von Pseudo-Zombie-Code, String-Hexadezimalisierung usw. Es gibt auch High-End-Methoden, die zunächst eine Syntaxanalyse und eine lexikalische Analyse durchführen und den Syntaxbaum rekonstruieren. Dies entspricht der Implementierung einer JS-Engine und der Verarbeitung des Codes in der Engine. Anschließend können Sie Operationen mit hohem Grad ausführen Sie können jederzeit neue Syntaxstrukturen in den Syntaxbaum einfügen, alle Zeichenfolgen extrahieren und verschlüsseln, Variablen regelmäßig neu definieren, um sie bedeutungslos zu machen usw. Dies ermöglicht eine echte Code-Rekonstruktion. Die Sicherheit des so rekonstruierten JS-Codes wird qualitativ verbessert.
Wenn echte Verschleierung und Verschlüsselung zusammen verwendet werden, wie z. B. JShaman JS-Schutz, kann ein echter JS-Code-Sicherheitsschutz erreicht werden. Die JS-Verschlüsselung ist in die JS-Verschleierung integriert, und die JS-Verschleierung ist in die JS-Verschlüsselung eingebettet. Selbst wenn der auf diese Weise geschützte Code in der Client-Ausführungsumgebung rückwärts wiederhergestellt wird, wird eine große Anzahl von Funktionen, Codes und Zeichenfolgen mit unbekannter Bedeutung erhalten. Das Besondere ist: Der Code wurde rekonstruiert, und was Sie durch Reverse Engineering erhalten, ist auch der getrennte und rekonstruierte bedeutungslose JS-Code, eine große Anzahl von Zombie-Codes, verwirrte Zeichenfolgen und Variablen mit unbekannter Bedeutung. Die Lesbarkeit im Vergleich zum Originalcode ist ... ein himmelweiter Unterschied.
Hartnäckige Leute sagen vielleicht: Es gibt keine Schutzlösung, die nicht geknackt werden kann, solange ich sie sorgfältig und aufmerksam analysiere und mir Zeit nehme, kann ich die Bedeutung des Originalcodes noch analysieren .
Das Lesen des Originalcodes dauert jedoch möglicherweise nur 10 Minuten, das Lesen der ursprünglichen Bedeutung aus dem geschützten JS-Code kann jedoch ... 10 Monate dauern. Zu diesem Zeitpunkt wurde unser JS-Code möglicherweise auf die nächste Version aktualisiert.
Der Zweck des JS-Codeschutzes wurde erreicht, nicht wahr?

Verwandte Empfehlungen:

Web-Front-End-Code-Spezifikation

Web-Front-End-Entwicklung hochladen Avatar js Beispielcode hochladen

Das obige ist der detaillierte Inhalt vonBraucht der Web-Frontend-JS-Code Schutz? So schützen Sie Web-Front-End-JS-Code. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!