System and method for preventing API (Application Program Interface) request forgery at browser side

Abstract

The invention discloses a system for preventing an API (Application Program Interface) request from being counterfeited at a browser end, comprising a Web application module which is used for docking with a server end application program, sending and receiving an API request, processing security verification and loading service data; the security component module is used for providing a dynamic key, a national cryptographic algorithm and extension of the national cryptographic algorithm; and the business core module comprises a request processing component, a business logic component, a data storage component and a log recording component. Dependence on specific hardware equipment is not needed, the cost is reduced, and user operation is facilitated; a service message is encrypted and decrypted between a server side and a browser side by setting a national cryptographic algorithm, so that the system has relatively high security and autonomous controllability; a one-time pad dynamic key management mechanism is set to be matched with a national secret algorithm, so that key leakage and replay attack can be effectively prevented.

Description

Technical Field

[0001] The present invention relates to a system and method for preventing API request forgery, and in particular to a system and method for preventing API request forgery on a browser side. Background Art

[0002] With the development of Internet technology, API (Application Programming Interface) is widely used in various application systems to realize data interaction and function call between different systems; however, there are many security issues with API requests;

[0003] 1. Currently, many enterprises have adopted authentication mechanisms based on hardware security modules, such as Token, USBKey and dynamic token, to improve the security of API requests. These hardware security modules verify the legitimacy of API requests by storing keys and executing encryption algorithms. For example, banks use USBKey in online banking systems, and users need to insert USBKey and enter passwords when making transactions to ensure that transaction requests come from legitimate users. However, this method has high hardware costs, including hardware equipment procurement costs, distribution costs and management costs, and different hardware equipment has compatibility issues on different operating systems and browsers, requiring a lot of adaptation work. At the same time, the update and maintenance of hardware equipment is relatively complicated, requiring users to manually update drivers or replace equipment, which brings inconvenience to users.

[0004] Second, API request authentication is performed through the Token authentication mechanism, which verifies the user's identity by carrying a token in the request. However, if the Token is obtained by an attacker, the attacker can forge API requests and impersonate a legitimate user to perform operations. In the browser environment, the security of the Token authentication mechanism is more vulnerable because the application logic and key information can be easily analyzed and obtained by attackers. For example, attackers can obtain the Token through malicious scripts or network monitoring, and then use the Token to send forged API requests to steal data or perform malicious operations.

[0005] 3. During the API request process, the security of data transmission is of vital importance. Traditional encryption methods may not be able to effectively prevent man-in-the-middle attacks and replay attacks. Man-in-the-middle attacks refer to attackers intercepting and tampering with data between communicating parties, while replay attacks refer to attackers repeatedly sending legitimate API requests to obtain illegal benefits. When keys are not managed properly, such as when keys remain unchanged for a long time or are stored insecurely, it is easy to cause key leakage, thereby endangering the security of the entire system. For example, in the internal systems of some enterprises, due to chaotic key management, attackers can decrypt data and perform malicious operations after obtaining keys. Summary of the invention

[0006] In order to solve the deficiencies of the above-mentioned technologies, the present invention provides a system and method for preventing API request forgery on a browser side.

[0007] In order to solve the above technical problems, the technical solution adopted by the present invention is: a browser-side system for preventing API request forgery, including a Web application module, which is used to implement a unified module based on JavaScript, connect with a server-side application, send and receive API requests, and process security verification and load service data;

[0008] Security component module, used to provide dynamic keys, national secret algorithms and extensions of national secret algorithms; extensions of national secret algorithms include public key exchange, data encryption and decryption, key protection, signature verification, uniqueness verification and timeliness verification;

[0009] The business core module includes a request processing component for processing API requests; a business logic component for executing specific business logic; a data storage component for storing various parameters and data; and a logging component for recording API operation logs.

[0010] A method for preventing API request forgery on a browser side, specifically comprising the following steps:

[0011] Step S1: The browser initiates a request without parameters, and the server generates API verification parameters;

[0012] Step S2: The browser verifies whether the interaction parameters at both ends are legal based on the dynamic key and the national encryption algorithm, and sends an API verification request;

[0013] Step S3: The server accepts and processes the verification request, decrypts the messages at both ends based on the dynamic key and the national encryption algorithm, and the API performs legal verification of the interaction parameters; if the interaction parameters are verified to be legal, the message is logically processed, otherwise, an exception code is returned and the process ends;

[0014] Step S4: The browser executes the decrypted and logically processed service message;

[0015] Step S5: destroy the public key and private key in the dynamic key, and clear the cache data on the browser side;

[0016] Step S6: Use an asynchronous processing mechanism to record the full API operation log.

[0017] Furthermore, step S1 specifically includes the following steps:

[0018] Step S11: The browser initiates a request without parameters;

[0019] Step S12: The server accepts the request without parameters from the browser; the server automatically generates a one-time SM2 public key public Key1 and a private key private Key1; calls SM3 to calculate the hash value of the UUID and the current timestamp to generate a random sequence serialCode to ensure the uniqueness of the random sequence and prevent replay attacks;

[0020] Step S13: Use SM4 to encrypt the server private key private Key1 into private Key1_SM4; put serialCode and private Key1_SM4 into the server Redis for caching;

[0021] Step S14: The server returns public Key1 and serialCode to the browser.

[0022] Furthermore, the encryption key of SM4 in step S13 is generated periodically by the server and protected by the Spring Security security mechanism.

[0023] Furthermore, in step S13, the server accesses the server Redis through a high-strength password and a whitelist.

[0024] Furthermore, the interaction parameters in step S2 include a random sequence, a timestamp, a public key and a signature value.

[0025] Furthermore, in step S2, the interaction parameters of both ends are verified based on the dynamic key and the national secret algorithm, which specifically includes the following steps:

[0026] Step S21: The browser receives the message and submits data preparation:

[0027] Step S22: using the received public Key1 to encrypt the service message;

[0028] Step S23: Encrypt the current timestamp using the accepted public Key1;

[0029] Step S24: The browser generates a one-time SM2 public key public Key2 and a private key private Key2;

[0030] Step S25: Use the private key private Key2 to sign the encrypted service message in step S22 and obtain the signature value;

[0031] Step S26: The browser initiates a request and sends the encrypted timestamp, serialCode, public Key2, the encrypted business message in step S22, and the signature value to the server.

[0032] Furthermore, in step S3, the API performs legal verification of the interaction parameters, which specifically includes the following steps:

[0033] Step S31: The server performs the first phase of verification, that is, the server accepts the request and determines whether the request parameter format, signature value, serialCode and cache time are legal. If not, an exception Code is returned;

[0034] Step S32: The server performs the second stage verification, i.e., uses SM4 and SM4 periodic encryption key to decrypt privateKey1_SM4 to obtain private Key1, and uses private Key1 to decrypt the timestamp to verify the legitimacy of the timestamp; if it is not legal, it returns an exception code and ends; if it is legal, it executes step S33;

[0035] Step S33: The server performs the third stage of verification, i.e., uses private Key1 to decrypt the service message and verify the legitimacy of the service message; if it is not legal, an exception code is returned and the process ends; if it is legal, step S34 is executed;

[0036] Step S34: the server performs business logic processing on the decrypted business message;

[0037] Step S35: Use public Key2 to encrypt the logically processed business message, and use privateKey1 to sign the encrypted business message after the logical processing, that is, the ciphertext, to obtain the ciphertext signature;

[0038] Step S36: The server returns the request and returns the encrypted business message and ciphertext signature after logical processing to the browser.

[0039] Further, step S31 specifically includes the following steps:

[0040] Step S31-1: The server accepts the request and determines whether the request parameter format is legal. If not, an exception code is returned and the process ends. If legal, the process proceeds to step S31-2:

[0041] Step S31-2: The server determines whether the signature value obtained by signing the encrypted service message using the private key private Key2 is legal. If it is illegal, an exception code is returned and the process ends; if it is legal, step S31-3 is performed;

[0042] Step S31-3: The server determines whether the random sequence serialCode is legal. If not, an exception code is returned and the process ends. If legal, the server proceeds to step S31-4.

[0043] Step S31-4: Get private Key1_SM4 in the cache through serialCode, and determine whether the cache is expired. If the cache is expired, it is illegal, and an exception code is returned and the process ends; if the cache is not expired, it is legal, and step S32 is executed.

[0044] Furthermore, the decrypted and logically processed service message in step S4 specifically includes the following steps:

[0045] Step S41: The browser receives the message and uses public Key1 to verify the ciphertext signature. If the verification is illegal, the failure reason is recorded and the process ends; if the verification is legal, step S42 is executed;

[0046] Step S42: after verification, use private Key2 to decrypt the encrypted service message after logical processing;

[0047] Step S43: Process the service data in the service message.

[0048] The present invention discloses a system and method for preventing API request forgery on a browser side, which has the following beneficial effects:

[0049] 1. No need to rely on specific hardware devices, no need to update and maintain hardware devices, which reduces costs and facilitates user operation; the browser side implements a unified module based on JavaScript, achieving compatibility across operating system platforms and different browsers, which is easy to promote and use;

[0050] Second, by setting up the national secret algorithm to encrypt and decrypt business messages between the server and the browser, the system has high security and autonomous controllability, can resist a variety of attack methods, and can increase the difficulty of reverse attacks through code obfuscation and other means;

[0051] 3. By setting up a one-time dynamic key management mechanism and cooperating with the national secret algorithm, a new public and private key pair is generated for each API request, which can effectively prevent key leakage and replay attacks and ensure secure and reliable data transmission. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 1 It is a structural diagram of the present invention.

[0053] Figure 2 It is a flow chart of the present invention.

[0054] Figure 3 It is an interaction diagram between the browser end and the server end in the present invention. DETAILED DESCRIPTION

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

[0056] Embodiment 1:

[0057] like Figures 1 to 3 A browser-side system for preventing API request forgery is shown, including a Web application module, which is used to implement a unified module based on JavaScript, connect with a server-side application, send and receive API requests, and process security verification and load service data; that is, the national encryption suite, security verification and business processing are implemented on the browser side;

[0058] The security component module is used to provide dynamic keys, national secret algorithms and extensions of national secret algorithms, namely encryption components and rule components; the extensions of national secret algorithms include public key exchange, data encryption and decryption, key protection, signature verification, uniqueness verification and timeliness verification;

[0059] The business core module includes a request processing component, which is used by the server Redis to process API requests; a business logic component, which is used to execute specific business logic; a data storage component DB, which is used to store various parameters and data; and a logging component, which is used to record API operation logs.

[0060] A method for preventing API request forgery on a browser side, specifically comprising the following steps:

[0061] Step S1: The server generates the required parameters for API verification; including the following steps:

[0062] Step S11: The browser initiates a request without parameters;

[0063] Step S12: The server accepts the request without parameters from the browser; the server automatically generates a one-time SM2 public key public Key1 and a private key private Key1; calls SM3 to calculate the hash value of the UUID and the current timestamp to generate a random sequence serialCode to ensure the uniqueness of the random sequence and prevent replay attacks;

[0064] Step S13: Use SM4 to encrypt the server private key private Key1 into private Key1_SM4; the encryption key of SM4 is generated regularly by the server and protected by the Spring Security security mechanism; put serialCode and private Key1_SM4 into the server Redis for caching, where the cache validity is configured according to the parameter setting, and the default value in this embodiment is 5 seconds; the server accesses the server Redis through a high-strength password and a whitelist;

[0065] Step S14: The server returns public Key1 and serialCode to the browser;

[0066] National secret algorithms refer to domestic cryptographic algorithms, which include SM2, SM3 and SM4. SM2 is used for key pair generation, digital signature and public key encryption. SM3 is used to calculate hash values, such as the calculation when generating random sequence serialCode. SM4 is used to encrypt and decrypt data, such as encrypting the server private key.

[0067] A one-time dynamic key management mechanism is adopted, and a new public-private key pair is generated for each API request. On the server side, the SM2 public-private key pair is randomly generated, and the private key is encrypted and stored in combination with the SM4 encryption algorithm to ensure the security of the key; at the same time, a shorter key cache period is set to further reduce the risk of key leakage.

[0068] Step S2: The browser verifies whether the interaction parameters between the two ends are legal based on encryption rules and requests API verification. The interaction parameters include random sequence, timestamp, public key and signature. The specific steps include:

[0069] Step S21: The browser receives the message and submits data preparation:

[0070] Step S22: using the received public Key1 to encrypt the service message;

[0071] Step S23: Encrypt the current timestamp using the accepted public Key1;

[0072] Step S24: The browser generates a one-time SM2 public key public Key2 and a private key private Key2;

[0073] Step S25: Use the private key private Key2 to sign the encrypted service message in step S22 and obtain the signature value;

[0074] Step S26: The browser initiates a request and sends the encrypted timestamp, serialCode, public Key2, the encrypted business message in step S22, and the signature value to the server.

[0075] Step S3: The server accepts and processes the request, decrypts the messages at both ends based on the encryption rules, and the API performs legal verification of the interaction parameters; specifically, the following steps are included:

[0076] Step S31: The server performs the first phase of verification, that is, the server accepts the request and determines whether the request parameter format, signature value, serialCode and cache time are legal. If not, an abnormal Code is returned; including the following steps:

[0077] Step S31-1: The server accepts the request and determines whether the request parameter format is legal. If not, an exception code is returned and the process ends. If legal, the process proceeds to step S31-2:

[0078] Step S31-2: The server determines whether the signature value obtained by signing the encrypted service message using the private key private Key2 is legal. If it is illegal, an exception code is returned and the process ends; if it is legal, step S31-3 is performed;

[0079] Step S31-3: The server determines whether the random sequence serialCode is legal. If not, an exception code is returned and the process ends. If legal, the server proceeds to step S31-4.

[0080] Step S31-4: Get private Key1_SM4 in the cache through serialCode, and determine whether the cache is expired. If the cache is expired, it is illegal, and an exception code is returned and the process ends; if the cache is not expired, it is legal, and step S32 is executed;

[0081] Step S32: The server performs the second stage verification, i.e., uses SM4 and SM4 periodic encryption key to decrypt privateKey1_SM4 to obtain private Key1, and uses private Key1 to decrypt the timestamp to verify the legitimacy of the timestamp; if it is not legal, it returns an exception code and ends; if it is legal, it executes step S33;

[0082] Step S33: The server performs the third stage of verification, i.e., uses private Key1 to decrypt the service message and verify the legitimacy of the service message; if it is not legal, an exception code is returned and the process ends; if it is legal, step S34 is executed;

[0083] Step S34: the server performs business logic processing on the decrypted business message;

[0084] Step S35: Use public Key2 to encrypt the logically processed business message, and use privateKey1 to sign the encrypted business message after the logical processing, that is, the ciphertext, to obtain the ciphertext signature;

[0085] Step S36: The server returns the request and returns the encrypted business message and ciphertext signature after logical processing to the browser.

[0086] Among them, the browser and the server encrypt and verify the signature of the business message and key information during the data transmission process; the browser uses the public key provided by the server to encrypt the business message and timestamp, and uses the private key generated by itself to sign the business message; after receiving the request, the server performs signature verification, timestamp verification, message decryption and business processing in sequence, and encrypts and signs it after the processing is completed and returns it to the browser.

[0087] Step S4: The browser executes the decrypted and logically processed service message; specifically, the following steps are included:

[0088] Step S41: The browser receives the message and uses public Key1 to verify the ciphertext signature. If the verification is illegal, the failure reason is recorded and the process ends; if the verification is legal, step S42 is executed;

[0089] Step S42: after verification, use private Key2 to decrypt the encrypted service message after logical processing;

[0090] Step S43: Processing the service data in the service message;

[0091] Step S44: destroy the public key and private key, and clear the cache data on the browser side.

[0092] Step S5: Use an asynchronous processing mechanism to record the full API operation log.

[0093] The present invention is based on software implementation and does not rely on specific hardware devices, which greatly reduces costs. At the same time, by using JavaScript on the browser side to achieve module unification, it achieves compatibility across operating system platforms and different browsers, which is easy to promote and use.

[0094] At the same time, compared with the traditional Token authentication mechanism and software encryption scheme, the present invention significantly improves security through the dynamic key management mechanism and the application of the national secret algorithm. The dynamic key is updated every time it is requested, which effectively prevents key leakage and replay attacks; the national secret algorithm has high security and autonomous controllability, and can resist a variety of attack methods, especially in the white-box attack environment, through code obfuscation and other means to increase the difficulty of reverse attack. White-box attack means that the attacker fully connects the internal structure, parameters, algorithms, training data and other detailed information of the target model. In this situation, the attacker can directly use the internal information of the model to generate adversarial samples, thereby realizing the attack on the model.

[0095] The present invention minimizes the impact of encryption and decryption operations on system performance through reasonable architecture design and algorithm selection, achieving performance optimization while ensuring security. In actual tests, the performance loss of API requests in the encrypted state is within an acceptable range, with little impact on the normal operation of users, ensuring a good user experience.

[0096] Embodiment 2:

[0097] This embodiment is a system and method for preventing API request forgery on a browser side, and provides a method for preventing API request forgery in an online banking system in the financial field, specifically comprising the following steps:

[0098] Step A1: In the online banking system, during the user login phase, the browser first initiates a parameter-free request to the server;

[0099] Step A2: After receiving the request, the server quickly generates a one-time SM2 public key public Key1A and private key private Key1A, and calls SM3 according to specific rules to calculate the hash value of the UUID and the current timestamp to generate a random sequence serialCode_A;

[0100] Step A3: Use the SM4 encryption algorithm to encrypt private Key1A into private Key1A_SM4. The encryption key is generated regularly by the server and strictly protected with the help of Spring Security security mechanism. At the same time, serialCode_A and private Key1A_SM4 are stored in the server Redis cache. The default cache validity period is set to 5 seconds.

[0101] Step A4: The server returns public Key1A and serialCode_A to the browser;

[0102] Step A5: When the user performs a transfer operation, the browser uses the received public Key1A to encrypt the message containing key business information such as the transfer amount, the receiving account number, the transfer notes, and the current timestamp;

[0103] Step A6: The browser generates a one-time SM2 public key public Key2A and a private key private Key2A, and uses private Key2A to sign the encrypted service message to obtain a signature value;

[0104] Step A7: Send the encrypted timestamp, serialCode_A, public Key2A, encrypted service message and signature value to the server;

[0105] Step A8: After receiving the request, the server enters a multi-stage verification process; checks the verification request parameter format, signature value, serialCode and cache time validity in turn to see if they are legal. If there are illegal parameters, the corresponding error code can be returned; uses the SM4 encryption key to decrypt private Key1A_SM4 to obtain private Key1A, and then uses privateKey1A to decrypt the timestamp to verify the legitimacy of the timestamp to ensure that the request has not been subjected to a replay attack; uses private Key1A to decrypt the business message and verify the legitimacy of the business message to prevent data tampering; after the multi-stage verification process is completed and all are legal, the server performs transfer business logic processing on the encrypted business message, such as checking whether the user account balance is sufficient, verifying whether the receiving account is valid, etc.;

[0106] Step A9: Use public Key2A to encrypt the logically processed business message, use privateKey1A to sign it, and return the logically processed encrypted business message and its signature to the browser;

[0107] Step A10: After receiving the data returned by the server, the browser uses public Key1A to verify its signature. If the verification fails, a corresponding error code is returned. If the verification passes, it indicates that the data has not been tampered with during transmission and the source is reliable.

[0108] Step A11: After the signature verification is passed, the browser uses private Key2A to decrypt the encrypted business message after logical processing, obtains information such as the transfer result, and displays it to the user;

[0109] Step A12: Destroy the public key and private key used in this operation, and clear the browser cache data to ensure security.

[0110] The present invention effectively prevents attackers from forging transfer requests in the application of online banking systems, thus greatly ensuring the financial security of users.

[0111] Embodiment three:

[0112] This embodiment provides a system and method for preventing API request forgery on a browser side and provides a method for managing electronic medical records in the medical and health field, which specifically includes the following steps:

[0113] Step B1: When a doctor uses the electronic medical record management system to view the patient's medical record, the browser sends a non-parameter request to the server;

[0114] Step B2: After receiving the request, the server quickly generates a one-time SM2 public key public Key1B and private key private Key1B, and calls SM3 according to specific rules to calculate the hash value of the UUID and the current timestamp to generate a random sequence serialCode_B;

[0115] Step B3: Use the SM4 encryption algorithm to encrypt private Key1B into private Key1B_SM4. The encryption key is generated regularly by the server and strictly protected with the help of Spring Security security mechanism. At the same time, serialCode_B and private Key1B_SM4 are stored in the server Redis cache. The default cache validity period is set to 5 seconds.

[0116] Step B4: The server returns public Key1B and serialCode_B to the browser;

[0117] Step B5: When the browser is ready to view the medical records of a specific patient, it uses the received public Key1B to encrypt the service message containing the patient medical record query request information, such as the patient ID, query time period, etc. and the current timestamp;

[0118] Step B6: The browser generates a one-time SM2 public key public Key2B and a private key private Key2B, and uses private Key2B to sign the encrypted service message to obtain a signature value;

[0119] Step B7: Send the encrypted timestamp, serialCode_B, public Key2B, encrypted service message and signature value to the server;

[0120] Step B8: After the server accepts the request, it verifies the request parameter format, signature value, serialCode_B and cache time limit in turn; uses the SM4 encryption key to decrypt private Key1B_SM4 to obtain private Key1B, and then uses private Key1B to decrypt the timestamp to verify the legitimacy of the timestamp to ensure that the request has not been subjected to a replay attack; uses private Key1B to decrypt the business message and verify the legitimacy of the business message; after confirmation, performs medical record query business processing and retrieves the corresponding medical record information from the database;

[0121] Step B9: Use public Key2B to encrypt the logically processed business message, use privateKey1B to sign it, and return the logically processed encrypted business message and its signature to the browser;

[0122] Step B10: After receiving the data returned by the server, the browser uses public Key1B to verify the signature; if the verification fails, a corresponding error code is returned; if the verification passes, step B11 is executed;

[0123] Step B11: After the signature verification is passed, the browser uses private Key2B to decrypt the encrypted business message after logical processing, obtains the medical record data and displays it to the doctor;

[0124] Step B12: Destroy the public key and private key used in this operation, and clear the browser cache data to ensure security.

[0125] Among them, when updating medical records, the browser also encrypts, signs and sends the business message containing the update content. The server returns the update result after verification, ensuring that the patient's medical record data is effectively protected during transmission and preventing medical record leakage and tampering.

[0126] Embodiment 4:

[0127] This embodiment provides a system and method for preventing API request forgery on a browser side and provides a data sharing method in an enterprise-level application system. The process of the sales department providing sales data to the finance department specifically includes the following steps:

[0128] Step C1: The browser used by the sales department employee initiates a parameter-free request to the enterprise server;

[0129] Step C2: After receiving the request, the server quickly generates a one-time SM2 public key public Key1C and private key private Key1C, and calls SM3 according to specific rules to calculate the hash value of the UUID and the current timestamp to generate a random sequence serialCode_C;

[0130] Step C3: Use the SM4 encryption algorithm to encrypt private Key1C into private Key1C_SM4. The encryption key is generated regularly by the server and strictly protected with the help of Spring Security security mechanism. At the same time, serialCode_C and private Key1C_SM4 are stored in the server Redis cache. The default cache validity period is set to 5 seconds.

[0131] Step C4: The server returns public Key1C and serialCode_C to the browser;

[0132] Step C5: When the sales department submits sales data through the browser, it uses the received public Key1C to encrypt the business message and timestamp containing sales order details, sales amount, customer information, etc.;

[0133] Step C6: The browser generates a one-time SM2 public key public Key2C and a private key private Key2C, and uses private Key2C to sign the encrypted service message to obtain a signature value;

[0134] Step C7: Send the encrypted timestamp, serialCode_C, public Key2C, encrypted service message and signature value to the server;

[0135] Step C8: After receiving the request, the server verifies the request parameter format, signature value, serialCode_C and cache expiration in turn; uses the SM4 encryption key to decrypt private Key1C_SM4 to obtain private Key1C, and then uses private Key1C to decrypt the timestamp to verify the legitimacy of the timestamp and ensure that the request has not been subjected to a replay attack; uses private Key1C to decrypt the business message and verify the legitimacy of the business message; integrates and counts the sales data, such as calculating the total sales amount and analyzing sales trends;

[0136] Step C9: Use public Key2C to encrypt the logically processed business message, use privateKey1C to sign it, and return the logically processed encrypted business message and its signature to the browser;

[0137] Step C10: After receiving the data returned by the server through the browser, the finance department uses publicKey1C to verify the signature; if the signature verification fails, the corresponding error code is returned; if the signature verification passes, step C11 is executed;

[0138] Step C11: After the signature verification is passed, the browser uses private Key2C to decrypt the encrypted business message after logical processing and obtain sales data for financial accounting and other tasks;

[0139] Step C12: Destroy the public key and private key used in this operation, and clear the browser cache data to ensure security.

[0140] This method ensures the security of data transmission between different departments within the enterprise, prevents data from being illegally obtained or tampered with during the sharing process, and effectively protects the security of enterprise data and the normal operation of the business.

[0141] The above implementation modes are not limitations of the present invention, and the present invention is not limited to the above examples. Changes, modifications, additions or substitutions made by technicians in this technical field within the scope of the technical solution of the present invention also belong to the protection scope of the present invention.

Claims

1. A browser-side system for preventing API request forgery, characterized in that: Includes a web application module that implements a unified module based on JavaScript, connects to the server application, sends and receives API requests, and handles security verification and loading service data; Security component module, used to provide dynamic keys, national secret algorithms and extensions of national secret algorithms; extensions of national secret algorithms include public key exchange, data encryption and decryption, key protection, signature verification, uniqueness verification and timeliness verification; The business core module includes a request processing component for processing API requests; a business logic component for executing specific business logic; a data storage component for storing various parameters and data; and a logging component for recording API operation logs.

2. A method for preventing API request forgery on a browser side, applied to the system for preventing API request forgery on a browser side as claimed in claim 1, characterized in that: The specific steps include: Step S1: The browser initiates a request without parameters, and the server generates API verification parameters; Step S2: The browser verifies whether the interaction parameters at both ends are legal based on the dynamic key and the national encryption algorithm, and sends an API verification request; Step S3: The server accepts and processes the verification request, decrypts the messages at both ends based on the dynamic key and the national encryption algorithm, and the API performs legal verification of the interaction parameters; if the interaction parameters are verified to be legal, the message is logically processed, otherwise, an exception code is returned and the process ends; Step S4: The browser executes the decrypted and logically processed service message; Step S5: destroy the public key and private key in the dynamic key, and clear the cache data on the browser side; Step S6: Use an asynchronous processing mechanism to record the full API operation log.

3. The method for preventing API request forgery on the browser side according to claim 2, characterized in that: The step S1 specifically comprises the following steps: Step S11: The browser initiates a request without parameters; Step S12: The server accepts the request without parameters from the browser; the server automatically generates a one-time SM2 public key publicKey1 and a private key private Key1; calls SM3 to calculate the hash value of the UUID and the current timestamp to generate a random sequence serialCode to ensure the uniqueness of the random sequence and prevent replay attacks; Step S13: Use SM4 to encrypt the server private key private Key1 into private Key1_SM4; put serialCode and private Key1_SM4 into the server Redis for caching; Step S14: The server returns public Key1 and serialCode to the browser.

4. The method for preventing API request forgery on the browser side according to claim 3, characterized in that: The encryption key of SM4 in step S13 is generated regularly by the server and protected by the Spring Security security mechanism.

5. The method for preventing API request forgery on the browser side according to claim 4, characterized in that: In step S13, the server accesses the server Redis through a high-strength password and a whitelist.

6. The method for preventing API request forgery on the browser side according to claim 5, characterized in that: The interaction parameters in step S2 include a random sequence, a timestamp, a public key and a signature value.

7. The method for preventing API request forgery on the browser side according to claim 6, characterized in that: The step S2 obtains the interaction parameters of both ends based on the dynamic key and the national secret algorithm to verify the interaction parameters, which specifically includes the following steps: Step S21: The browser receives the message and submits data preparation: Step S22: using the received public Key1 to encrypt the service message; Step S23: Encrypt the current timestamp using the accepted public Key1; Step S24: The browser generates a one-time SM2 public key public Key2 and a private key private Key2; Step S25: Use the private key private Key2 to sign the encrypted service message in step S22 and obtain the signature value; Step S26: The browser initiates a request and sends the encrypted timestamp, serialCode, public Key2, the encrypted business message in step S22, and the signature value to the server.

8. The method for preventing API request forgery on the browser side according to claim 7, characterized in that: In step S3, the API performs legal verification of interaction parameters, which specifically includes the following steps: Step S31: The server performs the first phase of verification, that is, the server accepts the request and determines whether the request parameter format, signature value, serialCode and cache time are legal. If not, an exception Code is returned; Step S32: The server performs the second stage verification, i.e., uses SM4 and SM4 periodic encryption key to decrypt privateKey1_SM4 to obtain private Key1, and uses private Key1 to decrypt the timestamp to verify the legitimacy of the timestamp; if it is not legal, it returns an exception code and ends; if it is legal, it executes step S33; Step S33: The server performs the third stage of verification, i.e., uses private Key1 to decrypt the service message and verify the legitimacy of the service message; if it is not legal, an exception code is returned and the process ends; if it is legal, step S34 is executed; Step S34: the server performs business logic processing on the decrypted business message; Step S35: Use public Key2 to encrypt the logically processed business message, and use private Key1 to sign the encrypted business message after the logical processing, that is, the ciphertext, to obtain the ciphertext signature; Step S36: The server returns the request and returns the encrypted business message and ciphertext signature after logical processing to the browser.

9. The method for preventing API request forgery on the browser side according to claim 8, characterized in that: The step S31 specifically includes the following steps: Step S31-1: The server accepts the request and determines whether the request parameter format is legal. If not, an exception code is returned and the process ends. If legal, the process proceeds to step S31-2: Step S31-2: The server determines whether the signature value obtained by signing the encrypted service message using the private key private Key2 is legal. If it is illegal, an exception code is returned and the process ends; if it is legal, step S31-3 is performed; Step S31-3: The server determines whether the random sequence serialCode is legal. If not, an exception code is returned and the process ends. If legal, the server proceeds to step S31-4. Step S31-4: Get private Key1_SM4 in the cache through serialCode, and determine whether the cache is expired. If the cache is expired, it is illegal, and an exception code is returned and the process ends; if the cache is not expired, it is legal, and step S32 is executed.

10. The method for preventing API request forgery on the browser side according to claim 9, characterized in that: The step S4 executes the decrypted and logically processed service message, specifically comprising the following steps: Step S41: The browser receives the message and uses public Key1 to verify the ciphertext signature. If the verification is illegal, the failure reason is recorded and the process ends; if the verification is legal, step S42 is executed; Step S42: after verification, use private Key2 to decrypt the encrypted service message after logical processing; Step S43: Process the service data in the service message.

Images