CN114826556A - Front-end code processing method and device - Google Patents

Abstract

The invention relates to a front-end code processing method and a front-end code processing device, which are used for reducing the key exposure risk. The method comprises the following steps: acquiring a secondary key, wherein the secondary key is generated according to a real key and a preset algorithm; introducing the secondary key into a front-end code, and decrypting the secondary key according to the preset algorithm to obtain a real key and a version number; if the version number passes the verification, encrypting the information to be encrypted in the front-end code according to the real key; the front-end code is deeply obfuscated to generate a front-end code file for use by the browser.

Description

Front-end code processing method and device

technical field

The present disclosure relates to the field of front-end technologies, and in particular, to a method and apparatus for processing front-end codes.

Background technique

Since the front-end code is executed in the client's browser, it is in a public state. Anyone can get the front-end code through the browser's developer tools, so that any private information contained in the front-end code may be leaked. Therefore, some In scenarios, encryption needs to be used at the front end to improve data security. For the balance between security and performance, the industry usually adopts the AES (Advanced Encryption Standard, Advanced Encryption Standard) encryption algorithm, but how to improve the security of the AES key is the key point to ensure the security of front-end encryption. The industry usually has the following methods:

Obtain the key from the server through the interface request. The essence of this method is to store the key on the server side and obtain it from the server side when needed. The advantage of this method is that the security of key storage is ensured. At the same time, each time a key is obtained, the server can generate a new key and issue it to ensure that the key is updated at any time. However, the shortcomings are also obvious. First, although the server-side storage ensures the security of key storage, there is still a risk of leakage during the key transmission process. The attacker can easily obtain the key issued by the interface through the developer debugging tool of the browser. Secondly, obtaining the key from the server will block the encryption process. The client must wait for the interface to be successfully delivered before encryption. In many scenarios with high timeliness requirements, the response speed of the page will be reduced and the user experience will be affected.

Store keys in the local client cache, such as cookies (data stored on the user's local terminal), localstorage (local storage), etc. The advantage of this method is that it does not block the encryption process and can be taken as needed. However, the disadvantages are also obvious. The attacker can easily obtain the key from the cache, and it is more troublesome to update the key, and the client code needs to be modified and republished.

Store the key in the obfuscated compressed code on the client side. The usual practice is to write the key directly in the front-end code, and then compress and obfuscate the front-end code. In this way, the attacker must debug or analyze the front-end code to find the key in the compressed obfuscated code. However, this method only increases the cost of cracking the key relatively, and attackers familiar with browser developer tools can still obtain the key relatively easily.

SUMMARY OF THE INVENTION

To overcome the problems existing in the related art, embodiments of the present disclosure provide a front-end code processing method and apparatus. The technical solution is as follows:

According to a first aspect of the embodiments of the present disclosure, there is provided a front-end code processing method, including:

Obtain a secondary key, wherein the secondary key is generated according to the real key and a preset algorithm;

Introducing the secondary key into the front-end code, and decrypting the secondary key according to the preset algorithm to obtain the real key and version number;

If the version number verification is passed, encrypt the information to be encrypted in the front-end code according to the real key;

Deeply obfuscate front-end code to generate front-end code files for browser use.

In one embodiment, generating a secondary key according to a real key and a preset algorithm includes:

Generate multiple obfuscated keys according to the real key and form an obfuscated key array, wherein each obfuscated key is a string composed of the same character set as the real key, and the length is the same as the real key;

Randomly insert the real key into the obfuscated key array, and record the position of the real key in the obfuscated key array as the first insertion position;

Insert the preset key version number into the obfuscated key array, and record the position of the key version number in the obfuscated key array as the second insertion position;

inserting the first insertion position and the second insertion position into a preset position of the obfuscated key array;

Convert the obfuscated key array to a string by default;

Use the preset encryption algorithm to encrypt the string to obtain the secondary key.

In one embodiment, inserting the first insertion position and the second insertion position into a preset position of the obfuscated key array includes inserting the first insertion position and the second insertion position into the obfuscated key array. Last.

In one embodiment, the module for generating the secondary key is independent of the front-end code, and the front-end code imports the decryption module for decrypting the secondary key to obtain the real key as a dependency.

According to a second aspect of the embodiments of the present disclosure, there is provided a front-end code processing apparatus, comprising:

an acquisition module, configured to acquire a secondary key, wherein the secondary key is generated according to a real key and a preset algorithm;

A decryption module for introducing the secondary key into the front-end code, and decrypting the secondary key according to the preset algorithm to obtain a real key and a version number;

an encryption module, used for encrypting the front-end code according to the real key if the version number verification is passed;

The obfuscation module is used to deeply obfuscate the front-end code to generate front-end code files for browsers.

In one embodiment, the apparatus further includes: a generating module configured to generate a secondary key according to the real key and a preset algorithm, including:

Generate multiple obfuscated keys according to the real key and form an obfuscated key array, wherein each obfuscated key is a string composed of the same character set as the real key, and the length is the same as the real key;

Randomly insert the real key into the obfuscated key array, and record the position of the real key in the obfuscated key array as the first insertion position;

Insert the preset key version number into the obfuscated key array, and record the position of the key version number in the obfuscated key array as the second insertion position;

inserting the first insertion position and the second insertion position into a preset position of the obfuscated key array;

Convert the obfuscated key array to a string by default;

Use the preset encryption algorithm to encrypt the string to obtain the secondary key.

In one embodiment, inserting the first insertion position and the second insertion position into a preset position of the obfuscated key array includes inserting the first insertion position and the second insertion position into the obfuscated key array. Last.

In one embodiment, the module for generating the secondary key is independent of the front-end code, and the front-end code imports the decryption module that decrypts the secondary key to obtain the real key as a dependency.

According to a third aspect of the embodiments of the present disclosure, there is provided a front-end code processing apparatus, characterized by comprising:

processor;

memory for storing processor-executable instructions;

where the processor is configured as:

Obtain a secondary key, wherein the secondary key is generated according to the real key and a preset algorithm;

Decrypt the secondary key according to the preset algorithm to obtain the real key and version number;

If the version number verification is passed, encrypt the front-end code according to the real key;

Deeply obfuscate front-end code to generate front-end code files for browser use.

According to a fourth aspect of the embodiments of the present disclosure, there is provided a computer-readable storage medium on which computer instructions are stored, characterized in that, when the instructions are executed by a processor, any one of the first aspects of the embodiments of the present disclosure is implemented. steps of a method.

In the technical solutions provided by the embodiments of the present disclosure, the time-consuming asynchronous request is avoided, which greatly shortens the time for obtaining data from the backend in the scenario of interface request encryption, improves the corresponding speed and user experience of the entire page, and avoids It avoids the risk of the key being cracked during transmission; avoids the problem that the local cache easily leads to key leakage and difficulty in updating; by introducing a "secondary key", the risk of key exposure is further reduced and the difficulty of cracking is increased. The key is finally obtained through debugging. This key is also a processed "secondary key" and cannot be used directly. At the same time, through the version verification of the key, once the key is broken, the key can be updated in time and Upgrade the key version and key generation algorithm to completely invalidate the exposed key and reduce the loss caused by key exposure.

It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure.

Description of drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the disclosure and together with the description serve to explain the principles of the disclosure.

1 is a flowchart of a front-end code processing method according to an exemplary embodiment;

2 is a flowchart of a front-end code processing method shown according to an exemplary embodiment;

3 is a flowchart of a front-end code processing method according to an exemplary embodiment;

4 is a block diagram of a front-end code processing apparatus shown according to an exemplary embodiment;

5 is a block diagram of a front-end code processing apparatus shown according to an exemplary embodiment;

Fig. 6 is a block diagram of a front-end code processing apparatus according to an exemplary embodiment.

Detailed ways

Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. When the following description refers to the drawings, the same numerals in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the illustrative examples below are not intended to represent all implementations consistent with this disclosure. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present disclosure as recited in the appended claims.

For the encryption key of the front-end code, the current industry usually: obtain the key from the server through an interface request; store the key in the local client cache; or store the key in the obfuscated compression code of the client. However, none of the above-mentioned processing methods for encryption keys can guarantee the security of the keys. Embodiments of the present invention provide a front-end code processing method to improve this situation.

An embodiment of the present invention provides a front-end code processing method, as shown in FIG. 1 , including the following steps 101 to 104:

In step 101, a secondary key is obtained, wherein the secondary key is generated according to the real key and a preset algorithm.

In this embodiment, the developer needs to obtain a key when processing the front-end code, so as to encrypt the information to be encrypted in the front-end code. The information to be encrypted here is some key information in the code running process, such as the request parameters of the http request, the user's private information, etc. The secondary key may be generated by a generation module independent of the service code according to the real key and the preset algorithm, that is, it is not the real key. The input of the generation module is the real key, and then the real key is encrypted and the secondary key is output for use. Here, the module that generates the secondary key is independent of the service, so that the attacker cannot crack the encryption logic of the secondary key through the service code.

In step 102, the secondary key is introduced into the front-end code, and the secondary key is decrypted according to a preset algorithm to obtain the real key and version number.

For example, the secondary key is generated according to the real key and a preset encryption algorithm. To obtain the real key, the inverse operation of the preset encryption algorithm can be used to obtain the real key. In this embodiment, a version number is also added to the secondary key. After the real key and version number are obtained by decryption, verification can be performed according to the version number first. The decryption module part of the front-end code has a built-in correct version The version number obtained after the secondary key is decrypted should be the same as the version number built into the decryption module. Only when the verification is passed and the version number is confirmed to be legal, the secondary key is valid and can be used to encrypt the information to be encrypted in the front-end code. In this way, once the key is compromised, the key can be updated in time and the key version and key generation algorithm can be upgraded, making the exposed key completely invalid and reducing the loss caused by key exposure.

In step 103, if the verification of the version number is passed, the information to be encrypted in the front-end code is encrypted according to the real key.

Illustratively, in this embodiment, the AES encryption algorithm is used to encrypt the front-end code.

In step 104, the front-end code is deeply obfuscated to generate a front-end code file used by the browser.

At this point, the secondary key has been introduced into the front-end code, and the information to be encrypted in the front-end code has been encrypted. The current front-end code file is deeply obfuscated, and the secondary key is also obfuscated. In one embodiment, a tool javascript-obfuscator (a JavaScript code obfuscation tool) can be used for code obfuscation. The obfuscation of javascript-obfuscator is more complicated and thorough, including slicing and storing strings separately, injecting useless code for logical obfuscation, flattening the code structure, injecting anti-debugging debugger and other strategies, which can greatly improve the unreadability of the code. and non-debuggability, while also making reverse recovery of obfuscated code more difficult.

In the technical solutions provided by the embodiments of the present disclosure, compared with the real-time key acquisition solution through network requests, the solution proposed in this application firstly avoids the time-consuming of asynchronous requests, which greatly shortens the time-consuming process in the interface request encryption scenario. The time it takes for the client to obtain data, and the overall corresponding speed and user experience of the page are improved. Secondly, it also avoids the risk of the key being cracked during transmission. Compared with the solution of storing the key in the local client cache, the solution proposed in this application avoids the problem that the local cache easily leads to the leakage of the key and the difficulty of updating. Compared with the solution of directly storing the real key in the front-end code, the solution proposed in this application further reduces the risk of key exposure and improves the difficulty of cracking by introducing a "secondary key". Even if the attacker finally obtains the key through debugging, the key is a processed "secondary key" and cannot be used directly. At the same time, through the version verification of the key, once the key is broken, it can be updated in time. key and upgrade the key version and key generation algorithm, making the exposed key completely invalid and reducing the loss caused by key exposure. In addition, through in-depth code obfuscation, compared with the traditional obfuscation method in the industry, the obfuscated code of this solution is more reliable and secure, which greatly increases the attack cost and enables most attackers to retreat. The solution proposed in this application greatly improves the security of the front-end AES key storage, takes into account the page performance, and achieves a good balance between security and performance.

The following describes the implementation process in detail through embodiments.

The generation of the secondary key in the step 101 can be performed in the generation module, which is independent of the service code. The method for generating the secondary key may include the following steps A1-A6:

Step A1: Generate a plurality of obfuscated keys according to the real key and form an array of obfuscated keys, wherein each obfuscated key is a string composed of the same character set as the real key, and has the same length as the real key.

Figure 2 is a schematic diagram of generating a secondary key. First, generate an obfuscated key based on the real key. The so-called "obfuscated key" is a string with the same length and the same character set as the real key, and the string is randomly generated. In terms of appearance features, it is no different from the real key. Multiple obfuscation keys can be generated at one time: obfuscated key 1, obfuscated key 2, ..., obfuscated key n, and multiple obfuscated keys form an obfuscated array A.

Step A2: Randomly insert the real key into the obfuscated key array, and record the position of the real key in the obfuscated key array as the first insertion position.

As shown in Figure 2, the real key is randomly inserted into the obfuscated key array A, and the insertion position P1 is remembered.

Step A3: Insert the preset key version number into the obfuscated key array, and record the position of the key version number in the obfuscated key array as the second insertion position.

As shown in Figure 2, the concept of version is added to the key obfuscation algorithm, the version number at this time is inserted into the obfuscated key array A, and the insertion position P2 is remembered.

Step A4: Insert the first insertion position and the second insertion position into preset positions of the obfuscation key array.

As shown in Figure 2, the positions P1 and P2 are inserted into the last of the obfuscated key group array A.

Step A5, converting the obfuscation key array into a string in a preset manner.

As shown in FIG. 2 , the preset method is, for example, a specific conversion rule, and the obfuscated key array A is converted into a string B according to the conversion rule. An appropriate conversion rule can be selected as required, as long as the conversion rule can splicing the key array into a string in a specific way (algorithm), and can restore each component of the original array from the string.

Step A6: Encrypt the character string using a preset encryption algorithm to obtain a secondary key.

As shown in Figure 2, the character string B is encrypted using the ABS encryption algorithm to generate a secondary key.

So far, the generation module has generated the secondary key with the version number. When processing the front-end code, you can apply for the secondary key from the generation module.

In one embodiment, as shown in FIG. 3, the processing method for encrypting the front-end code may include the following steps 301-305:

Step 301, apply for a secondary key from the generation module. The generating module generates a secondary key according to a preset algorithm.

Step 302: Perform reverse decryption on the secondary key according to the above preset algorithm to obtain the real key and version number respectively.

In one embodiment, the front-end code may also import a decryption module for decrypting the secondary key as a dependency.

Step 303, verify the version number.

Step 304, determine whether the version number is legal, if not, end, if yes, execute 305.

Step 305: Use the real key to encrypt the data that needs to be encrypted in the front-end code.

At this point, the encryption process of the front-end code is over. At this time, the secondary key is introduced into the front-end code, and the key data has been encrypted. The front-end code can be deeply obfuscated to generate a front-end code file for the browser. In this way, only the secondary key is stored in the service, and for example, the "secondary key" is stored in slices. When using, assemble the slices first, then perform reverse decryption according to the corresponding encryption process, obtain the real key, and then perform business encryption. The decryption code is hidden through deep obfuscation, which greatly increases the difficulty of cracking. In addition, the secondary encryption process for the key is independent of the business code, and the business code introduces the decryption module as a dependency, so that the key encryption algorithm can be upgraded and updated at any time, such as key upgrade every fixed cycle. , which can further ensure the security of key storage.

The following are the apparatus embodiments of the present disclosure, which can be used to execute the method embodiments of the present disclosure.

Fig. 4 is a block diagram of a front-end code processing apparatus according to an exemplary embodiment, the front-end construction apparatus may be a server or a part of a server, or a terminal or a part of a terminal, and the front-end construction apparatus may be implemented through software, hardware or two The combination of the two is realized as part or all of the electronic device. As shown in Figure 4, the front-end code processing device includes:

an obtaining module 401, configured to obtain a secondary key, wherein the secondary key is generated according to a real key and a preset algorithm;

Decryption module 402, for introducing the secondary key into the front-end code, and decrypting the secondary key according to the preset algorithm to obtain a real key and a version number;

The encryption module 403 is used for encrypting the front-end code according to the real key if the version number verification is passed;

The obfuscation module 404 deeply obfuscates the front-end code to generate a front-end code file used by the browser.

In one embodiment, the apparatus further includes: a generating module configured to generate a secondary key according to the real key and a preset algorithm, including:

Generate multiple obfuscated keys according to the real key and form an obfuscated key array, wherein each obfuscated key is a string composed of the same character set as the real key, and the length is the same as the real key;

Randomly insert the real key into the obfuscated key array, and record the position of the real key in the obfuscated key array as the first insertion position;

Insert the preset key version number into the obfuscated key array, and record the position of the key version number in the obfuscated key array as the second insertion position;

inserting the first insertion position and the second insertion position into a preset position of the obfuscated key array;

Convert the obfuscated key array to a string by default;

Use the preset encryption algorithm to encrypt the string to obtain the secondary key.

In one embodiment, inserting the first insertion position and the second insertion position into a preset position of the obfuscated key array includes inserting the first insertion position and the second insertion position into the obfuscated key array. Last.

In one embodiment, the module for generating the secondary key is independent of the front-end code, and the front-end code imports the decryption module that decrypts the secondary key to obtain the real key as a dependency.

5 is a block diagram of a front-end code processing apparatus 50 according to an exemplary embodiment. The front-end construction apparatus may be a server or a part of a server, or a terminal or a part of a terminal, and the front-end code processing apparatus includes:

processor 501;

memory 502 for storing instructions executable by processor 501;

Wherein, the processor 501 is configured as:

Obtain a secondary key, wherein the secondary key is generated according to the real key and a preset algorithm;

Introducing the secondary key into the front-end code, and decrypting the secondary key according to the preset algorithm to obtain the real key and version number;

If the version number verification is passed, encrypt the information to be encrypted in the front-end code according to the real key;

Deeply obfuscate front-end code to generate front-end code files for browser use.

Fig. 6 is a block diagram of a front-end code processing apparatus 600 according to an exemplary embodiment, the apparatus may be a mobile phone, a computer, a digital broadcasting terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device devices, personal digital assistants, etc.

The apparatus may include one or more of the following components: processing component 602, memory 604, power supply component 606, multimedia component 608, audio component 610, input/output (I/O) interface 612, sensor component 614, and communication component 616.

The processing component 602 generally controls the overall operation of the device 600, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing element 502 may include one or more processors 620 to execute instructions to perform all or part of the steps of the methods described above. Additionally, processing component 602 may include one or more modules to facilitate interaction between processing component 602 and other components. For example, processing component 602 may include a multimedia module to facilitate interaction between multimedia component 508 and processing component 602 .

Memory 604 is configured not to store various types of data to support operation at device 600 . Examples of such data include instructions for any application or method operating on device 600, contact data, phonebook data, messages, pictures, videos, and the like. Memory 604 may be implemented by any type of volatile or nonvolatile storage device or combination thereof, such as static random access memory (SRAM), electrically erasable programmable read only memory (EEPROM), erasable Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), Magnetic Memory, Flash Memory, Magnetic or Optical Disk.

Power supply assembly 606 provides power to the various components of device 600 . Power components 606 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to device 600 .

Multimedia component 608 includes screens that provide an output interface between device 600 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touch, swipe, and gestures on the touch panel. The touch sensor may not only sense the boundaries of a touch or swipe action, but also detect the duration and pressure associated with the touch or swipe action. In some embodiments, the multimedia component 608 includes a front-facing camera and/or a rear-facing camera. When the apparatus 600 is in an operation mode, such as a shooting mode or a video mode, the front camera and/or the rear camera may receive external multimedia data. Each of the front and rear cameras can be a fixed optical lens system or have focal length and optical zoom capability.

Audio component 610 is configured to output and/or input audio signals. For example, audio component 610 includes a microphone (MIC) that is configured to receive external audio signals when device 600 is in operating modes, such as call mode, recording mode, and voice recognition mode. The received audio signal may be further stored in memory 604 or transmitted via communication component 616 . In some embodiments, audio component 610 also includes a speaker for outputting audio signals.

The I/O interface 612 provides an interface between the processing component 602 and a peripheral interface module, which may be a keyboard, a click wheel, a button, or the like. These buttons may include, but are not limited to: home button, volume buttons, start button, and lock button.

Sensor assembly 614 includes one or more sensors for providing status assessment of various aspects of device 600 . For example, the sensor assembly 614 can detect the open/closed state of the device 600, the relative positioning of components, such as the display and keypad of the device 600, and the sensor assembly 614 can also detect a change in the position of the device 600 or a component of the device 600 , the presence or absence of user contact with the device 600 , the orientation or acceleration/deceleration of the device 600 and the temperature change of the device 600 . Sensor assembly 614 may include a proximity sensor configured to detect the presence of nearby objects in the absence of any physical contact. Sensor assembly 614 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 514 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

Communication component 616 is configured to facilitate wired or wireless communication between apparatus 600 and other devices. The device 600 can access a wireless network based on a communication standard, such as a walkie-talkie private network, WiFi, 2G, 3G, 4G or 5G, or a combination thereof. In one exemplary embodiment, the communication component 616 receives broadcast signals or broadcast related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 616 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

In an exemplary embodiment, apparatus 600 may be implemented by one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable A gate array (FPGA), controller, microcontroller, microprocessor or other electronic component implementation is used to perform the above method.

In an exemplary embodiment, there is also provided a non-transitory computer-readable storage medium including instructions, such as a memory 604 including instructions, executable by the processor 620 of the apparatus 600 to perform the method described above. For example, the non-transitory computer-readable storage medium may be ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, optical data storage device, and the like.

A non-transitory computer-readable storage medium, when the instructions in the storage medium are executed by the processor of the apparatus 600, the apparatus 600 can execute the above-mentioned front-end code processing method, and the method includes:

Obtain a secondary key, wherein the secondary key is generated according to the real key and a preset algorithm;

Introducing the secondary key into the front-end code, and decrypting the secondary key according to the preset algorithm to obtain a real key and a version number;

If the version number verification is passed, encrypt the information to be encrypted in the front-end code according to the real key;

Deeply obfuscate front-end code to generate front-end code files for browser use.

Other embodiments of the present disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or techniques in the technical field not disclosed by the present disclosure . The specification and examples are to be regarded as exemplary only, with the true scope and spirit of the disclosure being indicated by the following claims.

It is to be understood that the present disclosure is not limited to the precise structures described above and illustrated in the accompanying drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims (10)

1. a front-end code processing method, is characterized in that, comprises: Obtain a secondary key, wherein the secondary key is generated according to the real key and a preset algorithm; Introducing the secondary key into the front-end code, and decrypting the secondary key according to the preset algorithm to obtain the real key and version number; If the version number verification is passed, encrypt the information to be encrypted in the front-end code according to the real key; Deeply obfuscate front-end code to generate front-end code files for browser use. 2. The method according to claim 1, wherein generating a secondary key according to a real key and a preset algorithm, comprising: Generate multiple obfuscated keys according to the real key and form an array of obfuscated keys, wherein each obfuscated key is a string composed of the same character set as the real key, and the length is the same as the real key; Randomly insert the real key into the obfuscated key array, and record the position of the real key in the obfuscated key array as the first insertion position; Insert the preset key version number into the obfuscated key array, and record the position of the key version number in the obfuscated key array as the second insertion position; inserting the first insertion position and the second insertion position into a preset position of the obfuscated key array; Convert the obfuscated key array to a string by default; Use the preset encryption algorithm to encrypt the string to obtain the secondary key. 3. The method according to claim 2, wherein inserting the first insertion position and the second insertion position into a preset position of the obfuscation key array comprises, inserting the first insertion position and the second insertion position The caret position is inserted at the end of the obfuscated key array. 4. The method according to claim 1, wherein the module for generating the secondary key is independent of the front-end code, and the front-end code introduces a decryption module for decrypting the secondary key to obtain the real key as a dependency. 5. A front-end code processing device is characterized in that, comprising: an acquisition module, configured to acquire a secondary key, wherein the secondary key is generated according to a real key and a preset algorithm; A decryption module for introducing the secondary key into the front-end code, and decrypting the secondary key according to the preset algorithm to obtain a real key and a version number; an encryption module, used for encrypting the front-end code according to the real key if the version number verification is passed; The obfuscation module is used to deeply obfuscate the front-end code to generate front-end code files for browsers. 6. The device according to claim 5, wherein the device further comprises: a generating module for generating a secondary key according to a real key and a preset algorithm: Generate multiple obfuscated keys according to the real key and form an array of obfuscated keys, wherein each obfuscated key is a string composed of the same character set as the real key, and the length is the same as the real key; Randomly insert the real key into the obfuscated key array, and record the position of the real key in the obfuscated key array as the first insertion position; Insert the preset key version number into the obfuscated key array, and record the position of the key version number in the obfuscated key array as the second insertion position; inserting the first insertion position and the second insertion position into a preset position of the obfuscated key array; Convert the obfuscated key array to a string by default; Use the preset encryption algorithm to encrypt the string to obtain the secondary key. 7. The apparatus according to claim 6, wherein inserting the first insertion position and the second insertion position into a preset position of the obfuscation key array comprises: inserting the first insertion position and the second insertion position The caret position is inserted at the end of the obfuscated key array. 8 . The apparatus according to claim 5 , wherein the module for generating the secondary key is independent of the front-end code, and the front-end code imports the decryption module for decrypting the secondary key to obtain the real key as a dependency. 9 . 9. A front-end code processing device, characterized in that, comprising: processor; memory for storing processor-executable instructions; wherein the processor is configured to: Obtain a secondary key, wherein the secondary key is generated according to the real key and a preset algorithm; Decrypt the secondary key according to the preset algorithm to obtain the real key and version number; If the version number verification is passed, encrypt the front-end code according to the real key; Deeply obfuscate front-end code to generate front-end code files for browser use. 10. A computer-readable storage medium on which computer instructions are stored, characterized in that, when the instructions are executed by a processor, the steps of the method according to any one of claims 1-4 are implemented.

Images