Web application anti-debugging method based on dynamic code distribution and full-link verification

Abstract

The invention discloses a Web application anti-debugging method based on dynamic code distribution and full-link verification, which comprises the following steps of: segmenting a front-end core code, and carrying out dynamic code distribution; mixing and encrypting the segmented core code; equipment fingerprints are generated regularly to be bound with the Token; dynamic loading and execution are carried out through WASM; the server side constructs an interface calling atlas according to the service logic, and full-link verification is carried out; the terminal obtains a device fingerprint; when the server side receives the request, dynamic Token generation and verification are carried out; the request content is dynamically encrypted and returned to the front end for decryption; and real-time connection between the front end and the server end is carried out, and defense is carried out based on distributed fusing control. By combining a plurality of advanced technical means such as module dependence atlas, interface calling atlas constraint, dynamic Token and equipment fingerprint binding and the like, the difficulty of code reverse engineering is remarkably improved, illegal requests are intercepted, and a set of all-around and multi-level comprehensive defense method is constructed for Web application.

Description

Technical Field

[0001] The present invention relates to a Web application anti-debugging method, and in particular to a Web application anti-debugging method based on dynamic code distribution and full-link verification. Background Art

[0002] In today's rapidly developing digital era, web applications have become a core hub for information exchange and are widely used in data transmission scenarios between users and organizations. However, their open architecture brings a series of security risks: Web applications need to address multiple security issues, including application vulnerability protection, preventing the leakage of sensitive user information, protecting core logic, and ensuring system stability, to meet growing security demands. Modern web applications generally adopt single-page applications (SPAs) or progressive web application (PWA) architectures, with a large amount of business logic migrating to the front-end. Operations such as data validation and encryption calculations are all performed on the front-end, making the front-end a prime target for attackers and significantly increasing the risk of attack. Furthermore, attackers can use professional debugging tools such as Chrome DevTools and Fiddler to perform malicious operations such as code injection, parameter tampering, and request interception. They can also use crawler technology to steal data, posing significant security risks to web applications. Existing anti-debugging technologies have the following shortcomings: 1. Traditional code obfuscation tools, such as UglifyJS, can only perform basic operations such as variable name replacement and format compression. Through technical means such as abstract syntax tree (AST) parsing, attackers can still restore the control flow structure of the code, reducing the protective effect of code obfuscation. Second, common debugging detection methods, such as using debugger statements for detection, can be disabled by setting breakpoints. Furthermore, when using performance monitoring functions to detect debugging behavior, attackers can easily bypass detection by forging timestamps, rendering the debugging detection mechanism ineffective. 3. Traditional static token mechanisms use fixed tokens for authentication. Fixed tokens lack dynamic binding with device features or call contexts. Attackers can capture and reuse tokens to forge legitimate requests. Fourth, the existing server-side interface verification mechanism only verifies the legitimacy of a single interface and does not establish a call order between interfaces. Attackers can forge request sequences to bypass verification. 5. The front-end and server-side protection strategies are independent of each other and lack an effective coordination mechanism. For example, when an attacker bypasses the front-end debugging detection, they can send a request with a forged signature to the server. The server cannot detect and prevent such attacks in time, and a comprehensive defense system has not been formed, resulting in poor overall defense effectiveness and an inability to meet the growing security needs of Web applications. Summary of the Invention

[0003] In order to address the shortcomings of the above technologies, the present invention provides a Web application anti-debugging method based on dynamic code distribution and full-link verification.

[0004] To solve the above technical problems, the present invention adopts a technical solution: a Web application anti-debugging method based on dynamic code distribution and full-link verification, which specifically includes the following steps: Step S1: Split the front-end core code according to the functional cohesion rules and low coupling principles to obtain several atomic modules that can be loaded and executed independently on demand. Build a module dependency graph to perform dynamic code distribution and protection. Among them, a time window constraint mechanism is set between each atomic module; Step S2: Obfuscate and encrypt the segmented core code based on JavaScript Obfuscato; Step S3: Collect hardware features based on Fingerprint JS, generate device fingerprints regularly and bind them to Token; Step S4: Dynamically load and execute the split, encrypted, and obfuscated core code through WASM to perform memory protection and fuse mechanism protection; Step S5: The server constructs an interface call graph based on the business logic. When receiving a request, the server verifies the call graph in sequence and performs full-link verification. Step S6: The server obtains the device fingerprint; Step S7: The server generates and verifies a dynamic token when receiving the request; Step S8: Dynamically encrypt the request content and return it to the front end, which decrypts it; Step S9: Establish a real-time connection between the front-end and the server based on the WebSocket real-time channel, and perform defense based on distributed circuit breaker control.

[0005] Furthermore, in step S1, dynamic code distribution and protection are performed, which specifically includes the following steps: Step S11: Conduct a comprehensive analysis of the functional requirements of the Web application; Step S12: Based on the functional requirement analysis results obtained in step S11, the Web application is divided into several independent atomic modules, each of which has clear inputs and outputs; Step S13: Detailed design of each atomization module; Step S14: Module coding is performed according to the design to ensure that the functional implementation of each atomized module meets actual requirements; Step S15: Perform unit detection and comprehensive testing on each atomized module.

[0006] Furthermore, in step S2, the segmented core code is obfuscated, specifically including the following steps: Step A1: Convert the original sequential execution logic into a Switch-Case structure and insert several useless branches to flatten the control flow; Step A2: Encrypt the plaintext string; Step A3: Insert a conditional branch that is never executed; In step S2, the divided core code is encrypted, which specifically includes the following steps: Step B1: Encrypt the obfuscated code using the AES-256-GCM symmetric encryption algorithm; Step B2: Encrypt and transmit the AES key based on the RSA-OAEP algorithm, and embed the public key into the WASM module to effectively prevent key leakage.

[0007] Furthermore, in step S3, the device fingerprint is bound to the token, which specifically includes the following steps: Step S31: Collect various hardware feature information of the device; Step S32: Process the collected hardware feature information, concatenate the hash values ​​of multiple hardware feature information, perform hash calculation again, and generate a unique device fingerprint; Step S33: Generate original data by combining the device fingerprint, timestamp, and random number; and use the HMAC-SHA256 algorithm to sign the original data and bind it to the session validity period; Step S34: The server verifies and parses the token to obtain the device fingerprint in the original data; Step S35: Compare the device fingerprint of the current device with the device fingerprint in the Token in step S34 to see if they are consistent; if the two are consistent, perform Token signature verification; if the two are inconsistent, trigger an exception.

[0008] Furthermore, in step S4, dynamic loading and execution are performed through WASM, specifically including the following steps: Step C1: Use the Rust language to write module call verification logic and compile it into a WASM module using the wasm-pack tool; Step C2: The front-end initiates a module request, carrying the current device fingerprint and call context; Step C3: After verifying the legitimacy of the request, the server returns the module code encrypted with AES-256-GCM and the key encrypted with RSA-OAEP; Step C4: The WASM module decrypts and verifies the code integrity, and dynamically executes it through the Function constructor.

[0009] Furthermore, in step S4, memory protection and fuse protection are performed, which specifically includes the following steps: Step D1: Use WebAssembly.Memory to independently allocate memory space for the WASM module and prohibit JavaScript from directly accessing this memory area; Step D2: If three consecutive call rule violations are detected, a circuit breaker operation will be triggered. The circuit breaker operation includes clearing the WASM memory, destroying the front-end encryption key, and notifying the server through WebSocket to terminate the current session.

[0010] Furthermore, the full link verification in step S5 specifically includes the following steps: Step S51: Based on the specific business scenario, define the calling dependency relationship between the interfaces in detail; Step S52: The server maintains the session state machine and verifies the legitimacy of the request in real time based on the interface call graph when receiving a request. For requests not initiated in the order of the graph, such as directly calling the data query interface without logging in, the server will reject the request, effectively blocking the illegal request chain.

[0011] Furthermore, in step S8, the request content is dynamically encrypted and returned to the front end, specifically including the following steps: Step S81: The server generates a unique AES-GCM key for each session; Step S82: The sensitive API response data is encrypted using AES-GCM, and the ciphertext is returned together with the authentication tag; Step S83: The front end performs decryption through the WASM module.

[0012] Furthermore, in step S9, a real-time connection is established between the front-end and the server based on the WebSocket real-time channel, specifically including the following steps: Step E1: The front-end establishes a WebSocket connection, and the server immediately issues a device fingerprint collection instruction to complete device identity binding and initiate the session; Step E2: The call status of each atomic module on the front end is synchronized to the server in real time. The server promptly updates the interface call permissions based on the status information to ensure the consistency between the front end and the server and the legitimacy of the interface call. Step E3: Set the heartbeat period, and send a survival verification packet to the server according to the heartbeat period.

[0013] Furthermore, in step S9, defense is performed based on distributed circuit breaking control, specifically including the following steps: Step F1: When the server detects that the abnormal request rate of the same device fingerprint exceeds the set threshold, it automatically adds the device fingerprint to the blacklist and rejects all subsequent requests from the fingerprint; Step F2: The server sends a circuit breaker command to the front end via WebSocket; Step F3: After receiving the fuse instruction, the front end immediately triggers the memory cleanup operation and locks the interface.

[0014] The present invention discloses a Web application anti-debugging method based on dynamic code distribution and full-link verification, which has the following beneficial effects: First, through WASM modular execution and code loading technology, the core business logic is made "logically invisible" and the code is ensured to run in an isolated environment. At the same time, the front-end core technology business logic is divided into atomic modules by function, and the dependencies and calling order rules between modules are defined using directed acyclic graphs. The core code is processed with multi-layer obfuscation and encryption, which significantly increases the difficulty of reverse engineering and makes it difficult for attackers to restore the code logic. The WASM isolated execution environment prevents JavaScript from directly accessing memory, effectively protecting the security of core code and user data. Second, by setting execution time thresholds for adjacent functional units, a timeout triggers a circuit breaker mechanism, proactively blocking debug interrupts. This prevents the leakage of core code and user data, and prevents attackers from maliciously tampering with the code execution rhythm through debugging tools, thereby ensuring system stability. 3. Combining device fingerprints with dynamic tokens, using hardware features and real-time generated tokens to verify the legitimacy of request sources, ensuring the uniqueness and legitimacy of each request, completely blocking replay attacks, and significantly improving the legitimacy and accuracy of request sources. Fourth, by jointly verifying the interface call sequence in real time with the front-end and back-end, we can build a complete interface call graph, effectively blocking illegal request chains and reducing the risk of man-in-the-middle attacks. This ensures the security and integrity of web application data interactions and prevents attackers from bypassing verification through unnecessary requests. 5. Through the WebSocket real-time channel, status synchronization is performed during the communication process to prevent the separation of front-end and back-end protection and build an overall defense system; through the distributed circuit breaker mechanism, the impact of malicious attacks on the application is effectively prevented, improving the stability and security of the application. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 This is a framework diagram of the front-end and server-side in the present invention.

[0016] Figure 2 This is an interaction diagram between the front-end and the server in the present invention.

[0017] Figure 3 This is a flow chart of the front-end dynamic code protection in the present invention.

[0018] Figure 4 It is a directed acyclic graph of the module dependency graph in the present invention.

[0019] Figure 5 This is a flowchart of the code obfuscation encryption in the present invention.

[0020] Figure 6 This is an interactive diagram of the WASM dynamic loading execution in the present invention.

[0021] Figure 7 This is a flowchart of the server-side full-link verification in the present invention.

[0022] Figure 8 This is a flowchart of generating and verifying Token in the present invention. DETAILED DESCRIPTION

[0023] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0024] like Figure 1 and 2 The web application anti-debugging method shown here is based on dynamic code distribution and full-link verification. This anti-debugging technology is a comprehensive technical system designed to prevent or interfere with reverse analysis and debugging operations targeting web application logic through a series of technical means such as code protection, environment monitoring, and request verification. It specifically includes the following steps: Step S1: Figure 3-Figure 6 As shown, the front-end core code is divided according to the functional cohesion rules and low coupling principles to obtain several atomic modules, and a module dependency graph is constructed to perform dynamic code distribution and protection; ensuring that each atomic module can be loaded and executed independently and on demand, improving the flexibility and security of the code, and overcoming the problem that the control flow in traditional code is easily restored; several atomic modules include a data encryption module and a user authentication module, and use acyclic graphs to clearly define the dependencies and call sequence rules between modules; as shown in the figure, data flows from module A to modules B and C, and after being processed by module B, part of the data goes to module C and part of the data goes to module D; this embodiment provides a module dependency graph for constructing a payment process, and calls the modules in sequence according to the identity authentication module, order generation module, and payment confirmation module. If the payment confirmation module is called directly without completing the identity authentication, the system will immediately trigger an exception to ensure the correct execution of the business logic. Specifically, the following steps are included: Step S11: Conduct a comprehensive analysis of the functional requirements of the Web application, that is, clarify the responsibilities and boundaries of each atomic module. For example, the responsibility of the order generation module is to obtain product information and generate orders based on this information, but does not include the order payment function; the responsibility of the payment confirmation module is to obtain order information and call payment, but does not include the order generation function. Step S12: Based on the functional requirements analysis results obtained in step S11, the web application is divided into several independent atomic modules, and each atomic module has clear input and output to facilitate subsequent development and testing. For example, the input of the order generation module is product information, and the output is a completed order, including related product information and price. Step S13: Conduct detailed design for each atomized module, including module interface definition, internal logical structure, and data processing flow. The design process should fully consider the module's scalability and maintainability. Step S14: Module coding is performed according to the design to ensure that the functional implementation of each atomized module meets the actual requirements; during the coding process, some technical means are used to increase the difficulty of reverse engineering, such as code obfuscation and encryption; Step S15: Perform unit testing and comprehensive testing on each atomized module to ensure the functional correctness and stability of each atomized module, and pay attention to the interface interaction and data transmission between modules during the comprehensive testing process. Among them, a time window constraint mechanism is set between each atomic module, and an execution time threshold Δt of adjacent functional units is set, Δt≤500ms; in actual operation, if module A is executed and if the call of module B is not triggered for more than a certain time, which is 10 seconds in this embodiment, the system will determine that there may be a debugging interrupt operation, and then trigger the fuse mechanism; this time window constraint mechanism can effectively monitor and prevent attackers from maliciously tampering with the code execution rhythm through debugging tools, actively defend against debugging interruption behavior, overcome the problem that debugging detection is easy to bypass in the existing technology, and ensure the stability of system operation.

[0025] Dynamic code distribution is a model for code delivery that finely divides the core business logic code of a Web application into several encrypted modules. These modules are dynamically loaded from the server and executed after the verification process is completed.

[0026] Step S2: Obfuscating the segmented core code based on JavaScript Obfuscato and encrypting it. This combination of multiple layers of obfuscation and encryption overcomes the limitation of traditional tools that only achieve surface obfuscation, significantly improving reverse engineering costs. Obfuscate the split core code, which includes the following steps: Step A1: Convert the original sequential execution logic into a Switch-Case structure and insert several useless branches to interfere with the attacker's reverse analysis and flatten the control flow. The Switch-Case structure is a multi-branch selection control structure. Step A2: Encrypt the plaintext string, convert it into Unicode encoding or Hex array, and dynamically restore it when the program is running; Step A3: insert a conditional branch that is never executed to increase the complexity of code static analysis; in this embodiment, if (0) is inserted.

[0027] Encrypting the split core code includes the following steps: Step B1: Encrypt the obfuscated code using the AES-256-GCM symmetric encryption algorithm to ensure confidentiality and integrity. The AES-256-GCM symmetric encryption algorithm is a symmetric encryption scheme that combines encryption and integrity verification. The 256-bit key version of the AES symmetric encryption algorithm uses a 256-bit key to encrypt data, providing high security. The GCM mode ensures confidentiality, integrity, and authenticity verification.

[0028] Step B2: Encrypt the AES key using the RSA-OAEP algorithm and embed the public key in the WASM module, effectively preventing key leakage. The RSA-OAEP algorithm combines the RSA public key encryption algorithm with OAEP optimal asymmetric encryption padding. This algorithm addresses the security flaws inherent in the deterministic nature of native RSA encryption and meets higher security requirements. A WASM module, or WebAssembly module, is a binary instruction format-based program designed for efficient execution and secure sandboxing, running in browsers and server environments.

[0029] Step S3: Based on Fingerprint JS, hardware features are collected, and device fingerprints are regularly generated and bound to the Token. The fingerprints are compared with the server-side historical records to determine whether there are any abnormalities, which are used for server-side call uniqueness verification. In this embodiment, a device fingerprint is generated every 30 minutes and compared with the server-side historical records. If the difference exceeds 10%, it is determined to be abnormal, which improves the legitimacy verification of the request source and overcomes the problem that the static Token mechanism is susceptible to replay attacks. Fingerprint JS is a browser fingerprint recognition JavaScript library used to anonymously identify user devices. The dimensions of hardware features include Canvas fingerprint, WebGL fingerprint, and audio fingerprint. The specific data of the Canvas fingerprint dimension is the 2D Canvas rendering grayscale image pixel matrix, which is hashed using the SHA-3-256 algorithm to obtain a fixed hash value. The specific data of the WebGL fingerprint dimension is the WebGL renderer version and extension support list, which is hashed using the MurmurHash algorithm to obtain a fixed hash value. The specific data of the audio fingerprint dimension is the AudioContext frequency response characteristics, which is hashed using the xxHash64 algorithm to obtain a fixed hash value.

[0030] Binding the device fingerprint to the token involves the following steps: Step S31: Collect various hardware feature information of the device; Step S32: Process the collected hardware feature information, concatenate the hash values ​​of multiple hardware feature information, and perform a hash operation again to generate a unique device fingerprint; Step S33: Generate original data by combining the device fingerprint, timestamp, and random number. The original data is signed using the HMAC-SHA256 algorithm and bound to the session validity period. In this embodiment, the timestamp is set to 60 seconds, generating a dynamic token with device fingerprint information that is unique and time-sensitive. The HMAC-SHA256 algorithm is a key-based hash message authentication code algorithm used to provide data integrity verification and identity verification. Step S34: The server verifies and parses the token to obtain the device fingerprint in the original data; Step S35: Compare the device fingerprint of the current device with the device fingerprint in the Token in step S34 to see if they are consistent; if the two are consistent, perform Token signature verification; if the two are inconsistent, trigger an exception.

[0031] Step S4: The split, encrypted, and obfuscated core code is dynamically loaded and executed through WASM, and memory protection and a fuse mechanism are implemented to ensure that the core code and user data are not leaked when the Web application is attacked. Dynamic loading and execution through WASM includes the following steps: Step C1: Use the Rust language to write module call verification logic and compile it into a WASM module using the wasm-pack tool. WASM modules have high performance and good security, and can provide a reliable environment for code execution. Step C2: The front-end initiates a module request, carrying the current device fingerprint and call context; Step C3: After verifying the legitimacy of the request, the server returns the module code encrypted with AES-256-GCM and the key encrypted with RSA-OAEP; Step C4: After the WASM module decrypts and verifies the code integrity, it is dynamically executed through the Function constructor. Through WASM modular execution and real-time code loading, "logic invisibility" is achieved. The WASM module isolates the execution environment, overcomes the security risks of direct JavaScript memory access, and significantly reduces reverse engineering costs.

[0032] Memory protection and fuse mechanism are implemented, including the following steps: Step D1: Use WebAssembly.Memory to independently allocate memory space for the WASM module, prohibiting JavaScript from directly accessing this memory area. The WASM module itself controls the memory growth operation memory.grow, effectively preventing illegal memory access in the JavaScript environment and protecting the security of core code and user data. Step D2: If three consecutive call rule violations are detected, a circuit breaker defense operation will be triggered. The circuit breaker defense operation includes clearing WASM memory, destroying the front-end encryption key, and notifying the server through WebSocket to terminate the current session, thereby blocking the attack in a timely manner and preventing data leakage and further spread of malicious operations. Through active defense, the lag of passive detection in existing technologies is overcome, effectively preventing the leakage of core code and user data.

[0033] Step S5: Figure 7 、 8 As shown, the server builds an interface call graph based on the business logic. When receiving a request, the server verifies the call graph in sequence and performs full-link verification. The specific steps include: Step S51: Based on the specific business scenario, define the calling dependency relationship between the interfaces in detail; for example, {"API1 (login)":["API2 (get permissions)","API3 (query data)"],"API2":["API4 (submit operation)"],"API3":[]}; Step S52: The server maintains the session state machine and verifies the legitimacy of the request in real time based on the interface call graph when receiving a request. For requests that are not initiated in the order of the graph, such as directly calling the data query interface without logging in, the server will reject the request and effectively block the illegal request chain. The call order is enforced to overcome the disorder problem of isolated interface verification and block the illegal request chain.

[0034] Full-link verification is a protection mechanism that implements joint verification from multiple dimensions, such as code execution order, interface calling rules, and device identity characteristics, throughout the entire request lifecycle from the front-end initiation to the server-side response, to ensure the security and legitimacy of the entire link.

[0035] Step S6: The server obtains the device fingerprint; Step S7: Bind the device fingerprint to a unique token, and dynamically generate and verify the token when accepting the request to ensure the legitimacy of the call of the same device fingerprint; The device fingerprint is bound to a unique token for verification, which includes the following steps: Step S71: The device fingerprint is associated with the dynamic token. When the server receives a request, it checks whether the device fingerprint in the request matches the token. If they do not match, the request is rejected to ensure the legitimacy of the request source and prevent access by unauthorized devices. This overcomes the vulnerability of static tokens to replay attacks and ensures the legitimacy of the request source. Step S72: Generate original data by combining the device fingerprint, timestamp, and random number, sign the original data using the HMAC-SHA256 algorithm, and bind the session validity period; for example, set the session validity period to 60 seconds to generate a dynamic token with uniqueness and timeliness; Step S73: The front-end obtains the token within the validity period of the session through WebSocket and carries the token in each API request; Step S74: After receiving the request, the server verifies the consistency of the Token signature, timestamp, and device fingerprint; Step S75: The token becomes invalid immediately after use, effectively preventing replay attacks. This token's one-time validity mechanism can overcome the risk of replay attacks and ensure the uniqueness and legitimacy of each request. Step S8: Dynamically encrypt the request content and return it to the front end, which decrypts it to ensure the security of the data during transmission. The dynamic encryption of the request content and its return to the front end specifically includes the following steps: Step S81: The server generates a unique AES-GCM key for each session; Step S82: The sensitive API response data is encrypted using AES-GCM, and the ciphertext is returned together with the authentication tag; Step S83: The front-end performs decryption through the WASM module to ensure that the key is not exposed to the JavaScript environment; the key isolation mechanism overcomes the risk of key leakage in the existing technology and ensures data security during transmission.

[0036] Step S9: Real-time connection between the front-end and the server is established based on a WebSocket or HTTPS real-time channel, and defense is provided based on distributed circuit breaker control. Identity information, request call information, and call permission information are synchronized in real time during the real-time connection process. From the moment the browser opens the Web application to the moment the browser window closes, self-protection against attacks is provided through real-time verification, heartbeat mechanisms, and circuit breaker mechanisms. This embodiment establishes a real-time connection between the front-end and the server based on the WebSocket real-time channel, specifically including the following steps: Step E1: The front-end establishes a WebSocket connection, and the server immediately issues a device fingerprint collection instruction to complete device identity binding and initiate a session, laying the foundation for subsequent communication and verification. Step E2: The call status of each atomic module on the front end is synchronized to the server in real time. The server promptly updates the interface call permissions based on the status information to ensure the consistency between the front end and the server and the legitimacy of the interface call. Step E3: Set the heartbeat period, and send a survival verification packet to the server according to the heartbeat period. In this embodiment, the heartbeat period is 15 seconds, which ensures the active state of the connection, detects connection anomalies in time, and ensures the stability of communication; real-time communication and status synchronization overcome the problem of front-end and back-end protection separation in the existing technology, and builds an overall defense system.

[0037] Defense is based on distributed circuit breaking control. Distributed circuit breaking includes server-side circuit breaking and front-end circuit breaking. Specifically, it includes the following steps: Step F1: When the server detects that the abnormal request rate of the same device fingerprint exceeds the set threshold, it automatically adds the device fingerprint to the blacklist and rejects all subsequent requests from this fingerprint, effectively preventing malicious requests from continuously attacking the system. In this embodiment, the threshold is set to 5 times / minute, which means the server-side circuit breaker is activated. Step F2: The server sends a circuit breaker instruction to the front-end through WebSocket, thus performing a circuit breaker operation on the front-end. Step F3: After the front-end receives the fuse instruction, it immediately triggers the memory cleanup operation and locks the interface, preventing the attack from spreading further and protecting the security of the front-end environment. Through distributed fuse control, the impact of malicious attacks on the application is effectively prevented, improving the stability and security of the application.

[0038] The present invention relies on the close collaboration between the front-end and the server-side, deeply integrates the front-end dynamic code protection mechanism and the server-side full-link verification mechanism, and is achieved with the help of the front-end and back-end collaborative protection system, and is based on dynamic code distribution and full-link verification technology. The front-end dynamic code protection mechanism uses modular segmentation and layered encryption technology, combined with the WebAssembly module dependency graph for dynamic loading, to build a front-end code anti-reverse technology system; it focuses on obfuscating and encrypting the JavaScript and WebAssembly modules running on the front end, so as to improve the security and confidentiality of the code. The server-side full-link verification mechanism is based on the interface call graph, device fingerprint binding and dynamic Token verification technology to achieve accurate verification of the legitimacy of server-side requests; by using dynamic Token verification technology and device fingerprint binding and other technical means, the legitimacy of the interface requests received by the server is verified to ensure that the request source is reliable and the operation is compliant. The front-end and back-end collaborative protection system uses the real-time communication channel WebSocket to achieve real-time synchronization of execution status and verification results. Based on the module dependency graph and interface call graph, it can quickly handle abnormal operations and accurately trace the source. It uses WebSocket to achieve real-time communication between the front-end and back-end, and builds an abnormal circuit breaker mechanism based on this to achieve the goal of front-end and back-end collaborative defense.

[0039] With dynamic code distribution and full-link verification as the core technologies, combined with a variety of advanced technical means such as module dependency graph, interface call graph constraints, dynamic token and device fingerprint binding, it significantly improves the difficulty of code reverse engineering, can intercept illegal requests, and builds a comprehensive, multi-level integrated defense method for Web applications, effectively ensuring the overall security of Web applications and meeting the growing security needs of Web applications.

[0040] The above embodiments are not limitations of the present invention, and the present invention is not limited to the above examples. Any changes, modifications, additions or substitutions made by technicians in this technical field within the scope of the technical solution of the present invention also fall within the scope of protection of the present invention.

Claims

1. A web application anti-debugging method based on dynamic code distribution and full-link verification, characterized by: The following steps are involved: Step S1: Split the front-end core code according to the functional cohesion rules and low coupling principles to obtain several atomic modules that can be loaded and executed independently on demand. Build a module dependency graph to perform dynamic code distribution and protection. Among them, a time window constraint mechanism is set between each atomic module; Step S2: Obfuscate and encrypt the segmented core code based on JavaScript Obfuscato; Step S3: Collect hardware features based on Fingerprint JS, generate device fingerprints regularly and bind them to Token; Step S4: Dynamically load and execute the split, encrypted, and obfuscated core code through WASM to perform memory protection and fuse mechanism protection; Step S5: The server constructs an interface call graph based on the business logic. When receiving a request, the server verifies the call graph in sequence and performs full-link verification. Step S6: The server obtains the device fingerprint; Step S7: The server generates and verifies a dynamic token when receiving the request; Step S8: Dynamically encrypt the request content and return it to the front end, which decrypts it; Step S9: Establish a real-time connection between the front-end and the server based on the WebSocket real-time channel, and perform defense based on distributed circuit breaker control.

2. The web application anti-debugging method based on dynamic code distribution and full-link verification according to claim 1 is characterized in that: The step S1 performs dynamic code distribution and protection, specifically including the following steps: Step S11: Conduct a comprehensive analysis of the functional requirements of the Web application; Step S12: Based on the functional requirement analysis results obtained in step S11, the Web application is divided into several independent atomic modules, each of which has clear inputs and outputs; Step S13: Detailed design of each atomization module; Step S14: Module coding is performed according to the design to ensure that the functional implementation of each atomized module meets actual requirements; Step S15: Perform unit detection and comprehensive testing on each atomized module.

3. The web application anti-debugging method based on dynamic code distribution and full-link verification according to claim 2 is characterized in that: In step S2, the segmented core code is obfuscated, specifically comprising the following steps: Step A1: Convert the original sequential execution logic into a Switch-Case structure and insert several useless branches to flatten the control flow; Step A2: Encrypt the plaintext string; Step A3: Insert a conditional branch that is never executed; In step S2, the divided core code is encrypted, which specifically includes the following steps: Step B1: Encrypt the obfuscated code using the AES-256-GCM symmetric encryption algorithm; Step B2: Encrypt and transmit the AES key based on the RSA-OAEP algorithm, and embed the public key into the WASM module to effectively prevent key leakage.

4. The web application anti-debugging method based on dynamic code distribution and full-link verification according to claim 3 is characterized in that: In step S3, the device fingerprint is bound to the token, specifically including the following steps: Step S31: Collect various hardware feature information of the device; Step S32: Process the collected hardware feature information, concatenate the hash values ​​of multiple hardware feature information, perform hash calculation again, and generate a unique device fingerprint; Step S33: Generate original data by combining the device fingerprint, timestamp, and random number; and use the HMAC-SHA256 algorithm to sign the original data and bind it to the session validity period; Step S34: The server verifies and parses the token to obtain the device fingerprint in the original data; Step S35: Compare the device fingerprint of the current device with the device fingerprint in the Token in step S34 to see if they are consistent; if the two are consistent, perform Token signature verification; if the two are inconsistent, trigger an exception.

5. The web application anti-debugging method based on dynamic code distribution and full-link verification according to claim 4 is characterized in that: The step S4 is dynamically loaded and executed by WASM, specifically including the following steps: Step C1: Use the Rust language to write module call verification logic and compile it into a WASM module using the wasm-pack tool; Step C2: The front-end initiates a module request, carrying the current device fingerprint and call context; Step C3: After verifying the legitimacy of the request, the server returns the module code encrypted with AES-256-GCM and the key encrypted with RSA-OAEP; Step C4: The WASM module decrypts and verifies the code integrity, and dynamically executes it through the Function constructor.

6. The web application anti-debugging method based on dynamic code distribution and full-link verification according to claim 5 is characterized in that: The memory protection and fuse protection are performed in step S4, specifically including the following steps: Step D1: Use WebAssembly.Memory to independently allocate memory space for the WASM module and prohibit JavaScript from directly accessing this memory area; Step D2: If three consecutive call rule violations are detected, a circuit breaker operation will be triggered. The circuit breaker operation includes clearing the WASM memory, destroying the front-end encryption key, and notifying the server through WebSocket to terminate the current session.

7. The web application anti-debugging method based on dynamic code distribution and full-link verification according to claim 6 is characterized in that: The full link verification in step S5 specifically includes the following steps: Step S51: Based on the specific business scenario, define the calling dependency relationship between the interfaces in detail; Step S52: The server maintains the session state machine and verifies the legitimacy of the request in real time based on the interface call graph when receiving a request. For requests not initiated in the order of the graph, such as directly calling the data query interface without logging in, the server will reject the request, effectively blocking the illegal request chain.

8. The web application anti-debugging method based on dynamic code distribution and full-link verification according to claim 7 is characterized in that: The request content is dynamically encrypted and returned to the front end in step S8, specifically including the following steps: Step S81: The server generates a unique AES-GCM key for each session; Step S82: The sensitive API response data is encrypted using AES-GCM, and the ciphertext is returned together with the authentication tag; Step S83: The front end performs decryption through the WASM module.

9. The web application anti-debugging method based on dynamic code distribution and full-link verification according to claim 8 is characterized in that: In step S9, the real-time connection between the front-end and the server is performed based on the WebSocket real-time channel, which specifically includes the following steps: Step E1: The front-end establishes a WebSocket connection, and the server immediately issues a device fingerprint collection instruction to complete device identity binding and initiate the session; Step E2: The call status of each atomic module on the front end is synchronized to the server in real time. The server promptly updates the interface call permissions based on the status information to ensure the consistency between the front end and the server and the legitimacy of the interface call. Step E3: Set the heartbeat period, and send a survival verification packet to the server according to the heartbeat period.

10. The web application anti-debugging method based on dynamic code distribution and full-link verification according to claim 9 is characterized in that: The defense based on distributed fuse control in step S9 specifically includes the following steps: Step F1: When the server detects that the abnormal request rate of the same device fingerprint exceeds the set threshold, it automatically adds the device fingerprint to the blacklist and rejects all subsequent requests from the fingerprint; Step F2: The server sends a circuit breaker command to the front end via WebSocket; Step F3: After receiving the fuse instruction, the front end immediately triggers the memory cleanup operation and locks the interface.

Images