Enhanced JavaWeb security communication method and system

Abstract

The embodiment of the invention provides an enhanced JavaWeb security communication method and system, and belongs to the technical field of communication. The method comprises the following steps: a user submits a data request, and a front end assembles the user request into four groups of parameters, namely a service parameter, a timestamp, a request id and an Authorize; under the condition that encryption is needed, calling a back-end interface to obtain an SM2 key pair so as to perform encryption processing on the four groups of parameters, and sending the encrypted data to a back end for request processing; the back-end gateway receives the request, performs security check on the encrypted data, and distributes the data to the micro-service for request processing after the security check is passed; the back end encrypts data returned after the micro-service processing request is processed, and sends the encrypted data to the front end; and the front end carries out security check on the encrypted data and then carries out page rendering according to the returned data. According to the method, anti-theft, anti-tampering, anti-replaying and safe tracking can be carried out on the communication message, so that safe JavaWeb communication is realized.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to an enhanced JavaWeb security communication method and system. Background Art

[0002] In 1989, the first successful communication between a Hypertext Transfer Protocol (HTTP) client and server over the Internet was achieved.

[0003] In 1990, the world's first Web server and Web browser were successfully developed.

[0004] In 1991, the system was ported to other computer platforms and officially released. HTML, HTTP, URI, browser, and Web server were invented.

[0005] Today, the Web has become a global, dynamic, interactive, cross-platform distributed graphic information system based on hypertext and HTTP, and a network service built on the Internet. With the widespread use of the Internet, Web applications have been integrated into all aspects of daily life, such as online shopping, online banking applications, securities and stock trading, government administrative approval, etc.

[0006] As web applications continue to develop, web communication security is becoming more and more important. Web secure communication refers to ensuring the security and confidentiality of data during transmission in an Internet environment by using encryption, authentication, integrity protection and other means. Common web secure communication protocols include application security module coding, HTTPS, SSL / TLS, etc. These protocols can prevent data from being eavesdropped, tampered with and forged, and protect user privacy and transaction security. In the prior art, web communication security cannot be guaranteed under the http communication protocol, so an enhanced JavaWeb secure communication method is needed. Summary of the invention

[0007] The purpose of the embodiments of the present invention is to provide an enhanced JavaWeb secure communication method and system, which can prevent theft, tampering, replay, and secure tracking of communication messages, thereby achieving secure JavaWeb communication.

[0008] In order to achieve the above object, an embodiment of the present invention provides an enhanced JavaWeb security communication method, the method comprising:

[0009] The user submits a data request, and the front end assembles the user request into four groups of parameters: business parameters, timestamp, request id, and Authorize;

[0010] If encryption is required, call the backend interface to obtain the SM2 key pair to encrypt the four sets of parameters, and send the encrypted data to the backend for request processing;

[0011] The backend gateway accepts the request and performs a security check on the encrypted data. After the security check passes, the data is distributed to the microservice for request processing.

[0012] The backend encrypts the data returned by the microservice after processing the request and sends the encrypted data to the frontend;

[0013] After the front end performs a security check on the encrypted data, it renders the page based on the returned data to complete the user's request response.

[0014] Optionally, if encryption is required, the backend interface is called to obtain the SM2 key pair to encrypt the four sets of parameters, and the encrypted data is sent to the backend for request processing, including:

[0015] Request a key pair from the server, where the public key is used for data encryption and the private key is used for data signing;

[0016] Reference the sm2 module in the sm-crypto library, use the sm2.doEncrypt method in the sm2 module and the public key to encrypt the four sets of parameters to obtain encrypted data;

[0017] Use the sm2.doSignature method and the private key to sign the encrypted data to obtain a signature value;

[0018] Send the encrypted data and signature value to the backend for request processing.

[0019] Optionally, the backend gateway accepts the request and performs a security check on the encrypted data. After the security check passes, the data is distributed to the microservice for request processing, including:

[0020] Obtain the encrypted data and signature value, and obtain a key pair from a database, wherein the public key contained in the key pair is used for data signature verification, and the private key of the key pair is used for data decryption;

[0021] Get two numbers r and s from the signature value, and then calculate the new R value through the sm2 module and the public key;

[0022] Compare the calculated R value with the r value in the signature value to verify whether the signature is legitimate;

[0023] If the signature verification fails, it indicates that the data has been tampered with, and an error message is returned to the front end, and the user is forced to log out. The tampering time is recorded in the exception log through log management.

[0024] When the signature result is verified, the encrypted data is decrypted through the sm2 module and the private key, and it is determined whether the decryption is successful;

[0025] In case of decryption failure, an error message is returned to the front end, the user is forced to log out, and the tampering event is recorded in the exception log through log management;

[0026] If the decryption is successful, the decrypted plaintext parameters are obtained.

[0027] Optionally, the backend gateway accepts the request and performs a security check on the encrypted data. After the security check passes, the data is distributed to the microservice for request processing, including:

[0028] Obtaining the plaintext parameter;

[0029] Filter and replace the plain text parameters through a special character library and a keyword library to obtain replaced parameters;

[0030] Determine whether there is a difference between the parameters after replacement and the parameters before replacement;

[0031] If there is a discrepancy, an error message is returned to the front end to inform that special characters exist, and the special character event is recorded in the exception log through log management;

[0032] In the case where there is no difference, it is determined that the plain text parameter does not have any special characters and the plain text parameter is safe.

[0033] Optionally, the backend gateway accepts the request and performs a security check on the encrypted data. After the security check passes, the data is distributed to the microservice for request processing, including:

[0034] The business parameters, timestamp, request id and Authorize of the decrypted data form a unique key for the Web request;

[0035] Determine whether the same key exists in the backend gateway's cache;

[0036] In the absence of existence, the key is put into the fetch cache and the data is distributed to the microservice for request processing;

[0037] If it exists, an error message is returned to the front end, prompting the user that the request is intercepted and replayed and the user is forced to log out, and the replay event is recorded in the exception log through log management.

[0038] Optionally, the backend encrypts the data returned after the microservice processes the request and sends the encrypted data to the frontend, including:

[0039] The backend receives the response data after the microservice processes the business data;

[0040] Identify sensitive fields such as mobile phone number, ID card, and email address in the response data and perform desensitization processing;

[0041] The special character library and keyword library filter the response data after desensitization processing;

[0042] After filtering is completed, the request id is obtained from the context and added to the response data.

[0043] Optionally, the backend encrypts the data returned after the microservice processes the request and sends the encrypted data to the frontend, including:

[0044] Get the supplemented response data;

[0045] The sm2 module encrypts the response data using the public key of the SM2 key pair to obtain ciphertext data;

[0046] The sm2 module uses the private key of the SM2 key pair to sign the ciphertext data to obtain the signature data;

[0047] After the operation is completed, the completed data will be responded to the front end.

[0048] Optionally, after the front end performs a security check on the encrypted data, it renders the page according to the returned data to complete the user's request response, including:

[0049] Get the encrypted response data;

[0050] The sm2 module calculates the signature of the response data using the public key to obtain the calculated value;

[0051] Determine whether the calculated value is the same as the signature data of the corresponding data to verify whether the signature is legal;

[0052] If the verification fails, the request will be stopped and a window will pop up, forcing the user to log out. The tampering time will be recorded in the exception log through log management.

[0053] In the same case, if the signature verification is successful, the sm2 module decrypts the ciphertext data through the private key and renders the decrypted data on the page to complete the user's request response.

[0054] On the other hand, the present invention also provides an enhanced JavaWeb security communication system, the system comprising:

[0055] The front-end module is used to receive user request data, encrypt the request data, and decrypt the returned response data to render the page according to the response data to complete the customer's request response;

[0056] The backend module receives the encrypted data, decrypts it after security verification, sends the decrypted data to the microservice module, and encrypts the returned response data;

[0057] The microservice module receives the decrypted data to complete the request and returns the response data to the backend module;

[0058] The exception log module records the abnormal situations in the data transmission process.

[0059] Through the above technical scheme, the present invention provides an enhanced JavaWeb security communication method and system. After the user submits a data request, the front end can assemble the user request into four groups of parameters: business parameters, timestamp, request id and Authorize. When encryption is required, the back-end interface can be called to obtain the SM2 key pair, so that the four groups of parameters can be encrypted, and the encrypted data can be sent to the back end for request processing. After receiving the request, the back-end gateway can perform a security check on the encrypted data. If the security check passes, the data can be divided into microservices for request processing. The microservice can process the data request for submission and return the processed data to the back end. The back end encrypts the data returned after the microservice processing and can send the encrypted data to the front end. After receiving the encrypted data and performing a security check, the front end can render the page according to the returned data, so as to complete the user's request response. The method can prevent the communication message from being stolen, tampered, replayed, and tracked securely, thereby realizing secure JavaWeb communication.

[0060] Other features and advantages of the embodiments of the present invention will be described in detail in the subsequent detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] The accompanying drawings are used to provide a further understanding of the embodiments of the present invention and constitute a part of the specification. Together with the following specific implementations, they are used to explain the embodiments of the present invention, but do not constitute a limitation on the embodiments of the present invention. In the accompanying drawings:

[0062] Figure 1 is a flow chart of an enhanced JavaWeb security communication method according to an embodiment of the present invention;

[0063] Figure 2is a flow chart of encrypting four groups of parameters according to an enhanced JavaWeb security communication method according to an embodiment of the present invention;

[0064] Figure 3 is a first flow chart of security check of an enhanced JavaWeb security communication method according to an embodiment of the present invention;

[0065] Figure 4 is a second flow chart of security check of an enhanced JavaWeb secure communication method according to an embodiment of the present invention;

[0066] Figure 5 is a third flow chart of security check of an enhanced JavaWeb security communication method according to an embodiment of the present invention;

[0067] Figure 6 It is a first flow chart of encrypting returned data by a back end of an enhanced JavaWeb security communication method according to an embodiment of the present invention;

[0068] Figure 7 is a second flow chart of encrypting returned data by a back end of an enhanced JavaWeb security communication method according to an embodiment of the present invention;

[0069] Figure 8 is a flowchart of decrypting returned data of an enhanced JavaWeb security communication method according to an embodiment of the present invention;

[0070] Fig. 9 The present invention is a front-end data encryption code according to an embodiment of the present invention. DETAILED DESCRIPTION

[0071] The specific implementation of the embodiment of the present invention is described in detail below in conjunction with the accompanying drawings. It should be understood that the specific implementation described here is only used to illustrate and explain the embodiment of the present invention, and is not used to limit the embodiment of the present invention.

[0072] It should be noted that the acquisition, transmission, storage, use, and processing of data in the technical solution of this application are in compliance with the relevant provisions of national laws and regulations. In the embodiments of this application, some existing solutions in the industry such as certain software, components, and models may be mentioned, which should be considered as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of this application, but it does not mean that the applicant has or will necessarily use the solution.

[0073] Figure 11 is a flow chart of an enhanced Java Web security communication method according to an embodiment of the present invention. In the present invention, the process of the method may include:

[0074] In step S1, the user submits a data request, and the front end assembles the user request into four groups of parameters: business parameters, timestamp, request id, and Authorize.

[0075] In step S2, if encryption is required, the backend interface is called to obtain the SM2 key pair to encrypt the four sets of parameters, and the encrypted data is sent to the backend for request processing.

[0076] In step S3, the backend gateway accepts the request and performs a security check on the encrypted data. After the security check passes, the data is distributed to the microservice for request processing.

[0077] In step S4, the backend encrypts the data returned after the microservice processing request is processed, and sends the encrypted data to the frontend.

[0078] In step S5, the front end performs a security check on the encrypted data and then renders the page according to the returned data to complete the user's request response.

[0079] Through the above technical scheme, the present invention provides an enhanced JavaWeb security communication method and system. After the user submits a data request, the front end can assemble the user request into four groups of parameters: business parameters, timestamp, request id and Authorize. When encryption is required, the back-end interface can be called to obtain the SM2 key pair, so that the four groups of parameters can be encrypted, and the encrypted data can be sent to the back end for request processing. After receiving the request, the back-end gateway can perform a security check on the encrypted data, and when the security check passes, the data can be distributed to the microservice for request processing. The microservice can process the data request for submission and return the processed data to the back end. The back end encrypts the data returned after the microservice processing and can send the encrypted data to the front end. After receiving the encrypted data and performing a security check, the front end can render the page according to the returned data, so as to complete the user's request response. The method can prevent the communication message from being stolen, tampered, replayed, and tracked securely, thereby realizing secure JavaWeb communication.

[0080] In one embodiment of the present invention, Figure 2 As shown, the process of encrypting four sets of parameters may include:

[0081] In step S6, a key pair is requested from the server, wherein the public key is used for data encryption and the private key is used for data signing.

[0082] In step S7, the sm2 module in the sm-crypto library is referenced, and the sm2.doEncrypt method in the sm2 module and the public key are used to encrypt the four groups of parameters to obtain encrypted data.

[0083] In step S8, the encrypted data is signed using the sm2.doSignature method and the private key to obtain a signature value.

[0084] In step S9, the encrypted data and signature value are sent to the backend for request processing.

[0085] In the present invention, a series of rigorous and standardized steps must be followed in the process of data encryption transmission at the front end to ensure the security and integrity of the data. When encrypting, it is necessary to obtain necessary information, which may include user login information. In the case of login, the authentication Token of the currently logged-in user is obtained from the local storage (sessionStorage). This Token is usually used to verify the identity of the user and authorize its access to specific resources. The Token is recorded as the parameter Authorize. Encryption identification: By obtaining the encryption communication configuration in the fixed value management function, the system communication mode is obtained to indicate whether the current environment communication requires data encryption. Business parameters: According to the business logic, collect and prepare the input parameters to be sent to the back end. Timestamp: Generate a timestamp of the current time (Unix timestamp) to identify the initiation time of the request, and as part of the parameters, it helps the back end to perform time verification of the request. The introduction of the timestamp, the value that changes over time, can distinguish requests at different time points. Request id: Generate a unique identifier (UUID) so that each request has a unique id to distinguish and track different requests. Every time a request is initiated, this custom UUID method is called to generate a unique requestId. Authorize: Use the user token as part of the parameters so that the backend can verify the user's identity when receiving the request. After obtaining the four parameters, you can assemble the four parameters into request parameters. Based on the previously obtained encryption representation, you can determine whether the data needs to be encrypted at present. If the representation indicates that it is currently in a non-encrypted state, you can directly perform JSON serialization on all the above parameters to generate a standard JSON string. If the representation indicates that it is currently in an encrypted state, first define a function named app.operaSm2, which is used to handle encryption and signing operations based on the SM2 algorithm. SM2 is a public key cryptography algorithm (asymmetric encryption algorithm) based on elliptic curves and is widely used in China's national cryptographic standards. Request the server to obtain a key pair. The publicKey public key is used for data encryption and the privKey private key is used for data signing. The sm2 module in the sm-crypto library is introduced. Use the sm2.doEncrypt method to encrypt the assembled request parameters, such as Fig. 9 As shown, the encrypted data encryptData is obtained. The encrypted data encryptData is signed using the sm2.doSignature method to obtain the signature value sigValueHex. An object is returned, which contains the encrypted data d, the signature value s, and a constant string 'c':'i'. The encryption of the entire data package is completed.

[0086] In one embodiment of the present invention, Figure 3As shown, the first process of security check may include:

[0087] In step S10, the encrypted data and signature value are obtained, and a key pair is obtained from a database. The public key contained in the key pair is used for data signature verification, and the private key of the key pair is used for data decryption.

[0088] In step S11, two numbers r and s are obtained from the signature value, and then a new R value is calculated through the sm2 module and the public key.

[0089] In step S12, the calculated R value is compared with the r value in the signature value to verify whether the signature is legitimate.

[0090] In step S13, when the signature verification fails, it indicates that the data has been tampered with, and an error message is returned to the front end, and the login is forced to be logged out, and the tampering time is recorded in the exception log through log management.

[0091] In step S14, when the signature result is verified, the encrypted data is decrypted by the sm2 module and the private key, and it is determined whether the decryption is successful.

[0092] In step S15, when decryption fails, an error message is returned to the front end, and the user is forced to log out. The tampering event is recorded in the exception log through log management.

[0093] In step S16, when the decryption is successful, the decrypted plaintext parameters are obtained.

[0094] In the present invention, after the parameter preparation is completed, the front-end HTTP client library (axios) can be used to send HTTP requests. In the request, the encrypted data (or unencrypted JSON string) is used as part of the request body or request parameters. The request is sent according to the request method (such as GET, POST, etc.) and request header (such as Content-Type, etc.) set in advance. After receiving the request, the gateway will check the request method, such as POST or GET. According to business logic and security requirements, ensure that the request method complies with predefined rules. If it is a request of other types, it will be directly returned to the front end for abnormal prompts, and the abnormal request will be sent to the log system through the message queue to record the abnormal log. The gateway determines whether the current request communication is in the encrypted state through the system fixed value management. If it is in the non-encrypted state, the parameters can be deserialized. In the encrypted state, the encrypted data and signature value can be obtained, and the key pair can be obtained from the cache or database. The key pair contains the publicKey public key for data data verification and the privKey private key for data decryption. Use SM2's signature verification method to verify the message s requested by the front-end, SMUtils.verifySM2Signature(publicKey,d,s) for signature verification. Its basic logic is to calculate the Z value and the SM3 hash value through the signature public key and the encrypted data, and get two numbers from the signature: r and s, and then calculate the new R value, and then compare the calculated R value with the r value in the signature to verify whether the signature is legal. If the signature verification fails, it means that the request data has been tampered with. The system will reject the request and immediately return an error message to the front-end, force the login to log out, and record the tampering event in the exception log through log management. When the signature verification passes, it proves that the data has not been tampered with and decrypts the data. After the signature verification passes, the SM2 signature verification method can be used to decrypt the encrypted data requested by the front-end SMUtils.SM2Dec(privKey,d). The basic logic is to decrypt the encrypted data with the private key to obtain the plaintext parameters. If the decryption fails, it means that the integrity of the request data has been compromised. The system will reject the request and immediately return an error message to the front end, force the user to log out, and record the tampering event in the exception log through log management.

[0095] In one embodiment of the present invention, Figure 4 As shown, the second process of security check may include:

[0096] In step S17, plain text parameters are obtained.

[0097] In step S18, the plain text parameters are filtered and replaced by using the special character library and the keyword library to obtain replaced parameters.

[0098] In step S19, it is determined whether there is a difference between the parameters after replacement and the parameters before replacement.

[0099] In step S20, if there is a difference, an error message is returned to the front end to inform that a special character exists, and the special character event is recorded in the exception log through log management.

[0100] In step S21, when there is no difference, it is determined that the plain text parameter does not have any special characters and the plain text parameter is safe.

[0101] In the present invention, after the data is decrypted, the plain text parameters are obtained, and the parameter content can be processed with special characters. The purpose is to ensure data security, and the data is strictly verified and cleaned to ensure the security and validity of the data to prevent SQL injection and XSS cross-site scripting attacks. The system performs unified configuration management on the special character library and the keyword library. The parameters are filtered and replaced by the special character library and the keyword library to obtain the replaced parameters. The replaced parameters are compared with the parameters before the replacement to see if there are any differences. If there are any differences, it means that there are special characters in the parameters. The system will reject the request and immediately return an error message to the front end, informing that the special characters exist, and the special character events are recorded in the exception log through log management. In the case where there are no differences, it can be determined that there are no special characters in the plain text parameters, and the plain text parameters are safe.

[0102] In one embodiment of the present invention, Figure 5 As shown, the third process of security check may include:

[0103] In step S22, the business parameters, timestamp, request id and Authorize of the decrypted data are combined into a unique key for the Web request.

[0104] In step S23, it is determined whether the same key exists in the acquisition cache of the backend gateway.

[0105] In step S24, if it does not exist, the key is put into the acquisition cache and the data is distributed to the microservice for request processing.

[0106] In step S25, if there is an error, an error message is returned to the front end, prompting the user that the request is intercepted and replayed and the user is forced to log out, and the replay event is recorded in the exception log through log management.

[0107] In the present invention, after the security and validity of the parameters are verified, an anti-replay verification strategy can also be implemented. The main purpose of the anti-replay verification strategy is to prevent replay attacks, that is, an attacker intercepts a request from a legitimate user and resends the request to achieve unauthorized access or operation. Replay attacks can threaten the confidentiality, integrity and availability of the system.

[0108] The purpose of anti-replay attack is:

[0109] Protect sensitive operations: Attackers can intercept and resend important operations (such as fund transfers, data updates, etc.) to achieve unauthorized purposes.

[0110] Ensure the uniqueness of requests: Ensure that each request is unique and will not be processed repeatedly, preventing multiple executions of the same request.

[0111] Enhanced session security: In a user session, ensure the legitimacy of each operation to prevent the acquisition of user permissions by replaying old requests.

[0112] When preventing replay, you can obtain the decrypted business parameters, timestamp, request id and Authorize, and then implement the anti-replay strategy based on these four parameters. Request id: When the user triggers a system event, the front end will generate a unique identifier (UUID) for each request to distinguish and track different requests. And when processing the request, the processed request identifier is recorded, and the request id is placed in the context for subsequent return. Timestamp: Include a timestamp in the request and verify it on the server side to ensure that the request is valid within a certain time window. For example, if the timestamp of the request is later than a certain range of the current time, the request is rejected. Session management: Using session management, the status of the user session is controlled on the server side, the validity of each session is monitored, and each Authorize token is ensured to be valid to avoid reusing requests from old sessions. Therefore, when performing anti-replay, the request id is used to identify the request parameters and response data, and the timestamp is used to verify whether there is a time difference between when the server receives the request and when the client sends the request. Business parameters, timestamp, request ID and Authorize can form the unique key of the web request. Check whether the same key exists in the cache. If not, put the key into the cache and distribute the data to the microservice for request processing. If it exists, it means that the request is replayed. The system will reject the request and immediately return an error message to the front end, prompting the user that the request is intercepted and replayed and forced to log out, and record the replay event in the exception log through log management.

[0113] Due to the encryption transformation of the request parameters in the communication method, the parameter structure is fixed and unified. After the above verification is completed, the request body needs to be modified dynamically and the request type needs to be set correctly. Rewrite the parameters to different request parameter positions according to different request methods to ensure that the parameters are normal when the subsequent microservices process business requests: obtain the request parameters by obtaining the current request context, rewrite the different request methods and positions of the context, and restore the normal parameter format. Rewrite Authorize to the request header and write the request id to the context for subsequent use.

[0114] After the gateway completes a series of security and validity checks on the request, it distributes the request to the corresponding microservice for business data processing, and uniformly receives the response data after the microservice processing is completed.

[0115] After the microservice on the server processes the business data, the response data is returned to the gateway. After receiving the response data, the gateway processes it uniformly and notifies the log system through the message queue to record the operation log according to the resource configuration.

[0116] In one embodiment of the present invention, Figure 6 As shown, the first process of encrypting data may include:

[0117] In step S26, the backend receives response data after the microservice processes the business data.

[0118] In step S27, the sensitive fields of mobile phone number, ID card and email address in the response data are identified and desensitized.

[0119] In step S28, the special character library and the keyword library filter the response data after the desensitization processing.

[0120] In step S29, after filtering is completed, the request id is obtained from the context and added to the response data.

[0121] In the present invention, after responding to the user request, the back end can receive the response data after the microservice has processed the business data, and then some sensitive fields in the response data can be desensitized, such as mobile phone number, ID card, mailbox, etc. After desensitization, the response data can be filtered by a special character library and a keyword library to ensure the security of the response data. After filtering is completed, the request id can be obtained from the context to supplement the response data, so that the front end can compare the request id sent and the request id in the response after the data is received.

[0122] In one embodiment of the present invention, Figure 7 As shown, the first process of encrypting data may include:

[0123] In step S30, the supplemented response data is acquired.

[0124] In step S31, the sm2 module encrypts the response data using the public key of the SM2 key pair to obtain ciphertext data.

[0125] In step S32, the sm2 module signs the ciphertext data using the private key of the SM2 key pair to obtain signature data.

[0126] In step S33, after the operation is completed, the completed data is responded to the front end.

[0127] In the present invention, after obtaining the supplemented response data, it can be determined whether the current request communication is encrypted. When it is not encrypted, the response data can be directly serialized into JSON to generate a standard JSON string. In the encrypted state, the key pair can be obtained from the cache or database. The key pair contains the publicKey public key for data encryption and the privKey private key for data signing. The data result data is encrypted by the function SecretHolder.SM2Enc(publicKey,data) to obtain the ciphertext data. The ciphertext data is then signed by the function SecretHolder.genSM2Signature(privKey,Util.byteToHex(d.getBytes())).getSm2_signForHard()) to obtain the signature data, and the encryption and signature structure is {d: encrypted data, s signature data}.

[0128] In one embodiment of the present invention, Figure 8 As shown, the process of decrypting the returned data may include:

[0129] In step S34, the encrypted response data is obtained.

[0130] In step S35, the sm2 module calculates the signature of the response data using the public key to obtain a calculated value.

[0131] In step S36, it is determined whether the calculated value is identical to the signature data of the corresponding data to verify whether the signature is legal.

[0132] In step S37, if the signature verification fails due to differences, the request is stopped, a pop-up window prompts, and the user is forced to log out. The tampering time is recorded in the exception log through log management.

[0133] In step S38, when the signature verification is successful, the sm2 module decrypts the ciphertext data using the private key and renders the decrypted data on the page to complete the user's request response.

[0134] In the present invention, after obtaining the encrypted response data, the SM2 module can calculate the signature of the public key, and compare the calculated value with the signature value to verify whether the signature is legal. If the signature verification fails, it means that the response data has been tampered with. The system will stop the request and pop up a window prompt, and force the login to be logged out, and record the tampering event in the exception log through log management. When the signature verification passes, the data decryption process is performed. During decryption, the ciphertext data can be decrypted by the private key to obtain the plaintext data. If the decryption fails, it means that the integrity of the response data has been destroyed. The system will stop the request and pop up a window prompt, and force the login to be logged out, and record the tampering event in the exception log through log management. If the decryption is successful, the object will be converted into a JavaScript object, and the page will be rendered by the data after successful decryption to complete the user's request response.

[0135] After the response data is parsed, the request ID in the acquired data is compared with the request ID when the request was sent to see if they are consistent. If they are inconsistent, it means that the request response is reused. The system will stop the request and pop up a window to prompt, force the login to log out, and record the interception event in the exception log through log management.

[0136] On the other hand, the present invention also provides an enhanced JavaWeb secure communication system, which includes: a front-end module, a back-end module, a microservice module and an exception log module. The front-end module can be used to accept user request data, encrypt the request data, and decrypt the returned response data to render the page according to the response data to complete the customer's request response. The back-end module is used to receive the encrypted data, decrypt it after security verification, and send the decrypted data to the microservice module, and encrypt the returned response data. The microservice module is used to receive the decrypted data to complete the request and return the response data to the back-end module. The exception log module is used to record abnormal situations during data transmission.

[0137] Through the above technical scheme, the present invention provides an enhanced JavaWeb security communication method and system. After the user submits a data request, the front end can assemble the user request into four groups of parameters: business parameters, timestamp, request id and Authorize. When encryption is required, the back-end interface can be called to obtain the SM2 key pair, so that the four groups of parameters can be encrypted, and the encrypted data can be sent to the back end for request processing. After receiving the request, the back-end gateway can perform a security check on the encrypted data, and when the security check passes, the data can be distributed to the microservice for request processing. The microservice can process the data request for submission and return the processed data to the back end. The back end encrypts the data returned after the microservice processing and can send the encrypted data to the front end. After receiving the encrypted data and performing a security check, the front end can render the page according to the returned data, so as to complete the user's request response. The method can prevent the communication message from being stolen, tampered, replayed, and tracked securely, thereby realizing secure JavaWeb communication.

[0138] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0139] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0140] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0141] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0142] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0143] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0144] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0145] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0146] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included within the scope of the claims of the present application.

Claims

1. An enhanced JavaWeb security communication method, characterized in that: The method comprises: The user submits a data request, and the front end assembles the user request into four groups of parameters: business parameters, timestamp, request id, and Authorize; If encryption is required, call the backend interface to obtain the SM2 key pair to encrypt the four sets of parameters, and send the encrypted data to the backend for request processing; The backend gateway accepts the request and performs a security check on the encrypted data. After the security check passes, the data is distributed to the microservice for request processing. The backend encrypts the data returned by the microservice after processing the request and sends the encrypted data to the frontend; After the front end performs a security check on the encrypted data, it renders the page based on the returned data to complete the user's request response.

2. The method according to claim 1, characterized in that If encryption is required, call the backend interface to obtain the SM2 key pair to encrypt the four sets of parameters, and send the encrypted data to the backend for request processing, including: Request a key pair from the server, where the public key is used for data encryption and the private key is used for data signing; Reference the sm2 module in the sm-crypto library, use the sm2.doEncrypt method in the sm2 module and the public key to encrypt the four sets of parameters to obtain encrypted data; Use the sm2.doSignature method and the private key to sign the encrypted data to obtain a signature value; Send the encrypted data and signature value to the backend for request processing.

3. The method according to claim 2, characterized in that The backend gateway accepts the request and performs a security check on the encrypted data. After the security check passes, the data is distributed to the microservices for request processing, including: Obtain the encrypted data and signature value, and obtain a key pair from a database, wherein the public key contained in the key pair is used for data signature verification, and the private key of the key pair is used for data decryption; Get two numbers r and s from the signature value, and then calculate the new R value through the sm2 module and the public key; Compare the calculated R value with the r value in the signature value to verify whether the signature is legitimate; If the signature verification fails, it indicates that the data has been tampered with, and an error message is returned to the front end, and the user is forced to log out. The tampering time is recorded in the exception log through log management. When the signature result is verified, the encrypted data is decrypted through the sm2 module and the private key, and it is determined whether the decryption is successful; In case of decryption failure, an error message is returned to the front end, the user is forced to log out, and the tampering event is recorded in the exception log through log management; If the decryption is successful, the decrypted plaintext parameters are obtained.

4. The method according to claim 3, characterized in that: The backend gateway accepts the request and performs a security check on the encrypted data. After the security check passes, the data is distributed to the microservices for request processing, including: Obtaining the plaintext parameter; Filter and replace the plain text parameters through a special character library and a keyword library to obtain replaced parameters; Determine whether there is a difference between the parameters after replacement and the parameters before replacement; If there is a discrepancy, an error message is returned to the front end to inform that special characters exist, and the special character event is recorded in the exception log through log management; In the case where there is no difference, it is determined that the plain text parameter does not have any special characters and the plain text parameter is safe.

5. The method according to claim 4, characterized in that The backend gateway accepts the request and performs a security check on the encrypted data. After the security check passes, the data is distributed to the microservices for request processing, including: The business parameters, timestamp, request id and Authorize of the decrypted data form a unique key for the Web request; Determine whether the same key exists in the backend gateway's cache; In the absence of existence, the key is put into the fetch cache and the data is distributed to the microservice for request processing; If it exists, an error message is returned to the front end, prompting the user that the request is intercepted and replayed and the user is forced to log out, and the replay event is recorded in the exception log through log management.

6. The method according to claim 5, characterized in that The backend encrypts the data returned by the microservice after processing the request and sends the encrypted data to the frontend, including: The backend receives the response data after the microservice processes the business data; Identify sensitive fields such as mobile phone number, ID card, and email address in the response data and perform desensitization processing; The special character library and keyword library filter the response data after desensitization processing; After filtering is completed, the request id is obtained from the context and added to the response data.

7. The method according to claim 6, characterized in that The backend encrypts the data returned by the microservice after processing the request and sends the encrypted data to the frontend, including: Get the supplemented response data; The sm2 module encrypts the response data using the public key of the SM2 key pair to obtain ciphertext data; The sm2 module uses the private key of the SM2 key pair to sign the ciphertext data to obtain the signed data; After the operation is completed, the completed data will be responded to the front end.

8. The method according to claim 7, characterized in that After the front-end performs a security check on the encrypted data, it renders the page based on the returned data and completes the user's request response, including: Get the encrypted response data; The sm2 module calculates the signature of the response data using the public key to obtain the calculated value; Determine whether the calculated value is the same as the signature data of the corresponding data to verify whether the signature is legal; If they are not the same and the signature verification fails, the request will be stopped, a window will pop up, and the user will be forced to log out. The tampering time will be recorded in the exception log through log management. In the same case, if the signature verification is successful, the sm2 module decrypts the ciphertext data through the private key and renders the decrypted data on the page to complete the user's request response.

9. An enhanced JavaWeb secure communication system, characterized in that: The system comprises: The front-end module is used to receive user request data, encrypt the request data, and decrypt the returned response data to render the page according to the response data to complete the customer's request response; The backend module receives the encrypted data, decrypts it after security verification, sends the decrypted data to the microservice module, and encrypts the returned response data; The microservice module receives the decrypted data to complete the request and returns the response data to the backend module; The exception log module records the abnormal situations in the data transmission process.

Images