Browser-side data processing method and device, and electronic equipment

Abstract

The application provides a browser-side data processing method and device and electronic equipment, and relates to the field of data processing. The method comprises the following steps: generating an initialized symmetric working key through a corresponding backend of a browser side; in response to the start of a client-side Web application, transmitting a key request to a corresponding frontend of the browser side, and when the backend receives the key request, encrypting the symmetric working key through an RSA asymmetric encryption algorithm to generate encrypted key ciphertext, and transmitting the key ciphertext to the frontend; in response to the frontend receiving the key ciphertext, decrypting the key through the RSA decryption logic built in the frontend to obtain a usable symmetric working key; storing the usable symmetric working key in the memory of the frontend through a Memory-only pure memory storage mode; constructing a memory isolation sandbox through a WeakMap feature, and binding the usable symmetric working key to an independent context of a window object of the frontend.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a browser-side data processing method, apparatus, and electronic device. Background Technology

[0002] Currently, regarding the security status of local storage, modern web applications widely use browser-side storage (such as localStorage) to store sensitive data such as user preferences and session state. Because this data is directly exposed to the user's client environment, users or third-party plugins can bypass application logic and directly modify the stored data. Therefore, browser-side data is easily subject to malicious tampering. Summary of the Invention

[0003] The purpose of this application is to provide a browser-side data processing method, apparatus, and electronic device to solve the technical problem that browser-side data is easily maliciously tampered with.

[0004] Firstly, this application provides a browser-side data processing method, the method comprising: An initial symmetric working key is generated through the backend corresponding to the browser client; In response to the launch of the client web application, a key request is transmitted to the front end corresponding to the browser. When the back end receives the key request, the symmetric working key is encrypted using the RSA asymmetric encryption algorithm to generate encrypted key ciphertext, and the key ciphertext is transmitted to the front end. In response to the front end receiving the key ciphertext, the front end decrypts the key using its built-in RSA decryption logic to obtain a usable symmetric working key; the RSA decryption logic matches the back end's RSA private key. The available symmetric working key is stored in the memory of the front end in a memory-only pure memory storage mode to prevent the available symmetric working key from being written to any disk-level storage medium other than the memory of the front end; A memory-isolated sandbox is constructed using the WeakMap feature, and the available symmetric working key is bound to an independent context of the front-end window object, so that the available symmetric working key is only invoked within the specified application execution context.

[0005] In one possible implementation, after storing the available symmetric working key in the front-end's memory using a memory-only pure memory storage mode, the method further includes: Set the key validity period of the available symmetric working key to a first specified duration; In response to a second specified time period before the available symmetric working key reaches the corresponding period of the first specified time period, a new key request is automatically transmitted from the front end to the back end to complete the seamless key rotation update; the first specified time period is longer than the second specified time period. In response to the front end detecting abnormal access behavior, an emergency key update is triggered, and an abnormal identifier is sent to the back end through the front end. The back end then regenerates a dedicated symmetric working key based on the abnormal identifier, encrypts and distributes the dedicated symmetric working key, and invalidates the original key of the usable symmetric working key. The abnormal access behavior includes at least one of the following: consecutive signature verification failures, unauthorized modification of stored data, and XSS attack alarm.

[0006] In one possible implementation, before storing the available symmetric working key in the memory of the front end via a memory-only pure memory storage mode, the method further includes: The available symmetric working key is identified as the data to be stored; In response to detecting that the data to be stored is not in JSON format, the data to be stored is converted into a standard JSON key-value pair data structure to obtain JSON data; Sort all keys in the JSON data according to a specified sorting method and fix the key-value pair order to obtain sorted data. Remove all redundant and invalid characters from the sorted data and unify the data type format to obtain standardized JSON data. Add a dedicated timestamp field to the standardized JSON data; the timestamp in the timestamp field corresponds to the current system time of the client. The key name of the timestamp field is fixed, and the fixed key name is concatenated with the standardized JSON data to form the complete data to be signed; the timestamp serves as the verification basis for subsequent anti-replay attacks and participates in the signature calculation, so that the signatures generated by the same data at different times are completely different; The corresponding HMAC hash algorithm is determined based on the security level of the data to be signed, and the signature is calculated using the corresponding HMAC hash algorithm to obtain the signature calculation result. The security level includes regular non-sensitive data, and the HMAC hash algorithm corresponding to the regular non-sensitive data is the HMAC-SHA256 algorithm. The signature calculation using the corresponding HMAC hash algorithm to obtain the signature calculation result includes: using the available symmetric working key in the front-end memory as the first key parameter and the complete data to be signed as the first message parameter in the front-end memory using the HMAC-SHA256 algorithm; performing hash calculation based on the first key parameter and the first message parameter using the HMAC-SHA256 algorithm to generate a 256-bit binary signature value; and converting the 256-bit binary signature value into a hexadecimal string to obtain the final regular data signature. The security level includes critical sensitive data, and the HMAC hash algorithm corresponding to the critical sensitive data is the HMAC-SHA512 algorithm. The signature calculation using the corresponding HMAC hash algorithm to obtain the signature calculation result includes: in the front-end memory, the HMAC-SHA512 algorithm calculation logic is consistent with that of regular data to generate a 512-bit binary signature value, and the 512-bit binary signature value is converted into a hexadecimal string to obtain a sensitive data signature with a higher than the specified high security level.

[0007] In one possible implementation, after removing all redundant and invalid characters from the sorted data and unifying the data type format to obtain standardized JSON data, the following steps are also included: The standardized JSON data is encrypted using the AES-GCM-256 symmetric encryption algorithm, and the hardware fingerprint abbreviation of the client is used as an additional parameter of AAD during the encryption process to bind the ciphertext to the hardware environment of the client. The encryption process generates ciphertext data and an authentication tag. The ciphertext data is then converted into a Base64 encoded string to obtain the encrypted Base64 ciphertext data. The encrypted Base64 ciphertext data, the signature calculation result, and the timestamp are assembled to generate ternary structured data; The ternary structured data is converted into a standard JSON string, and then written into a specified storage key using the browser's localStorage's setItem method on the browser side; the storage key is defined according to business requirements.

[0008] In one possible implementation, it also includes: In response to the startup of the client web application, the front-end initializes the key request unit and the data processing unit, and sends a target key request to the back-end key service unit. The target key request carries the client's unique identifier and hardware fingerprint abbreviation. The key service unit verifies the legitimacy of the unique identifier, assigns a dedicated 2048-bit RSA public key to the client, extracts the 256-bit symmetric working key of the current batch, encrypts the 256-bit symmetric working key with the RSA public key, and generates the target key ciphertext. The backend sends the RSA public key and the target key ciphertext to the frontend via an HTTPS link. The target key ciphertext is decrypted using the RSA decryption logic at the front end to obtain the target symmetric working key. The target symmetric working key is then stored in a memory-only sandbox to complete key initialization. The system obtains the original data to be stored from the business layer through the front end, performs standardized preprocessing on the original data to obtain standardized original data, encrypts the standardized original data with AES-GCM-256 to generate Base64 encoded target ciphertext data, embeds a millisecond-level timestamp into the standardized original data to obtain timestamped data, concatenates the target ciphertext data and the timestamped data to obtain target data to be signed, selects the HMAC-SHA256 / HMAC-SHA512 algorithm according to the data security level, uses the target symmetric working key in memory as the key to perform signature calculation on the target data to be signed to generate a hexadecimal signature string, assembles the target ciphertext data, the signature string and the timestamped data into a ternary structured JSON data, converts the ternary structured JSON data into a target string and writes it to localStorage with a specified key name to complete data storage.

[0009] In one possible implementation, after converting the ternary structured JSON data into a string and writing it to localStorage with the specified key name to complete data storage, the method further includes: The front end uses the getItem method of localStorage to read the target string with the specified key name, parses the target string into a structured data object, obtains the current system's millisecond-level timestamp, and calculates the time difference between the current time and the storage time; the time difference is the current timestamp of the current time minus the timestamp value corresponding to the storage time. In response to the time difference being greater than the preset maximum valid duration, the target string is determined to have failed the timestamp validity verification, and a tampering response strategy is triggered to clear the abnormal data; In response to the time difference being less than or equal to the preset maximum valid duration, the target string is determined to have passed the timestamp validity verification, and the HMAC signature integrity verification process is executed; During the HMAC signature integrity verification process, the front end extracts the data and timestamp fields from the ternary structured JSON data corresponding to the target string, embeds the timestamp into an empty standardized JSON structure, generates a data structure to be signed that is consistent with the storage time, extracts the currently valid symmetric working key from the memory isolation sandbox, selects the HMAC-SHA256 / HMAC-SHA512 algorithm consistent with the storage time according to the data security level, and recalculates the signature using the HMAC-SHA256 / HMAC-SHA512 algorithm. During the recalculation of the signature, the symmetric working key is used as the second key parameter and the concatenated data to be signed is used as the second message parameter. A new hexadecimal signature string is generated based on the second key parameter and the second message parameter. The new hexadecimal signature string is compared bit by bit with the sign field in the ternary structured JSON data. If any bit of the comparison result is different, the signature verification is determined to be unsuccessful, the data is determined to be actively tampered with, and the tampering response strategy is triggered. If the comparison result is completely consistent, the signature verification is determined to be successful, and the AES-GCM-256 data decryption verification process is executed. During the AES-GCM-256 data decryption verification process, the front end extracts the data field from the ternary structured JSON data, performs Base64 decoding on the data field to obtain the original ciphertext encrypted by AES-GCM-256, extracts the symmetric working key from memory, obtains the hardware fingerprint abbreviation of the current client, and uses the AES-GCM-256 decryption algorithm to decrypt the original ciphertext, while verifying the legality of the authentication tag during the decryption process; If the decryption process proceeds without errors and restores the original data in standard JSON format, the decryption verification is considered successful, and the restored original data is returned to the business layer to complete the entire data reading verification process. If the decryption process encounters an error, the decryption verification is considered unsuccessful, and a tampering response policy is triggered.

[0010] In one possible implementation, it also includes: For the handling of the abnormal data, a silent cleanup operation is performed on the three-element structured JSON data that fails any one of the verifications. The abnormal data is deleted by using the removeItem method of localStorage to prevent the abnormal data from being called by the business layer, and the signature cache corresponding to the abnormal data is cleared to prevent cache pollution. The tampering event is logged, and the log entries include at least one of the following: the time of the tampering event, the stored data key name, the verification failure type, the client hardware fingerprint, the current key version, the time difference corresponding to the failure of the timestamp validity verification, and the signature comparison difference bit; the log data is encrypted using AES-GCM and stored in the temporary memory of the front end. The key log information of the tampering event is encrypted and reported to the backend monitoring platform via HTTPS protocol, so that the monitoring platform can perform real-time alerts and statistics based on the key log information; the reported data includes at least one of the following: event unique identifier, failure type, and occurrence time; If the determination is that the signature verification or decryption fails, the symmetric working key in the memory of the current front-end is cleared, and the key emergency update process is triggered to apply for a new symmetric working key from the front-end. At the same time, all signature caches of the front-end are cleared and the verification environment is reinitialized. If the same client fails to sign or decrypt more than a specified number of times within a third specified time period, it is determined to be a high-risk tampering attack, and a user identity re-authentication process is triggered. The local business operation permissions of the client corresponding to the current user are frozen until the current user completes mobile phone verification code, SMS verification or biometric verification. After successful verification, the permissions are restored and the key is reissued.

[0011] Secondly, this application provides a browser-side data processing apparatus, comprising: The generation module is used to generate an initialized symmetric working key through the backend corresponding to the browser client; An encryption module is used to respond to the startup of a client web application by transmitting a key request to the front end corresponding to the browser, and when the back end receives the key request, encrypting the symmetric working key using the RSA asymmetric encryption algorithm to generate encrypted key ciphertext, and transmitting the key ciphertext to the front end. The decryption module is used to respond to the front end receiving the key ciphertext, and to decrypt the key using the RSA decryption logic built into the front end to obtain a usable symmetric working key; the RSA decryption logic is matched with the RSA private key of the back end; A storage module is used to store the available symmetric working key in the memory of the front end in a memory-only pure memory storage mode to prevent the available symmetric working key from being written to any disk-level storage medium other than the memory of the front end. The binding module is used to build a memory isolation sandbox through the WeakMap feature and bind the available symmetric working key to the independent context of the front-end window object so that the available symmetric working key is only invoked within the specified application execution context.

[0012] Thirdly, this application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the method described in the first aspect above.

[0013] Fourthly, this application also provides a computer-readable storage medium storing computer-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method described in the first aspect above.

[0014] This application brings the following beneficial effects: This application provides a browser-side data processing method, apparatus, and electronic device, capable of generating an initial symmetric working key through a backend corresponding to the browser; in response to the startup of a client web application, transmitting a key request to a frontend corresponding to the browser; and when the backend receives the key request, encrypting the symmetric working key using an RSA asymmetric encryption algorithm to generate encrypted key ciphertext, and transmitting the key ciphertext to the frontend; in response to the frontend receiving the key ciphertext, decrypting the key using the frontend's built-in RSA decryption logic to obtain a usable symmetric working key; the RSA decryption logic matching the backend's RSA private key; storing the usable symmetric working key in the frontend's memory using a memory-only pure memory storage mode to prevent the usable symmetric working key from being written to any disk-level storage medium other than the frontend's memory; constructing a memory isolation sandbox using the WeakMap feature, and binding the usable symmetric working key to the independent context of the frontend's window object, so that the usable symmetric working key is only invoked within the specified application execution context; in this solution, asymmetric encryption is used for key transmission and the backend uses RSA... The public key encrypts the symmetric working key, and the decrypted key is stored only in pure memory. By constructing a memory isolation sandbox through WeakMap and binding the key to a specified application execution context, the key cannot be illegally obtained by XSS attack scripts and memory extraction tools. Through RSA encrypted transmission combined with memory-only memory storage, the traditional method of static hard-coding keys on the front end is completely abandoned. Instead, a dynamic key generation and management mechanism with backend distribution, RSA encrypted transmission, and memory-isolated storage is adopted, achieving a balance between key timeliness, security, and availability. This solves the single point of failure problem of the key, thereby preventing browser-side data from being tampered with and solving the technical problem that browser-side data is easily maliciously tampered with.

[0015] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 A schematic flowchart illustrating the browser-side data processing method provided in this application embodiment; Figure 2 Another flowchart illustrating the browser-side data processing method provided in this application embodiment; Figure 3 A schematic diagram of the browser-side data anti-tampering data storage process based on HMAC signature in the browser-side data processing method provided in the embodiments of this application; Figure 4 In the browser-side data processing method provided in the embodiments of this application, there is a browser-side data anti-tampering data reading verification process based on HMAC signature; Figure 5 This application provides a schematic diagram of the structure of a browser-side data processing device according to an embodiment of the present application. Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] The terms "comprising" and "having," and any variations thereof, used in the embodiments of this application, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0020] Currently, browser-side data still faces the risk of data forgery due to attackers spoofing high-privilege configurations or bypassing business rules, as well as a lack of trust issues stemming from the front-end's lack of reliable mechanisms to verify data integrity.

[0021] For existing protection solutions: 1. Data encryption: Using algorithms such as AES to encrypt and store data; drawback: the encryption key needs to be stored on the front end, making it vulnerable to reverse engineering. 2. HTTP-only cookies: storing sensitive data in cookies managed by the server; drawback: unable to store complex data structures, increasing server load. 3. Data obfuscation: performing Base64 encoding or simple transformation on the stored data; drawback: low protection level, easily detected.

[0022] Therefore, existing technologies have the following drawbacks: 1. Conflict between security and convenience: Strong security solutions require frequent server-side verification requests, reducing user experience; weak protection solutions cannot withstand targeted attacks. 2. Key management deficiencies: Encryption keys stored on the front end become a single point of failure. 3. Lack of data integrity: Existing solutions lack lightweight data tampering detection mechanisms.

[0023] Based on this, embodiments of this application provide a browser-side data processing method, apparatus, and electronic device, which can solve the technical problem that browser-side data is easily maliciously tampered with.

[0024] The embodiments of this application will be further described below with reference to the accompanying drawings.

[0025] Figure 1 This is a flowchart illustrating a browser-side data processing method provided in an embodiment of this application. Figure 1 As shown, the method includes: Step S110: Generate an initial symmetric working key through the backend corresponding to the browser.

[0026] In one possible implementation, for the initial generation of backend keys, for example, a dedicated key service module is deployed on the backend to generate a batch of symmetric working keys (256-bit random keys adapted to AES-GCM-256 and HMAC algorithms) every 2 hours. At the same time, a unique RSA public / private key pair (2048-bit RSA asymmetric encryption algorithm) is assigned to each client session. The RSA private key is securely stored on the backend, and the RSA public key is sent to the frontend when the client session is established.

[0027] In step S120, in response to the startup of the client web application, a key request is transmitted to the corresponding front-end on the browser side. When the back-end receives the key request, the symmetric working key is encrypted using the RSA asymmetric encryption algorithm to generate encrypted key ciphertext, which is then transmitted to the front-end.

[0028] For front-end key requests and encrypted transmission, for example, when the client web application starts, it sends a key request to the front-end key service module. After receiving the request, the back-end encrypts the symmetric working key of the current batch using the RSA asymmetric encryption algorithm (using the corresponding client's RSA public key) to generate the encrypted key ciphertext, and sends it to the front-end. During the transmission process, the HTTPS protocol is used for link encryption to prevent the key from being stolen during network transmission.

[0029] Step S130: In response to the front end receiving the key ciphertext, the key is decrypted using the RSA decryption logic built into the front end to obtain a usable symmetric working key.

[0030] Specifically, the RSA decryption logic matches the backend's RSA private key. For frontend key decryption and memory-isolated storage, for example, after receiving the encrypted symmetric working key, the frontend uses its built-in RSA decryption logic (matching the backend's RSA private key) to decrypt the key and obtain a usable symmetric working key.

[0031] Step S140: Store the available symmetric working key in the front-end memory using a memory-only pure memory storage mode to prevent the available symmetric working key from being written to any disk-level storage medium other than the front-end memory.

[0032] As one possible implementation, the decrypted key is stored only in the front-end memory, using a memory-only pure memory storage mode, and writing the key to any disk-level storage medium (including localStorage, sessionStorage, Cookie, IndexedDB, etc.) is prohibited.

[0033] Step S150: Construct a memory isolation sandbox using the WeakMap feature and bind the available symmetric working key to the independent context of the front-end window object so that the available symmetric working key is only invoked within the specified application execution context.

[0034] By using the WeakMap feature to build a memory isolation sandbox, the key is bound to an independent context of the front-end window object, so that the key can only be called within the specified application execution context, preventing XSS attacks and unauthorized acquisition of the key by memory extraction tools.

[0035] In this embodiment, asymmetric encryption is used for key transmission, and the symmetric working key is encrypted with an RSA public key on the backend. The decrypted key on the frontend is stored only in pure memory. A memory isolation sandbox is built using WeakMap, and the key is bound to a specified application execution context, preventing the key from being illegally obtained by XSS attack scripts and memory extraction tools. By combining RSA encrypted transmission with memory-only memory storage, the traditional method of static hard-coding keys on the frontend is completely abandoned. Instead, a dynamic key generation and management mechanism of backend distribution, RSA encrypted transmission, and memory-isolated storage is adopted, achieving a balance between key timeliness, security, and availability, solving the single point of failure problem of keys, and realizing a browser-side data anti-tampering method based on HMAC signature.

[0036] In some embodiments, after storing the available symmetric working key in the front-end memory using a memory-only pure memory storage mode, the method may further include the following steps: Set the key validity period of the available symmetric working key to a first specified duration; in response to a second specified duration before the available symmetric working key reaches the corresponding expiration time of the first specified duration, automatically transmit a new key request to the backend through the frontend to complete the seamless key rotation update; the first specified duration is longer than the second specified duration; In response to the front end detecting abnormal access behavior, an emergency key update is triggered, and an abnormality identifier is sent to the back end through the front end. The back end then regenerates a dedicated symmetric working key based on the abnormality identifier, encrypts and distributes the dedicated symmetric working key, and invalidates the original key of the usable symmetric working key. Abnormal access behavior includes at least one of the following: consecutive signature verification failures, unauthorized modification of stored data, and XSS attack alarms.

[0037] For the dual-mode automatic key update, for example, the symmetric working key adopts a dual-mode update mechanism that combines time-driven and event-driven approaches. At the time-driven level, the key validity period is strictly set to 2 hours. Five minutes before the expiration date, the front end automatically sends a new key request to the back end, completing the seamless key rotation. At the event-driven level, when the front end detects abnormal access behavior (such as consecutive signature verification failures, unauthorized modification of stored data, or XSS attack alerts), an emergency key update is immediately triggered. The front end sends an abnormality flag to the back end, and the back end regenerates a unique symmetric working key and encrypts and distributes it, while invalidating the original key.

[0038] Dynamic keys are the core of this security solution. This application abandons the traditional front-end static hard-coded key method and adopts a dynamic key generation and management mechanism of back-end distribution + RSA encrypted transmission + memory isolated storage + dual-mode automatic update to achieve a balance between key timeliness, security and availability.

[0039] For time-driven and event-driven dual-mode key updates, for example, the key can be automatically rotated at fixed intervals (2 hours) and can also be updated urgently when abnormal behavior is detected. This achieves a combination of regular updates and emergency updates, shortening the risk cycle of key leakage from several months / years in traditional solutions to 2 hours. Even if the key is leaked in rare cases, it can be quickly invalidated and updated, minimizing the harm of key leakage.

[0040] In some embodiments, before storing the available symmetric working key in the front-end memory via a memory-only pure memory storage mode, the method may further include the following steps: The available symmetric working key is identified as the data to be stored; in response to the detection that the data to be stored is not in JSON format, the data to be stored is converted into a standard JSON key-value pair data structure to obtain JSON data; Sort all keys in the JSON data according to a specified sorting method and fix the key-value pair order to obtain sorted data. Remove all redundant and invalid characters from the sorted data and unify the data type format to obtain standardized JSON data. A dedicated timestamp field is added to the standardized JSON data; the timestamp field corresponds to the client's current system time; the key name of the timestamp field is fixed, and the fixed key name is concatenated with the standardized JSON data to form the complete data to be signed; the timestamp serves as the verification basis for subsequent anti-replay attacks and participates in the signature calculation, so that the signatures generated by the same data at different times are completely different; the corresponding HMAC hash algorithm is determined according to the security level of the data to be signed, and the signature is calculated using the corresponding HMAC hash algorithm to obtain the signature calculation result; The security level includes regular non-sensitive data. The HMAC hash algorithm corresponding to the regular non-sensitive data is the HMAC-SHA256 algorithm. The signature calculation is performed using the corresponding HMAC hash algorithm to obtain the signature calculation result. This includes: using the available symmetric working key in the front-end memory as the first key parameter and the complete data to be signed as the first message parameter, performing hash calculation using the HMAC-SHA256 algorithm based on the first key parameter and the first message parameter to generate a 256-bit binary signature value, and converting the 256-bit binary signature value into a hexadecimal string to obtain the final regular data signature. The security level includes critical sensitive data. The HMAC hash algorithm corresponding to the critical sensitive data is the HMAC-SHA512 algorithm. The signature is calculated using the corresponding HMAC hash algorithm, and the signature calculation result includes: calculating the consistency of the HMAC-SHA512 algorithm calculation logic with the regular data in the front-end memory, generating a 512-bit binary signature value, converting the 512-bit binary signature value into a hexadecimal string, and obtaining a sensitive data signature with a higher security level than the specified high security level.

[0041] For signature calculation, which is a core step in verifying data integrity, this application adopts the HMAC hash message authentication code algorithm, such as... Figure 2 As shown, by combining data standardization processing and millisecond-level timestamp embedding, a unique signature for the data is generated, while resisting replay attacks and data tampering attacks. Differentiated signature strategies are designed for data with different security levels. The specific implementation steps are as follows: Standardization preprocessing of data to be stored: To avoid inconsistencies in signature calculations due to differences in data formats (such as different key-value pair orders, redundant spaces, differences in data type formats, etc.), all raw data to be stored undergoes mandatory standardization processing. If the original data is not in JSON format, first convert it to a standard JSON key-value pair data structure; sort all keys in the JSON data in ascending order of English letters to fix the key-value pair order; remove all redundant spaces, newlines, tabs and other invalid characters from the data; unify the data type format, such as removing leading zeros from numeric types, unifying boolean types to lowercase true / false, and unifying empty values ​​to null.

[0042] For millisecond-level timestamp embedding, a dedicated timestamp field is added to the standardized JSON data. This timestamp represents the client's current system time, accurate to the millisecond level. Figure 2 As shown, the key name of the timestamp field is fixed as timestamp, which is concatenated with the standardized data to form the complete data to be signed. The timestamp serves as the core verification basis for subsequent anti-replay attacks and also participates in the signature calculation, so that the signatures generated by the same data at different times are completely different.

[0043] For differentiated HMAC signature calculation, for example, the corresponding HMAC hash algorithm is selected for signature calculation based on the security level of the data. The calculation process adopts a dual-input mode of combining the key with the data to be signed, specifically as follows: For routine, non-sensitive data: The HMAC-SHA256 algorithm is used, with the symmetric working key in front-end memory as the key parameter and the standardized, timestamped JSON data as the message parameter. HMAC-SHA256 hashing is performed to generate a 256-bit binary signature value, which is then converted to a hexadecimal string to obtain the final routine data signature. For critical, sensitive data: The HMAC-SHA512 algorithm is used, with the same calculation logic as for routine data, generating a 512-bit binary signature value and converting it to a hexadecimal string to obtain a high-security sensitive data signature, improving the signature's resistance to cracking. The signature calculation process is entirely completed in front-end memory, with no intermediate data stored on the disk, avoiding data leakage during the signature calculation process.

[0044] In some embodiments, after removing all redundant and invalid characters from the sorted data and unifying the data type format to obtain standardized JSON data, the method may further include the following steps: The standardized JSON data is encrypted using the AES-GCM-256 symmetric encryption algorithm, and the client's hardware fingerprint abbreviation is used as an additional parameter of AAD during the encryption process to bind the ciphertext to the client's hardware environment. The encryption process generates ciphertext data and authentication tags. The ciphertext data is then converted into a Base64 encoded string to obtain encrypted Base64 ciphertext data. The encrypted Base64 ciphertext data, signature calculation results, and timestamps are then assembled to generate ternary structured data. The ternary structured data is converted into a standard JSON string, and then written to the specified storage key name using the browser's localStorage's setItem method on the browser side; the storage key name is defined according to business requirements.

[0045] For structured secure storage, this application designs a three-element structured storage format of encrypted data + unique signature + millisecond-level timestamp, taking into account the storage characteristics of browser-side localStorage. The original data encryption, signature, and timestamp are stored separately but linked together. At the same time, a strong encryption algorithm is used to protect the encrypted data, preventing the original data and signature from being directly exposed. The specific implementation steps are as follows: AES-GCM-256 Encryption of Raw Data: The standardized preprocessed raw data (basic data without embedded timestamps) is encrypted using the AES-GCM-256 symmetric encryption algorithm. During the encryption process, an Additional Authentication Data (AAD) mechanism is introduced, using the client's hardware fingerprint abbreviation (a concatenated value of CPU model identifier and screen resolution hash value) as an additional parameter of AAD, binding the ciphertext to the client's hardware environment. Even if the ciphertext is stolen, it cannot be decrypted in other hardware environments. After encryption, ciphertext data and authentication tags are generated, and the ciphertext data is converted into a Base64 encoded string for easy storage in localStorage.

[0046] The ternary structured data assembly process combines the encrypted Base64 ciphertext data, the HMAC signature generated in section 5.1.2, and the embedded millisecond-level timestamp to form a fixed JSON structured data. This structured data contains three core fields with fixed names: data: stores the ciphertext data encrypted with AES-GCM-256 and then Base64 encoded; sign: stores the hexadecimal signature string generated by the HMAC-SHA256 / HMAC-SHA512 algorithm; and timestamp: stores the millisecond-level timestamp value used in the signature calculation. The structured data has no other redundant fields, ensuring lightweight storage.

[0047] localStorage structured writing: The assembled ternary structured data is converted into a standard JSON string and written to the specified storage key name using the browser's localStorage setItem method. The storage key name is customized according to business needs (e.g., user preference data is user_prefs, session state data is session_state). During the writing process, the storage operation is logged, and the logged content includes the storage key name, writing time, and data size. The log is only stored in the front-end memory and is used for anomaly tracing.

[0048] In this embodiment, a multi-factor fusion dynamic key management mechanism is used to overcome the technical bottleneck of traditional static key management. A dynamic key generation system based on multi-factor fusion is designed, and dual-mode update and memory-isolated storage are implemented to ensure key security throughout the entire lifecycle of key generation, transmission, storage, and update. This solves the industry pain point of easy theft and leakage of front-end keys, as detailed below: Key generation using a multi-factor hybrid entropy source: The symmetric working key is generated by combining the client hardware fingerprint with a high-precision time signal as the hybrid entropy source. The hardware fingerprint includes the CPU model identifier (obtained through the browser's navigator.hardwareConcurrency and system information API), the screen resolution hash value (HMAC-SHA256 hash of the screen width-height product), and the graphics card rendering characteristics (obtained and hashed through WebGL's getParameter method). The high-precision time signal is the system timestamp accurate to milliseconds. The multi-factor entropy source is concatenated and the original key is generated using the SHA-3-512 algorithm to ensure the randomness and uniqueness of the key and prevent brute-force attacks.

[0049] In some embodiments, the method may further include the following steps: In response to the startup of the client web application, the key request unit and data processing unit are initialized through the front end, and the target key request is sent to the back end key service unit. The target key request carries the client's unique identifier and hardware fingerprint abbreviation. The key service unit verifies the legitimacy of the unique identifier, assigns a dedicated 2048-bit RSA public key to the client, extracts the 256-bit symmetric working key of the current batch, encrypts the 256-bit symmetric working key with the RSA public key, and generates the target key ciphertext. The backend sends the RSA public key and the target key ciphertext to the frontend via an HTTPS link; the frontend uses RSA decryption logic to decrypt the target key ciphertext to obtain the target symmetric working key, and stores the target symmetric working key in a memory-only sandbox to complete key initialization; The system obtains the original data to be stored from the business layer through the front end. It then performs standardized preprocessing to obtain standardized raw data. This standardized raw data is then encrypted using AES-GCM-256 to generate Base64-encoded target ciphertext data. A millisecond-level timestamp is embedded into the standardized raw data to obtain timestamped data. The target ciphertext data and the timestamped data are concatenated to obtain the target data to be signed. Based on the data security level, the HMAC-SHA256 / HMAC-SHA512 algorithm is selected, using the target symmetric working key in memory as the secret key. A signature calculation is performed on the target data to be signed, generating a hexadecimal signature string. The target ciphertext data, the signature string, and the timestamped data are assembled into a ternary structured JSON data. This ternary structured JSON data is then converted into the target string and written to localStorage with the specified key name to complete data storage.

[0050] For the complete data storage implementation process, for example, the browser-side data storage process of this application is a standardized backend-frontend collaborative process. From application startup to the final writing of data to localStorage, it is divided into 8 specific steps, all of which are executed automatically without manual intervention. The specific process is as follows: When the client web application starts, the front-end initializes the key request module and the data processing module, and sends a key request to the back-end key service module, carrying the client's unique identifier and hardware fingerprint abbreviation in the request. The backend key service module verifies the legitimacy of the client's identifier, assigns it a unique 2048-bit RSA public key, and extracts the 256-bit symmetric working key for the current batch. It then encrypts this symmetric working key using the RSA public key to generate key ciphertext. The backend sends the RSA public key and the encrypted key ciphertext to the frontend via an HTTPS link. By using HTTPS for the transmission link, dual protection is achieved through asymmetric encryption combined with link encryption for key transmission. The front end decrypts the key ciphertext using RSA decryption logic to obtain the symmetric working key, stores the key in a memory-only sandbox, and completes key initialization; the front end obtains the original data to be stored from the business layer and performs standardized preprocessing on it (format conversion, key name sorting, removal of redundant characters, and unification of data format). The front end encrypts the standardized raw data with AES-GCM-256 (with the hardware fingerprint AAD parameter attached) to generate Base64 encoded ciphertext data. At the same time, it embeds a millisecond-level timestamp into the standardized data and concatenates them into the data to be signed. Based on the data security level, the frontend selects the HMAC-SHA256 / HMAC-SHA512 algorithm, uses the symmetric working key in memory as the secret key, performs signature calculation on the data to be signed, and generates a hexadecimal signature string. The frontend assembles the ciphertext data, signature string, and timestamp into a three-element structured JSON data, converts it into a string, and writes it to the localStorage with the specified key name to complete the secure storage of the data.

[0051] For the complete process of writing to localStorage, such as Figure 3 As shown in Figure 3, this is a core schematic diagram of the data storage process of this invention, illustrating the complete process from the startup of the client web application to the final writing of data to localStorage. It involves two main module sets: a backend module and a frontend module, divided into eight core steps. Arrowed lines indicate the data transmission and processing flow, with each module corresponding to a step, clearly demonstrating the core operations and data conversion process at each stage. The attached figure is drawn at a 1:1 scale. Modules are identified using rectangles, core operations are labeled with text next to the steps, data flow arrows are indicated by solid lines, and encrypted transmission links are indicated by bold solid lines.

[0052] For example, the backend module set includes a backend key service module, an RSA encryption module, and an HTTPS link transmission module. The backend key service module is the core, responsible for generating the symmetric working key and the RSA public key. The RSA encryption module is responsible for encrypting the symmetric working key. The HTTPS link transmission module is responsible for implementing encrypted data transmission between the backend and the frontend. The frontend module set includes a key request module, an RSA decryption module, a memory isolation sandbox module, a data standardization module, an AES-GCM encryption module, an HMAC signature calculation module, a structured data assembly module, and a localStorage storage module. Each module interacts sequentially according to the process to complete key initialization, data encryption and signing, and structured data storage.

[0053] For the steps and data flow, Figure 3 illustrates the eight core steps of data storage, labeled with numbers 1-8. The operations and data flow of each step are as follows: The front-end key request module sends a key request to the back-end key service module, carrying the client's unique identifier and hardware fingerprint abbreviation; the back-end key service module generates a symmetric working key and an RSA public key, and transmits them to the RSA encryption module; the RSA encryption module encrypts the symmetric working key using the RSA public key, generating key ciphertext, and transmits it to the HTTPS link transmission module; the HTTPS link transmission module sends the RSA public key and key ciphertext to the front-end RSA decryption module via the HTTPS link (bold solid line); the RSA decryption module decrypts the key ciphertext to obtain the symmetric working key, and transmits it to the memory isolation sandbox module for secure storage; simultaneously, the front-end business layer transmits the original data to be stored to the data standardization module; the data standardization module completes data standardization preprocessing, and transmits the standardized data to the AES-GCM encryption module and the HMAC signature calculation module respectively; the AES-GCM encryption module encrypts the standardized data, generating Base64 ciphertext data; HMAC... The signature calculation module embeds a millisecond-level timestamp into the standardized data and combines it with the symmetric working key in memory to complete the signature calculation and generate a hexadecimal signature. The ciphertext data, signature, and timestamp are then transmitted to the structured data assembly module. The structured data assembly module assembles the data into ternary structured data, transmits it to the localStorage storage module, and finally writes it to the browser's localStorage to complete the data storage.

[0054] In some embodiments, after converting the ternary structured JSON data into a string and writing it to localStorage with a specified key to complete data storage, the method may further include the following steps: The front-end uses the getItem method of localStorage to read the target string with a specified key, parses the target string into a structured data object, obtains the current system's millisecond-level timestamp, and calculates the time difference between the current time and the storage time; the time difference is the current timestamp of the current time minus the timestamp value corresponding to the storage time. If the time difference is greater than the preset maximum valid duration, the target string is determined to have failed timestamp validity verification, and a tampering response policy is triggered to clear the abnormal data; if the time difference is less than or equal to the preset maximum valid duration, the target string is determined to have passed timestamp validity verification, and the HMAC signature integrity verification process is executed. During the HMAC signature integrity verification process, the front end extracts the data and timestamp fields from the three-element structured JSON data corresponding to the target string, embeds the timestamp into an empty standardized JSON structure, generates a data structure to be signed that is consistent with the storage time, extracts the currently valid symmetric working key from the memory isolation sandbox, selects the HMAC-SHA256 / HMAC-SHA512 algorithm consistent with the storage time according to the data security level, and recalculates the signature using the HMAC-SHA256 / HMAC-SHA512 algorithm. During the recalculation of the signature, the symmetric working key is used as the second key parameter and the concatenated data to be signed is used as the second message parameter. A new hexadecimal signature string is generated based on the second key parameter and the second message parameter. The new hexadecimal signature string is compared bit by bit with the sign field in the ternary structured JSON data. If any bit of the comparison result is different, the signature verification is deemed to have failed, the data is determined to have been actively tampered with, and the tampering response strategy is triggered. If the comparison result is completely consistent, the signature verification is deemed to have passed, and the AES-GCM-256 data decryption verification process is executed. During the AES-GCM-256 data decryption verification process, the data field in the ternary structured JSON data is extracted by the front end, Base64 is decoded on the data field to obtain the original ciphertext after AES-GCM-256 encryption, the symmetric working key is extracted from memory, and the hardware fingerprint abbreviation of the current client is obtained. The original ciphertext is decrypted using the AES-GCM-256 decryption algorithm, and the legality of the authentication label is verified during the decryption process. If the decryption process proceeds without errors and restores the original data in standard JSON format, the decryption verification is considered successful, and the restored original data is returned to the business layer to complete the entire data reading verification process. If the decryption process encounters an error, the decryption verification is considered unsuccessful, and the tampering response policy is triggered.

[0055] For browser-side data tamper-proofing verification processes based on HMAC signatures, an example is as follows: Figure 4 As shown, this application designs a triple verification mechanism to perform end-to-end zero-trust verification on structured data read from localStorage. The verification process is entirely completed locally on the front end with zero server-side interaction, ensuring high-performance verification. If any layer of verification fails, a tampering response policy is immediately triggered, such as... Figure 2 As shown, the specific verification steps are as follows: First layer: Timestamp validity verification: The core purpose of timestamp verification is to defend against replay attacks and data rollback attacks, ensuring that the data read is legitimate data within the valid time limit. Specifically: The frontend reads a structured JSON string with a specified key using the `getItem` method of `localStorage`, parses it into a structured data object containing `data`, `sign`, and `timestamp`; the frontend obtains the current system's millisecond-level timestamp and calculates the time difference between the current time and the stored time: Time difference = Current timestamp - Stored timestamp value; a preset maximum valid data duration (MAX_AGE) is used, which can be configured according to business needs (the default is consistent with the key validity period, which is 2 hours). If the calculated time difference is greater than MAX_AGE, the timestamp verification is considered to have failed, and a tampering response policy is immediately triggered to clear the abnormal data; if the time difference is less than or equal to MAX_AGE, the second layer of signature verification is initiated.

[0056] The second layer: HMAC signature integrity verification: Signature verification is the core step in verifying whether data has been tampered with. It determines data integrity by recalculating the signature and comparing it with the stored signature. Specifically: The frontend extracts the `data` field (Base64 ciphertext) and the `timestamp` field from the structured data, embedding the `timestamp` into an empty, standardized JSON structure to form the data structure to be signed, consistent with the storage structure. The frontend extracts the currently valid symmetric working key from the memory isolation sandbox and, based on the data's security level (determined by the storage key name or data identifier), selects the same HMAC-SHA256 / HMAC-SHA512 algorithm as the one used during storage to recalculate the signature: using the symmetric working key as the secret key and the concatenated data to be signed as the message parameter, generates a new hexadecimal signature string; for example... Figure 2 As shown, the newly calculated signature is compared bit by bit with the sign field in the structured data: if the two are completely identical, the signature verification is deemed successful and the third layer of data decryption is initiated; if there is any difference between the two, the signature verification is deemed unsuccessful and the tampering response strategy is immediately triggered.

[0057] The third layer: AES-GCM-256 data decryption verification: This layer verifies the validity of the ciphertext data and restores the original data. Combined with the AAD (Additional Authentication Data) mechanism, it verifies whether the ciphertext matches the client's hardware environment. Specifically: The frontend extracts the `data` field from the structured data, first decoding it using Base64 to obtain the original ciphertext encrypted with AES-GCM-256. The frontend extracts the symmetric working key from memory and obtains the current client's hardware fingerprint abbreviation (consistent with the AAD parameters stored). It then uses the AES-GCM-256 decryption algorithm to decrypt the original ciphertext, verifying the legitimacy of the authentication tag during the decryption process. If the decryption process is error-free and can restore the original data in standard JSON format, the decryption verification is considered successful, and the restored original data is returned to the business layer, completing the entire data reading and verification process. If the decryption process encounters errors (such as ciphertext tampering, AAD parameter mismatch, or invalid authentication tag), the decryption verification is considered unsuccessful, and a tampering response policy is immediately triggered.

[0058] For a three-tiered defense system, this application constructs a three-tiered defense-in-depth architecture consisting of a data layer, an authentication layer, and a timeliness layer. Different technical solutions are designed for different security dimensions, ensuring both security strength and performance optimization through algorithmic grading. This solves the problem of traditional solutions where security and performance cannot be simultaneously achieved. The specific solutions are as follows: Data Layer: AES-GCM-256 Encryption Combined with AAD Additional Authentication: The industrial-grade AES-GCM-256 symmetric encryption algorithm is used at the bottom layer of data storage. This algorithm has both encryption and authentication functions. At the same time, it innovatively introduces the Additional Authentication Data (AAD) mechanism, which uses the client hardware fingerprint as the AAD parameter, so that the ciphertext is deeply bound to the client hardware environment. Even if the ciphertext is stolen, it cannot be decrypted in other hardware environments, thus realizing environment-bound encryption of data. Authentication Layer: Differentiated Authentication with Dual HMAC Signature Chains: A dual HMAC signature chain structure is designed at the data authentication layer. HMAC-SHA256 and HMAC-SHA512 algorithms are used for regular non-sensitive data and key sensitive data, respectively. Regular data prioritizes verification speed, while sensitive data prioritizes anti-cracking capabilities. The differentiated signature strategy achieves a dynamic balance between security level and performance. At the same time, the signature calculation and data encryption use the same dynamic key, ensuring the synergy between authentication and encryption. Timeliness Layer: Time Window Lock Combined with Monotonically Increasing Counter: A time window lock mechanism is introduced into the data timeliness layer. The effective duration of data is controlled through millisecond-level timestamps and configurable MAX_AGE. At the same time, a monotonically increasing counter is configured for each storage key name. The counter value increases with each data update and is stored in the structured data to participate in signature calculation, effectively resisting replay attacks and data rollback attacks, and solving the problem that traditional solutions cannot verify the timeliness of data.

[0059] For the end-to-end zero-trust verification model, for example, this application thoroughly implements the zero-trust security principle, proposes a browser-side data verification concept of "never trusting, always verifying, and real-time computing", establishes an end-to-end zero-trust verification mechanism covering data reading, timeliness verification, signature verification, and decryption verification, and designs a signature caching accelerator to improve verification performance. The specific scheme is as follows: Four-stage end-to-end verification: The verification process is divided into four key stages: timestamp validity verification, dynamic key acquisition, real-time signature calculation, and multi-dimensional decision-making. Each stage is an independent verification link. If any stage fails, the process will be terminated immediately and a response will be triggered, realizing full-dimensional and comprehensive verification of data and completely abandoning the single verification method of traditional solutions. Signature Cache Accelerator: For frequently read legitimate data, a signature cache accelerator is designed to cache the first successfully verified signature along with its corresponding timestamp and data key in memory. The cache validity period is consistent with the data MAX_AGE. Subsequent readings and verifications of the data only require comparing the signature results in the cache, without re-executing the HMAC algorithm calculation. This reduces the average data verification time from 3ms to 0.2ms, achieving high-performance zero-trust verification.

[0060] For the five-level gradient adaptive security response mechanism, for example, this application designs a five-level gradient response system based on the severity of the attack. This system overcomes the limitations of traditional solutions that only perform tampering responses (cleaning only data), and achieves differentiated, gradient, and automated security responses. At the same time, it keeps the false positive rate at an extremely low level, balancing security and business availability. The specific solution is as follows: Five-level differentiated response: Based on the severity, frequency, and failure type of the tampering event, the response level is divided into five levels, each with a specific response strategy, enabling lightweight handling of minor anomalies and heavy-duty defense against severe attacks. Level 1 Response (Minor Signature Failure in a Single Field): Only field reset and local security alert are executed, without affecting business operations; Level 2 Response (Timestamp Expiration / Single Data Decryption Failure): Abnormal data is silently cleared, encrypted logs are generated, and key updates are not triggered; Level 3 Response (Two Consecutive Signature Verification Failures): Abnormal data is cleared + signature cache is cleared + regular key updates are triggered; Level 4 Response (Three or More Consecutive Decryption Failures): Abnormal data is cleared + emergency key updates are performed + front-end permissions are temporarily frozen; Level 5 Response (High-Frequency Tampering / Cross-Device Attacks): All locally stored data is cleared + all keys are invalidated + user biometric re-authentication is triggered + core logs are encrypted and reported to the backend.

[0061] For attack identification with a low false positive rate, multi-dimensional attack feature identification (such as failure frequency, hardware fingerprint matching degree, and key version consistency) effectively distinguishes between malicious tampering attacks and normal data anomalies (such as client time errors and memory data loss). In attack tests with Chrome extensions and professional tampering tools, it successfully intercepted all localStorage tampering behaviors, with the false positive rate controlled below 0.003%. Front-end and back-end collaborative response: After the front-end completes the local automated response, it encrypts and reports the core information of high-level attacks (level 4 and level 5) to the back-end. The back-end adds the client identifier to the high-risk list and strictly verifies its subsequent key requests and business operations, thus realizing a collaborative response of front-end local defense and back-end remote management.

[0062] Figure 4 illustrates the core data reading verification process for browser-side data anti-tampering based on HMAC signatures. It shows the complete verification process from reading data from localStorage to returning the original data to the business layer, and includes the triggering logic for tampering responses. All modules are local front-end modules, achieving zero server-side interaction. The process is divided into 10 core steps: steps 1-3 are timestamp verification, 4-6 are signature verification, 7-9 are decryption verification, and step 10 is tampering response triggering. Arrowed lines represent the data flow; solid lines indicate successful verification, while dashed lines indicate failed verification, clearly demonstrating the triple verification logic and the triggering conditions for tampering responses. The attached figures are drawn at a 1:1 scale, with modules identified by rectangles, verification results marked with "√ (pass) / × (fail)," and tampering response modules identified by red rectangles.

[0063] For example, the front-end local module set includes a localStorage reading module, a timestamp verification module, an HMAC signature recalculation module, a signature comparison module, a Base64 decoding module, an AES-GCM decryption module, a data restoration module, a tampering response module, a memory isolation sandbox module, and a business layer data receiving module. The memory isolation sandbox module provides a symmetric working key for signature calculation and data decryption, and the tampering response module is a unified processing module for all verification failures.

[0064] For the steps and data flow, Figure 4 illustrates the 10 core steps of data reading and verification, labeled with numbers 1-10. The operation and data flow of each step are as follows: The localStorage reading module reads a structured JSON string from the browser's localStorage and parses it into a structured data object containing data, sign, and timestamp. The timestamp field of the structured data is transmitted to the timestamp verification module, while the current system's millisecond-level timestamp is obtained, and the time difference is calculated. The timestamp verification module determines whether the time difference is less than or equal to MAX_AGE: if the verification passes (√), the structured data is transmitted to the next step; if the verification fails (×), the data flows to the tampering response module (step 10) via the dotted line. After successful verification, the data and timestamp fields of the structured data are transmitted to the HMAC signature recalculation module, while the symmetric working key is extracted from the memory isolation sandbox module. The HMAC signature recalculation module recalculates the HMAC. The process involves several steps: First, a new signature is generated and transmitted to the signature comparison module along with the `sign` field of the structured data. The module compares the old and new signatures bit by bit. If verification passes (√), the `data` field is transmitted to the next step. If verification fails (×), the data flows through the dotted line to the tamper response module (step 10). After successful verification, the `data` field is transmitted to the Base64 decoding module to decode the original AES-GCM ciphertext and extract the symmetric working key from the memory isolation sandbox module. The original ciphertext and the client hardware fingerprint AAD parameter are transmitted to the AES-GCM decryption module for data decryption. The AES-GCM decryption module completes the decryption verification. If verification passes (√), the restored original data is transmitted to the business layer data receiving module, completing the entire read verification process. If verification fails (×), the data flows through the dotted line to the tamper response module (step 10). The tamper response module receives all failed verification trigger signals and performs hierarchical response operations such as silently clearing abnormal data, generating encrypted logs, updating keys, and re-authenticating users, completing the tamper event handling.

[0065] In some embodiments, the method may further include the following steps: For handling abnormal data, a silent cleanup operation is performed on the three-element structured JSON data that fails any one of the validations. The abnormal data is deleted by using the removeItem method of localStorage to prevent the abnormal data from being called by the business layer, and the signature cache corresponding to the abnormal data is cleared to prevent cache pollution. Tampering events are logged, and the log entries include at least one of the following: the time of the tampering event, the stored data key name, the verification failure type, the client hardware fingerprint, the current key version, the time difference corresponding to the timestamp validity verification failure, and the signature comparison difference bit; all log data is encrypted using AES-GCM and stored in the front-end temporary memory. The key log information of the tampering incident is encrypted and reported to the backend monitoring platform via HTTPS protocol, so that the monitoring platform can perform real-time alerts and statistics based on the key log information; the reported data includes at least one of the following: unique event identifier, failure type, and occurrence time; If the signature verification or decryption fails, clear the symmetric working key in the current front-end memory and trigger the emergency key update process to request a new symmetric working key from the front-end. At the same time, clear all signature caches on the front-end and reinitialize the verification environment. If the same client experiences more than a specified number of signature verification or decryption failures within a third specified time period, it is determined to be a high-risk tampering attack, triggering a user identity re-authentication process. This process freezes the local business operation permissions of the current user on the client until the current user completes mobile phone verification, SMS verification, or biometric verification. Once the verification is successful, the permissions are restored and the key is reissued.

[0066] For the tamper response strategy, for example, this application designs a hierarchical and automated tamper response strategy, taking differentiated measures for different verification failure types (timestamp expiration, signature mismatch, decryption failure), and realizing a full-process response including abnormal data processing, security log recording, attack tracing and alarm, and user identity re-authentication. All response operations are executed automatically on the front end, and some key abnormal information is encrypted and reported to the back-end monitoring platform. The specific strategy is as follows: Abnormal data handling: For any structured data that fails verification, perform a silent cleanup operation by deleting the abnormal data using the removeItem method of localStorage to prevent the abnormal data from being called by the business layer. At the same time, clear the signature cache corresponding to the data (if it exists) to prevent cache pollution. Security logging: Fine-grained logging of tampering events, including: the time of the tampering event (milliseconds), the stored data key name, the verification failure type, the client hardware fingerprint, the current key version, the time difference (for timestamp expiration), and the signature comparison difference bits (for signature mismatch). All log data is encrypted with AES-GCM and stored in the front-end temporary memory. The logs are retained for 24 hours for attack tracing. Encrypted audit log reporting: The core log information of the tampering event (after desensitization, removing sensitive information such as hardware fingerprints) is encrypted and reported to the backend security monitoring platform via HTTPS protocol. The reported information includes the unique identifier of the event, the failure type, and the occurrence time. After receiving the information, the monitoring platform will issue real-time alerts and perform statistics. Key and cache handling: If signature verification or decryption fails (indicating that the data has been actively tampered with), immediately clear the symmetric working key in the current front-end memory and trigger the emergency key update process to request a new symmetric working key from the front-end; at the same time, clear all signature caches on the front-end and reinitialize the verification environment; User re-authentication: If the same client fails signature verification / decryption 3 or more times within 10 minutes, it is judged as a high-risk tampering attack. The user identity re-authentication process is immediately triggered, and the current user's local business operation permissions are frozen until the user completes mobile phone verification code, SMS verification or biometric verification (such as fingerprint, facial recognition). Only after the verification is successful will the permissions be restored and the key be reissued.

[0067] Tampering Source Tracing and Analysis System: The tampering source tracing and analysis module is integrated into the verification mechanism. By identifying verification failure modes (such as timestamp expiration, single-character signature difference, ciphertext tampering, AAD mismatch), it determines the attack type (replay attack, brute-force tampering attack, cross-device theft attack, XSS injection attack) and writes the tracing results to the encrypted log, providing decision support for the intelligent defense of the backend security monitoring platform and realizing the integration of verification and source tracing.

[0068] To address the security adaptation issues across different browsers and operating environments, this application employs a multi-layered cross-platform compatibility solution, combining hardware-level protection, algorithm downgrade, and mode switching. This ensures reliable operation in mainstream browsers, mobile WebView, older browsers, and special environments without Crypto APIs, while guaranteeing that the security level does not significantly decrease with environment adaptation. The specific solution is as follows: Mobile WebView: Hardware-level security module integration: In the Android and iOS mobile WebView environments, a native security module is integrated. The Android side connects to Android Keystore, and the iOS side connects to iOS SecureEnclave. Dynamic keys are stored in the system-level hardware security module to achieve hardware-level protection of keys and improve the security level of mobile devices. For older browsers: Automatic algorithm downgrade adaptation: For older browsers (such as IE11 and below) that do not support modern encryption algorithms such as AES-GCM-256 and HMAC-SHA512, an automatic algorithm downgrade mechanism is designed: the encryption algorithm is automatically downgraded to AES-CBC-256 and the signature algorithm is downgraded to HMAC-SHA256. At the same time, the PBKDF2 key derivation scheme with a high number of iterations (10,000 times) is adopted to make up for the security loss caused by the algorithm downgrade and ensure basic anti-tampering capabilities. Special Environments: Intelligent Mode Switching: In special operating environments without a browser Crypto API (such as some embedded web environments and lightweight mini-programs), it automatically switches from local verification mode to server-side signature verification mode. At the same time, it optimizes network requests through HTTP / 2 0-RTT technology, reduces network overhead caused by server-side verification, and ensures the smoothness of business operations. Standardized interfaces across all environments: A unified front-end encryption / verification interface is designed for all compatible solutions. The business layer does not need to be aware of the differences in the underlying environment. The interface automatically adapts to the technical solutions of different environments, realizing one-time development and operation in all environments, reducing the deployment and maintenance costs of the solution.

[0069] This application addresses the need for tamper-proofing of locally stored data on browsers by designing a complete technical solution integrating dynamic key management, layered signature verification, structured secure storage, end-to-end zero-trust verification, and adaptive tamper response. Its core features include zero-server interaction local data integrity verification, timely protection against replay and rollback attacks, and dynamic key management to prevent key leakage, while also considering cross-platform compatibility and high-performance verification requirements. The technical implementation of this solution revolves around three core technical principles: dynamic key generation, standardized signature calculation, and structured secure storage. It includes a complete data storage process, a triple data reading verification process, and a tiered tamper response strategy. All technical aspects employ standardized cryptographic algorithms and engineering implementation methods, abandoning traditional methods such as front-end hard-coded keys and simple data obfuscation.

[0070] This application overcomes the technical bottlenecks of traditional browser-based data anti-tampering schemes, such as the contradiction between security and convenience, key management deficiencies, and lack of data integrity. It constructs a multi-dimensional, layered, zero-trust verification, and adaptive response browser-based data security protection system, while also solving the technical challenge of cross-platform compatibility. The key technological innovations of this application are reflected in five aspects: a dynamic key management mechanism, a layered defense system, a zero-trust verification model, an adaptive security response mechanism, and a cross-platform compatibility scheme. These innovations are interconnected and synergistic, forming a complete technological closed loop.

[0071] Addressing the shortcomings of traditional browser-based data anti-tampering solutions and existing technologies, this solution presents a complete, detailed, and practical technical approach. Through the synergistic effect of dynamic key management, layered defense, zero-trust verification, adaptive response, and cross-platform compatibility, it achieves breakthroughs in security, performance, compatibility, and ease of deployment. This solution has undergone practical deployment testing (based on Chrome 110, Edge 110, Safari 16, Android WebView, and iOS WebView environments), achieving significant application results in fields with high data security and performance requirements, such as finance, government affairs, and healthcare. It demonstrates clear technical and application advantages. The following sections elaborate on its security, performance, and compatibility deployment effects, and compare it with existing technologies to illustrate the innovative value of this application.

[0072] This application completely solves the core problems of traditional solutions, such as easy key leakage, single verification method, inability to resist replay attacks, and delayed response to tampering. Through dynamic key lifecycle management, three-level defense in depth, and end-to-end zero-trust verification, it significantly improves the security level of locally stored data on the browser side, achieving a qualitative leap in browser-side data tampering prevention. Actual testing has shown the following core security effects: Malicious tampering attack interception rate reaches 99.2%: In actual deployment in the financial field, after the solution went live, the number of malicious attack events such as localStorage configuration tampering and data forgery decreased by 99.2%. Professional tampering tools and malicious Chrome extensions could not bypass the signature verification and encryption mechanism of this solution, successfully protecting the integrity of sensitive data such as user preferences, session state, and business configuration. The risk cycle of key leakage is shortened to 2 hours: Through time-driven + event-driven dual-mode key updates, the risk cycle of key leakage is shortened from several months / years in traditional solutions to 2 hours. Even if the key is leaked in extreme cases, it can be quickly invalidated and updated, minimizing the harm caused by key leakage and completely solving the problem of single point of failure of key in traditional solutions. The false alarm rate is controlled below 0.003%: Through multi-dimensional attack feature identification, it effectively distinguishes between malicious tampering and normal data anomalies. In a continuous 3-month test, the false alarm rate remained stable below 0.003%, avoiding business operation interruptions caused by false alarms and balancing security and availability. Comprehensive protection against various typical attacks: This solution can effectively resist common browser-side security attacks such as tampering attacks, replay attacks, data rollback attacks, key theft caused by XSS attacks, and cross-device data theft attacks, achieving all-dimensional security protection for data.

[0073] Compared with existing technologies, this application focuses on local storage on the browser side, realizing local end-to-end verification with zero server-side interaction. It also adds timestamps and counters to effectively resist replay attacks, filling the gap in local storage protection. This application adopts lightweight cryptographic algorithms and local verification mechanisms, without relying on any distributed architecture, achieving a higher attack interception rate on the browser side, while consuming fewer resources.

[0074] This solution balances high-performance verification with low resource consumption, overcoming the performance bottlenecks of traditional solutions such as long data verification times and high resource consumption. Through a signature caching accelerator, differentiated algorithm strategies, and pure front-end local verification, it achieves high-performance, low-latency, and low-resource-consumption verification results, fully meeting the needs of high-performance applications such as real-time transaction systems and government processing platforms. Actual testing in the Chrome 110 test environment yielded the following core performance results: Data read verification latency is controlled within 0.8 milliseconds: Based on the optimization of the signature cache accelerator, the average time for the first data verification is 0.5ms, and the average time for verification after caching is only 0.2ms. The overall data read verification latency is stable within 0.8ms, which is far lower than the 3-5ms of the traditional solution. In application scenarios with frequent data interaction, there is no performance bottleneck. Memory consumption increases by no more than 15%: All core modules of this solution (key sandbox, signature cache, encryption / verification module) are implemented using lightweight engineering. Compared with traditional encryption solutions, the front-end memory consumption increases by only 15%, and it can run smoothly on low-end terminals (such as entry-level mobile phones and old computers) without lag, crashes or other problems. No significant decrease in data storage / read throughput: The encryption, signing, and verification operations in this solution are all front-end memory-level operations, which have no significant impact on the storage / read throughput of localStorage. A single client can complete more than 1,000 secure storage / verification operations per second, meeting the needs of high-concurrency business. Zero server-side interaction, reducing server load: The core verification process of this solution is completed locally on the front end, eliminating the need to frequently send verification requests to the server. Compared with solutions such as HTTP-only cookies and server-side signature verification, this significantly reduces the network and computational load on the server, improving the overall system performance of the web application.

[0075] This solution also ensures effective deployment, achieving full platform compatibility and convenient deployment. The multi-layered cross-platform compatibility solution designed in this application solves the adaptation issues between different browsers and operating environments. Furthermore, the solution adopts a non-intrusive design, requiring no modification to the existing business architecture, resulting in convenient deployment, low maintenance costs, and strong engineering feasibility. Specific effects are as follows: High compatibility across all platforms: This solution supports all mainstream browsers (Chrome, Edge, Firefox, Safari, 360 Browser, etc.), mobile Android / iOS WebView, older browsers (IE11 and below), special embedded web environments and mini-programs. It can guarantee basic anti-tampering capabilities in all environments, and can also achieve hardware-level security protection in some environments. Non-intrusive deployment without modifying existing business architecture: This solution encapsulates core functions such as encryption, signing, verification, and response into an independent front-end SDK. The business layer only needs to call the unified interface of the SDK to achieve secure data storage and retrieval. There is no need to modify the existing business logic, data structure, and back-end services. The deployment process is simple. You only need to introduce the SDK into the front-end project and perform simple configuration. The deployment cycle can be controlled within 1 working day. Low maintenance cost and support for dynamic configuration: The core parameters of the solution (key validity period, data MAX_AGE, response level, security algorithm) can all be dynamically configured through the backend without modifying the frontend code, realizing remote dynamic management and reducing subsequent maintenance and upgrade costs; Comprehensive logging and monitoring system: This solution features a sophisticated encrypted logging and backend monitoring platform that can statistically analyze the number, type, and frequency of tampering events in real time, enabling real-time perception, accurate tracing, and rapid handling of security risks, providing data support for the secure operation of web applications.

[0076] Regarding the application scenario adaptability of this application, this solution, with its high security, high performance, high compatibility, and easy deployment, can be widely adapted to various web application scenarios with high requirements for browser-side data security and performance. It demonstrates excellent adaptability, particularly in real-time transaction systems in the financial sector, government processing platforms in the government sector, medical information management systems in the medical sector, and user session management systems in the e-commerce sector: Real-time financial transaction systems: Protecting users' transaction configurations, fund account session information, and preventing transaction risks caused by malicious tampering; the zero-server-side interaction verification method meets the real-time requirements of transactions; Government processing platforms: Protecting users' government processing information and identity session information, complying with the security management requirements of government data; the cross-platform compatible solution adapts to government processing scenarios on different terminals; Medical information management systems: Protecting patients' medical information and consultation session information, preventing data forgery and tampering; its low resource consumption characteristic adapts to various terminal devices in hospitals.

[0077] Figure 5 A schematic diagram of a browser-side data processing device is provided. Figure 5 As shown, the browser-side data processing device 500 includes: The generation module 501 is used to generate an initialized symmetric working key through the backend corresponding to the browser. The encryption module 502 is used to transmit a key request to the front end corresponding to the browser in response to the startup of the client web application, and when the back end receives the key request, encrypt the symmetric working key using the RSA asymmetric encryption algorithm to generate encrypted key ciphertext, and transmit the key ciphertext to the front end. The decryption module 503 is used to respond to the front end receiving the key ciphertext, and to decrypt the key through the RSA decryption logic built into the front end to obtain a usable symmetric working key; the RSA decryption logic matches the RSA private key of the back end; Storage module 504 is used to store the available symmetric working key in the memory of the front end in a memory-only pure memory storage mode to prevent the available symmetric working key from being written to any disk-level storage medium other than the memory of the front end; Binding module 505 is used to build a memory isolation sandbox through the WeakMap feature and bind the available symmetric working key to the independent context of the front-end window object so that the available symmetric working key is only invoked within the specified application execution context.

[0078] The browser-side data processing device provided in this application embodiment has the same technical features as the browser-side data processing method provided in the above embodiments, so it can also solve the same technical problems and achieve the same technical effects.

[0079] An electronic device provided in this application embodiment, such as Figure 6 As shown, the electronic device 600 includes a processor 602 and a memory 601. The memory stores a computer program that can run on the processor. When the processor executes the computer program, it implements the steps of the method provided in the above embodiments.

[0080] See Figure 6 The electronic device also includes a bus 603 and a communication interface 604. The processor 602, the communication interface 604 and the memory 601 are connected through the bus 603. The processor 602 is used to execute executable modules, such as computer programs, stored in the memory 601.

[0081] The memory 601 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 604 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0082] Bus 603 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0083] The memory 601 is used to store programs. After receiving an execution instruction, the processor 602 executes the program. The method executed by the apparatus defined by the process disclosed in any of the preceding embodiments of this application can be applied to the processor 602 or implemented by the processor 602.

[0084] The processor 602 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 602 or by instructions in software form. The processor 602 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 601, and processor 602 reads the information from memory 601 and, in conjunction with its hardware, completes the steps of the above method.

[0085] Corresponding to the above-described browser-side data processing method, this application embodiment also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are invoked and executed by a processor, the computer-executable instructions cause the processor to perform the steps of the above-described browser-side data processing method.

[0086] The browser-side data processing device provided in this application embodiment can be specific hardware on the device or software or firmware installed on the device. The implementation principle and technical effects of the device provided in this application embodiment are the same as those in the foregoing method embodiments. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the foregoing method embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

[0087] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0088] For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0089] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0090] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0091] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the browser-side data processing method described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0092] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0093] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A browser-side data processing method, characterized in that, The method includes: An initial symmetric working key is generated through the backend corresponding to the browser client; In response to the launch of the client web application, a key request is transmitted to the front end corresponding to the browser. When the back end receives the key request, the symmetric working key is encrypted using the RSA asymmetric encryption algorithm to generate encrypted key ciphertext, and the key ciphertext is transmitted to the front end. In response to the front end receiving the key ciphertext, the front end decrypts the key using its built-in RSA decryption logic to obtain a usable symmetric working key; the RSA decryption logic matches the back end's RSA private key. The available symmetric working key is stored in the memory of the front end in a memory-only pure memory storage mode to prevent the available symmetric working key from being written to any disk-level storage medium other than the memory of the front end; A memory-isolated sandbox is constructed using the WeakMap feature, and the available symmetric working key is bound to an independent context of the front-end window object, so that the available symmetric working key is only invoked within the specified application execution context.

2. The method according to claim 1, characterized in that, After storing the available symmetric working key in the front-end's memory using a memory-only pure memory storage mode, the method further includes: Set the key validity period of the available symmetric working key to a first specified duration; In response to a second specified time period before the available symmetric working key reaches the corresponding period of the first specified time period, a new key request is automatically transmitted from the front end to the back end to complete the seamless key rotation update; the first specified time period is longer than the second specified time period. In response to the front end detecting abnormal access behavior, an emergency key update is triggered, and an abnormal identifier is sent to the back end through the front end. The back end then regenerates a dedicated symmetric working key based on the abnormal identifier, encrypts and distributes the dedicated symmetric working key, and invalidates the original key of the usable symmetric working key. The abnormal access behavior includes at least one of the following: consecutive signature verification failures, unauthorized modification of stored data, and XSS attack alarm.

3. The method according to claim 1, characterized in that, Before storing the available symmetric working key in the front-end's memory using a memory-only pure memory storage mode, the method further includes: The available symmetric working key is identified as the data to be stored; In response to detecting that the data to be stored is not in JSON format, the data to be stored is converted into a standard JSON key-value pair data structure to obtain JSON data; Sort all keys in the JSON data according to a specified sorting method and fix the key-value pair order to obtain sorted data. Remove all redundant and invalid characters from the sorted data and unify the data type format to obtain standardized JSON data. Add a dedicated timestamp field to the standardized JSON data; the timestamp in the timestamp field corresponds to the current system time of the client. The key name of the timestamp field is fixed, and the fixed key name is concatenated with the standardized JSON data to form the complete data to be signed; the timestamp serves as the verification basis for subsequent anti-replay attacks and participates in the signature calculation, so that the signatures generated by the same data at different times are completely different; The corresponding HMAC hash algorithm is determined based on the security level of the data to be signed, and the signature is calculated using the corresponding HMAC hash algorithm to obtain the signature calculation result. The security level includes regular non-sensitive data, and the HMAC hash algorithm corresponding to the regular non-sensitive data is the HMAC-SHA256 algorithm. The signature calculation using the corresponding HMAC hash algorithm to obtain the signature calculation result includes: using the available symmetric working key in the front-end memory as the first key parameter and the complete data to be signed as the first message parameter in the front-end memory using the HMAC-SHA256 algorithm; performing hash calculation based on the first key parameter and the first message parameter using the HMAC-SHA256 algorithm to generate a 256-bit binary signature value; and converting the 256-bit binary signature value into a hexadecimal string to obtain the final regular data signature. The security level includes critical sensitive data, and the HMAC hash algorithm corresponding to the critical sensitive data is the HMAC-SHA512 algorithm. The signature calculation using the corresponding HMAC hash algorithm to obtain the signature calculation result includes: in the front-end memory, the HMAC-SHA512 algorithm calculation logic is consistent with that of regular data to generate a 512-bit binary signature value, and the 512-bit binary signature value is converted into a hexadecimal string to obtain a sensitive data signature with a higher than the specified high security level.

4. The method according to claim 3, characterized in that, After removing all redundant and invalid characters from the sorted data and unifying the data type format to obtain standardized JSON data, the process further includes: The standardized JSON data is encrypted using the AES-GCM-256 symmetric encryption algorithm, and the hardware fingerprint abbreviation of the client is used as an additional parameter of AAD during the encryption process to bind the ciphertext to the hardware environment of the client. The encryption process generates ciphertext data and an authentication tag. The ciphertext data is then converted into a Base64 encoded string to obtain the encrypted Base64 ciphertext data. The encrypted Base64 ciphertext data, the signature calculation result, and the timestamp are assembled to generate ternary structured data; The ternary structured data is converted into a standard JSON string, and then written into a specified storage key using the browser's localStorage's setItem method on the browser side; the storage key is defined according to business requirements.

5. The method according to claim 1, characterized in that, Also includes: In response to the startup of the client web application, the front-end initializes the key request unit and the data processing unit, and sends a target key request to the back-end key service unit. The target key request carries the client's unique identifier and hardware fingerprint abbreviation. The key service unit verifies the legitimacy of the unique identifier, assigns a dedicated 2048-bit RSA public key to the client, extracts the 256-bit symmetric working key of the current batch, encrypts the 256-bit symmetric working key with the RSA public key, and generates the target key ciphertext. The backend sends the RSA public key and the target key ciphertext to the frontend via an HTTPS link. The target key ciphertext is decrypted using the RSA decryption logic at the front end to obtain the target symmetric working key. The target symmetric working key is then stored in a memory-only sandbox to complete key initialization. The system obtains the original data to be stored from the business layer through the front end, performs standardized preprocessing on the original data to obtain standardized original data, encrypts the standardized original data with AES-GCM-256 to generate Base64 encoded target ciphertext data, embeds a millisecond-level timestamp into the standardized original data to obtain timestamped data, concatenates the target ciphertext data and the timestamped data to obtain target data to be signed, selects the HMAC-SHA256 / HMAC-SHA512 algorithm according to the data security level, uses the target symmetric working key in memory as the key to perform signature calculation on the target data to be signed to generate a hexadecimal signature string, assembles the target ciphertext data, the signature string and the timestamped data into a ternary structured JSON data, converts the ternary structured JSON data into a target string and writes it to localStorage with a specified key name to complete data storage.

6. The method according to claim 5, characterized in that, After converting the ternary structured JSON data into a string and writing it to localStorage with a specified key to complete data storage, the method further includes: The front end uses the getItem method of localStorage to read the target string with the specified key name, parses the target string into a structured data object, obtains the current system's millisecond-level timestamp, and calculates the time difference between the current time and the storage time; the time difference is the current timestamp of the current time minus the timestamp value corresponding to the storage time. In response to the time difference being greater than the preset maximum valid duration, the target string is determined to have failed the timestamp validity verification, and a tampering response strategy is triggered to clear the abnormal data; In response to the time difference being less than or equal to the preset maximum valid duration, the target string is determined to have passed the timestamp validity verification, and the HMAC signature integrity verification process is executed; During the HMAC signature integrity verification process, the front end extracts the data and timestamp fields from the ternary structured JSON data corresponding to the target string, embeds the timestamp into an empty standardized JSON structure, generates a data structure to be signed that is consistent with the storage time, extracts the currently valid symmetric working key from the memory isolation sandbox, selects the HMAC-SHA256 / HMAC-SHA512 algorithm consistent with the storage time according to the data security level, and recalculates the signature using the HMAC-SHA256 / HMAC-SHA512 algorithm. During the recalculation of the signature, the symmetric working key is used as the second key parameter and the concatenated data to be signed is used as the second message parameter. A new hexadecimal signature string is generated based on the second key parameter and the second message parameter. The new hexadecimal signature string is compared bit by bit with the sign field in the ternary structured JSON data. If any bit of the comparison result is different, the signature verification is determined to be unsuccessful, the data is determined to be actively tampered with, and the tampering response strategy is triggered. If the comparison result is completely consistent, the signature verification is determined to be successful, and the AES-GCM-256 data decryption verification process is executed. During the AES-GCM-256 data decryption verification process, the front end extracts the data field from the ternary structured JSON data, performs Base64 decoding on the data field to obtain the original ciphertext encrypted by AES-GCM-256, extracts the symmetric working key from memory, obtains the hardware fingerprint abbreviation of the current client, and uses the AES-GCM-256 decryption algorithm to decrypt the original ciphertext, while verifying the legality of the authentication tag during the decryption process; If the decryption process proceeds without errors and restores the original data in standard JSON format, the decryption verification is considered successful, and the restored original data is returned to the business layer to complete the entire data reading verification process. If the decryption process encounters an error, the decryption verification is considered unsuccessful, and a tampering response policy is triggered.

7. The method according to claim 6, characterized in that, Also includes: For the handling of the abnormal data, a silent cleanup operation is performed on the three-element structured JSON data that fails any one of the verifications. The abnormal data is deleted by using the removeItem method of localStorage to prevent the abnormal data from being called by the business layer, and the signature cache corresponding to the abnormal data is cleared to prevent cache pollution. The tampering event is logged, and the log entries include at least one of the following: the time of the tampering event, the stored data key name, the verification failure type, the client hardware fingerprint, the current key version, the time difference corresponding to the failure of the timestamp validity verification, and the signature comparison difference bit; the log data is encrypted using AES-GCM and stored in the temporary memory of the front end. The key log information of the tampering event is encrypted and reported to the backend monitoring platform via HTTPS protocol, so that the monitoring platform can perform real-time alerts and statistics based on the key log information; the reported data includes at least one of the following: event unique identifier, failure type, and occurrence time; If the determination is that the signature verification or decryption fails, the symmetric working key in the memory of the current front-end is cleared, and the key emergency update process is triggered to apply for a new symmetric working key from the front-end. At the same time, all signature caches of the front-end are cleared and the verification environment is reinitialized. If the same client fails to sign or decrypt more than a specified number of times within a third specified time period, it is determined to be a high-risk tampering attack, and a user identity re-authentication process is triggered. The local business operation permissions of the client corresponding to the current user are frozen until the current user completes mobile phone verification code, SMS verification or biometric verification. After successful verification, the permissions are restored and the key is reissued.

8. A browser-side data processing device, characterized in that, include: The generation module is used to generate an initialized symmetric working key through the backend corresponding to the browser client; An encryption module is used to respond to the startup of a client web application by transmitting a key request to the front end corresponding to the browser, and when the back end receives the key request, encrypting the symmetric working key using the RSA asymmetric encryption algorithm to generate encrypted key ciphertext, and transmitting the key ciphertext to the front end. The decryption module is used to respond to the front end receiving the key ciphertext, and to decrypt the key using the RSA decryption logic built into the front end to obtain a usable symmetric working key; the RSA decryption logic is matched with the RSA private key of the back end; A storage module is used to store the available symmetric working key in the memory of the front end in a memory-only pure memory storage mode to prevent the available symmetric working key from being written to any disk-level storage medium other than the memory of the front end. The binding module is used to build a memory isolation sandbox through the WeakMap feature and bind the available symmetric working key to the independent context of the front-end window object so that the available symmetric working key is only invoked within the specified application execution context.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

Images