Universal web development framework implementation method for full-ciphertext transmission

Abstract

The invention discloses a universal web development framework implementation method for full-ciphertext transmission, and the method comprises the steps: a front end obtains a national cryptographic symmetric key of a rear end for data encryption, generates a request message, and sends the request message to the rear end; after uniqueness of the request message is obtained through the distributed lock, signature verification is carried out by the rear end; the back end decrypts the encrypted message to obtain the user information and the secret key, and the secret key is stored in a thread local variable; adding a paging annotation and a log annotation to the decrypted request body data; a configuration change event is monitored in real time, and latest configuration data is pulled and updated to the Bean object after configuration change; an MQ adapter is utilized to realize automatic routing of a new message and an old message; the link ID is carried when the external interface is requested. The development cost of the basic function module is effectively reduced.

Description

Technical Field

[0001] The present invention relates to the field of information security technology, and in particular, to a method for implementing a general web development framework for full ciphertext transmission. Background Art

[0002] With the rapid development of Internet technology and microservices architecture, web development frameworks play an increasingly important role in enterprise informatization construction. Modern web systems have put forward higher requirements for data transmission security, development efficiency, and system maintainability. However, the existing technologies have significant deficiencies in the following aspects: 1. Insufficient data transmission security: In traditional web development frameworks, data transmission mostly uses plaintext or simple encryption methods (such as HTTPS combined with AES encryption), which are difficult to meet the requirements in high-security scenarios. Especially in systems involving sensitive information (such as finance, communication, government affairs, etc.), there is a lack of strong encryption mechanisms that comply with national cryptographic standards (such as national cryptographic algorithms), and data is easily intercepted or tampered with, posing security risks. 2. Weak protection against replay attacks: In existing web systems, although some frameworks verify the validity of requests through timestamps or random numbers, the verification mechanism is relatively simple and fails to comprehensively combine dynamic key negotiation and signature verification, resulting in the system being vulnerable to replay attacks. Attackers can bypass security protection by repeatedly sending historical requests, threatening the stability of the system. 3. Low development efficiency: In the microservices architecture, common functions such as service-to-service calls, paging queries, and logging usually need to be manually implemented by developers. For example, the implementation of the paging function often depends on manually passing the page number and the number of items per page parameters, and logging requires adding redundant code in each method. This not only increases the development workload but also reduces the code reusability and maintainability. 4. Insufficient system maintainability and scalability: Existing frameworks have limitations in problem troubleshooting and system expansion. The lack of a unified link tracing mechanism makes it difficult to locate faults in cross-service requests; configuration management mostly uses static file methods and requires restarting the service when changing, making it difficult to achieve dynamic adjustment; the support for message queues is usually limited to a single implementation (such as RabbitMQ), and significant code modifications are required when switching to other message queues (such as Kafka), resulting in poor scalability. 5. Limited support for basic functions: Most current web development frameworks only provide basic development tools and lack out-of-the-box general business functions (such as user management, role management, etc.). Developers need to develop these modules separately, prolonging the project delivery cycle.

[0003] Therefore, there is an urgent need for a brand-new web development framework that can improve development efficiency, enhance system maintainability, and provide flexible expansion capabilities and general business support on the basis of ensuring data transmission security to meet the diverse needs of modern complex business systems. Summary of the Invention

[0004] The object of the present invention is to provide a method for implementing a general web development framework for full ciphertext transmission.

[0005] The technical solution adopted by the present invention is as follows: A method for implementing a general web development framework for full ciphertext transmission, which includes the following steps: Step 1, the front end obtains the national cipher (SM4) symmetric key provided by the back end for data encryption, and uses the national cipher (SM4) symmetric key to encrypt the data to generate a request message and send it to the back end; Further, Step 1 specifically includes the following: Step 1-1, when a user first accesses the system, the front end automatically generates a set of RSA asymmetric keys (public key and private key), and sends the public key to the back-end server through a secure channel (such as HTTPS); Step 1-2, the back end generates an SM4 symmetric key (128 bits) for data encryption, and uses the RSA public key provided by the front end to encrypt the SM4 symmetric key to obtain an encrypted key package and return it to the front end.

[0006] Step 1-3, the front end uses the RSA private key to decrypt to obtain the SM4 symmetric key and establish an encrypted communication channel; Step 1-4, the front end uses the national cipher (SM4) algorithm (CBC mode, PKCS7 padding) to encrypt the request body data to generate ciphertext data blocks; Step 1-5, use the national cipher (SM3) algorithm to calculate the hash value of the original request body, and then combine the timestamp and random number to generate a final signature value to prevent data tampering; Step 1-6, combine the encrypted key, initialization vector (IV), ciphertext, signature, timestamp, and random number into a standard message format and send it to the back end.

[0007] Further, in Step 1, the key update process is automatically triggered every 30 minutes (the time can be configured), and the old and new keys coexist for 10 minutes (configurable) to ensure that the requests being processed can be normally decrypted.

[0008] Step 2, security verification: first, make the nonce parameter of the request message unique through a distributed lock, and then the back end verifies the signature of the received request; Further, Step 2 specifically includes the following steps: Step 2-1, perform cross-node nonce verification on the nonce parameter set of the request message stored in the Redis cluster through a distributed lock to ensure uniqueness in the cluster environment; Step 2-2, the back end receives the request and performs signature verification, and the signature verification includes time validity check, random number uniqueness verification, and signature reconstruction comparison.

[0009] Further, in step 2-1, the window time (5-15 minutes) for nonce verification is automatically shrunk or expanded based on the request frequency.

[0010] Further, step 2-2 specifically includes the following steps: Step 2-2-1, time validity check: Calculate the difference between the client timestamp and the server time. If it exceeds 10 minutes (configurable), the request is directly rejected.

[0011] Step 2-2-2, random number uniqueness verification: Query whether the nonce exists in Redis. If it exists, it is determined as a duplicate request.

[0012] Step 2-2-3, signature reconstruction comparison: Use the SM3 algorithm to recalculate the signature value for the request parameters, timestamp, and nonce, and perform a consistency check with the signature in the request.

[0013] Step 3, decrypt the encrypted message through the decryption interceptor, and store the decrypted user information and key in the thread local variable (LocalThread) for subsequent business logic use. Further, the decryption steps of step 3 are as follows: Step 3-1, use the front-end RSA private key to decrypt the encrypted message to obtain the SM4 session key; Step 3-2, use the SM4 key to decrypt the request body data to obtain JSON data; Step 3-3, extract and verify the security parameters, where the security parameters include timestamp, random number, and signature; Step 3-4, convert the decrypted JSON data into the @RequestBody parameter object of the controller layer through the reflection mechanism; Step 3-5, store the decrypted user information and key in the thread local variable (LocalThread) for subsequent business logic use.

[0014] Step 4, add paging annotations and logging annotations to the decrypted request body data; Specifically, as a feasible implementation, the annotation is above the method of the dao in the data persistence layer. When the method stack calls the corresponding function method, the annotation manually added to the function method can be obtained.

[0015] Further, step 4 specifically includes the following steps: Step 4-1, intercept the method with the @FfcsPage annotation through the AOP aspect, and automatically obtain the paging parameters from the thread local variable (LocalThread); specifically, the custom annotation is above the method of the dao in the data persistence layer. When the method stack calls the corresponding function method, the annotation manually added to the function method can be obtained.

[0016] Step 4-2: Automatically splice the LIMIT #{limit} OFFSET #{offset} statement in the MyBatis layer to avoid manually writing paging logic; Step 4-3: Package the query result into a unified paging object that includes a data list, the total number of records, and the total number of pages.

[0017] Furthermore, the paging parameters include the current page number page and the number of items per page limit.

[0018] Step 4-4: Log collection: Automatically record information such as method input parameters, return values, operator, and IP address through bytecode enhancement technology Step 4-5: Asynchronous storage optimization: Use the Disruptor high-performance queue to achieve asynchronous batch storage of logs, avoiding blocking the main business process.

[0019] Step 4-6: Support for dynamic content: Allow the use of SpEL expressions to record business-related dynamic information, for example: @FfcsLog(operation="User management", detail="Modified the permissions of user [#{#user.name}]") Step 5: Configuration center hot update: Real-time monitor the configuration change events of the Zookeeper registration node through a listener, and pull the latest configuration data to update the Bean object after the configuration change; Furthermore, Step 5 specifically includes the following steps: Step 5-1: Listener registration: Register a Zookeeper node listener when Spring Boot starts to real-time monitor configuration change events.

[0020] Step 5-2: Configuration change trigger: The operation and maintenance personnel modify the configuration node data through the Zookeeper client Step 5-3: Dynamic refresh mechanism: Update relevant Beans through Spring's RefreshScope mechanism. For example: (1) Reconstruct the database connection pool, (2) Re-initialize the MQ producer / consumer, (3) Version rollback guarantee: Keep the last 5 historical versions to support quick rollback of the configuration.

[0021] Step 6, MQ adapter implementation: Build an MQ adapter interface containing basic methods, and control the loading of specific implementation classes through the mq.type parameter in application.yml; Change the mq.type value in the configuration center from rocketmq to kafka. When the configuration is refreshed, the Spring container destroys the original RocketMQ instance and creates a Kafka connection factory according to the new configuration to establish producer / consumer connections; New messages are automatically routed to Kafka, and the existing messages continue to be consumed by the original queue until completion.

[0022] Further, in step 6, define an MQ adapter interface containing basic methods for sending and receiving messages.

[0023] Step 7, Obtain the link ID through the interceptor and write it into the MDC table (of log4j). When requesting an external interface, write the link ID (Trace-ID) into the header of the request so that the link ID can be passed between each service; Further, within the service itself, modify the log4j log format to print the link ID into the log file for quick retrieval of logs based on the link ID.

[0024] The present invention adopts the above technical solutions, encrypts the request body using national secret encryption, encrypts the transmission key pair using RSA public and private keys, and forms a full ciphertext transmission mechanism; The present invention verifies the legitimacy of requests through tokens and signs (including timestamps and nonces) to prevent replay attacks and forms a security verification mechanism. The full ciphertext transmission and anti-replay mechanism ensure data security. The present invention realizes pagination and log automation through self-developed annotations @FfcsPage and @FfcsLog, reduces duplicate code, and improves development speed. The present invention effectively reduces the development cost of basic function modules. Brief Description of the Drawings

[0025] The following further describes the present invention in detail with reference to the drawings and specific embodiments; Figure 1 It is a flowchart of an implementation method of a general web development framework with full ciphertext transmission of the present invention; Figure 2 It is a schematic diagram of the principle architecture of an implementation method of a general web development framework with full ciphertext transmission of the present invention. Detailed Description of the Embodiments

[0026] To make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application.

[0027] As Figure 1As shown in Fig. 1 or Fig. 2, the present invention discloses a method for implementing a general web development framework for full ciphertext transmission, which includes the following steps: Step 1, the front end obtains the national cipher (SM4) symmetric key provided by the back end for data encryption, and uses the national cipher (SM4) symmetric key to encrypt the data to generate a request message and send it to the back end; Among them, the back end includes an aop module, a controller layer, a sever unit, and a Dao layer.

[0028] Further, Step 1 specifically includes the following: Step 1-1, when a user first accesses the system, the front end automatically generates a set of RSA asymmetric keys (public key and private key), and sends the public key to the back-end server through a secure channel (such as HTTPS); Step 1-2, the back end generates an SM4 symmetric key (128 bits) for data encryption, and encrypts the SM4 symmetric key using the RSA public key provided by the front end to obtain an encrypted key package and returns it to the front end.

[0029] Step 1-3, the front end uses the RSA private key to decrypt to obtain the SM4 symmetric key and establish an encrypted communication channel; Step 1-4, the front end uses the national cipher (SM4) algorithm (CBC mode, PKCS7 padding) to encrypt the request body data to generate ciphertext data blocks; Step 1-5, use the national cipher (SM3) algorithm to calculate the hash value of the original request body, and then combine the timestamp and random number to generate a final signature value to prevent data tampering; Step 1-6, combine the encrypted key, initialization vector (IV), ciphertext, signature, timestamp, and random number into a standard message format and send it to the back end.

[0030] Further, the key update process is automatically triggered every 30 minutes (the time can be configured) in Step 1, and the old and new keys coexist for 10 minutes (configurable) to ensure that the requests being processed can be decrypted normally.

[0031] Step 2, security verification: first, make the nonce parameter of the request message unique through a distributed lock, and then the back end verifies the signature of the received request; Further, Step 2 specifically includes the following steps: Step 2-1, perform cross-node nonce verification on the nonce parameter set of the request message stored in the Redis cluster through a distributed lock to ensure uniqueness in the cluster environment; Step 2-2, the back end receives the request and performs signature verification, and the signature verification includes time validity check, random number uniqueness verification, and signature reconstruction comparison.

[0032] Further, in step 2-1, automatically shrink or expand the window time (5-15 minutes) for nonce verification based on the request frequency.

[0033] Further, step 2-2 specifically includes the following steps: Step 2-2-1, time validity check: Calculate the difference between the client timestamp and the server time. If it exceeds 10 minutes (configurable), directly reject the request.

[0034] Step 2-2-2, random number uniqueness verification: Query whether the nonce exists in Redis. If it exists, it is determined as a duplicate request.

[0035] Step 2-2-3, signature reconstruction comparison: Use the SM3 algorithm to recalculate the signature value for the request parameters, timestamp, and nonce, and perform a consistency check with the signature in the request.

[0036] Step 3, decrypt the encrypted message through a decryption interceptor, and store the decrypted user information and key in a thread local variable (LocalThread) for subsequent business logic use. Further, the decryption steps of step 3 are as follows: Step 3-1, decrypt the encrypted message using the front-end RSA private key to obtain the SM4 session key; Step 3-2, decrypt the request body data with the SM4 key to obtain JSON data; Step 3-3, extract and verify the security parameters, where the security parameters include timestamp, random number, and signature; Step 3-4, convert the decrypted JSON data into the @RequestBody parameter object of the controller layer through the reflection mechanism; Step 3-5, store the decrypted user information and key in a thread local variable (LocalThread) for subsequent business logic use.

[0037] Step 4, add paging annotations and logging annotations to the decrypted request body data; Specifically, as a feasible implementation, the annotation is on the method of the data persistence layer dao at the back end. When the method stack calls the corresponding function method, the annotation manually added to the function method is obtained.

[0038] Further, step 4 specifically includes the following steps: Step 4-1, intercept the method with the @FfcsPage annotation through the AOP aspect, and automatically obtain the paging parameters from the thread local variable (LocalThread); specifically, the custom annotation is above the method of the data persistence layer dao at the back end. When the method stack calls the corresponding function method, the annotation manually added to the function method can be obtained.

[0039] Step 4-2: Automatically splice the LIMIT #{limit} OFFSET #{offset} statement in the MyBatis layer to avoid manually writing paging logic; Step 4-3: Package the query result into a unified paging object that includes a data list, the total number of records, and the total number of pages.

[0040] Furthermore, the paging parameters include the current page number page and the number of items per page limit.

[0041] Step 4-4: Log collection: Automatically record information such as method input parameters, return values, operators, and IP addresses through bytecode enhancement technology Step 4-5: Asynchronous storage optimization: Use the Disruptor high-performance queue to achieve asynchronous batch storage of logs, avoiding blocking the main business process.

[0042] Step 4-6: Dynamic content support: Allow the use of SpEL expressions to record business-related dynamic information, for example: @FfcsLog(operation="User management", detail="Modified the permissions of user [#{#user.name}]") Step 5: Configuration center hot update: Real-time monitor the configuration change events of the Zookeeper registration node through a listener, and pull the latest configuration data to update the Bean object after the configuration changes; Furthermore, Step 5 specifically includes the following steps: Step 5-1: Listener registration: Register a Zookeeper node listener when Spring Boot starts to real-time monitor configuration change events.

[0043] Step 5-2: Configuration change trigger: The operation and maintenance personnel modify the configuration node data through the Zookeeper client Step 5-3: Dynamic refresh mechanism: Update the relevant Beans through Spring's RefreshScope mechanism. For example: (1) Reconstruct the database connection pool, (2) Re-initialize the MQ producer / consumer, (3) Version rollback guarantee: Retain the last 5 historical versions to support quick rollback of the configuration.

[0044] Step 6, MQ adapter implementation: Build an MQ adapter interface containing basic methods, and control the loading of specific implementation classes through the mq.type parameter in application.yml; change the mq.type value in the configuration center from rocketmq to kafka. When the configuration is refreshed, the Spring container destroys the original RocketMQ instance and creates a Kafka connection factory according to the new configuration to establish producer / consumer connections; new messages are automatically routed to Kafka, and the existing messages continue to be consumed by the original queue until completion.

[0045] Further, in Step 6, define an MQ adapter interface containing basic methods for sending and receiving messages.

[0046] Step 7, obtain the link ID through an interceptor and write it into the MDC table (of log4j). When requesting an external interface, write the link ID (Trace-ID) into the header of the request so that the link ID can be passed between each service; Further, within the service itself, modify the log4j log format to print the link ID to the log file for quick retrieval of logs based on the link ID.

[0047] The present invention adopts the above technical solutions, encrypts the request body using national cryptography, and encrypts the transmission key pair using RSA public and private keys to form a full ciphertext transmission mechanism; the present invention verifies the legitimacy of requests through tokens and signs (including timestamps and nonces) to prevent replay attacks and forms a security verification mechanism. The full ciphertext transmission and anti-replay mechanism ensure data security. The present invention realizes pagination and log automation through the annotations @FfcsPage and @FfcsLog, reduces duplicate code, and improves the development speed. The present invention effectively reduces the development cost of basic functional modules.

[0048] Obviously, the described embodiments are part of the embodiments of the present application, rather than all of them. Without conflict, the embodiments and features in the present application can be combined with each other. Usually, the components of the embodiments of the present application described and illustrated in the drawings here can be arranged and designed in various different configurations. Therefore, the detailed description of the embodiments of the present application is not intended to limit the scope of the present application claimed, but merely represents the selected embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of the present application.

Claims

1. A method for implementing a general web development framework with full ciphertext transmission, characterized in that: It includes the following steps: Step 1, full ciphertext transmission mechanism: The front end obtains the national cipher symmetric key provided by the back end for data encryption, and uses the national cipher symmetric key to encrypt the data to generate a request message and send it to the back end; Step 2, security verification mechanism: First, the uniqueness of the nonce parameter of the request message is ensured through a distributed lock, and then the back end performs signature verification on the received request; Step 3, back-end decryption: The back end decrypts the encrypted message through a decryption interceptor, and stores the decrypted user information and key in thread local variables; Step 4, adding annotations: Add paging annotations and log annotations to the decrypted request body data; Step 5, configuration center hot update: Real-time monitor the configuration change events of the Zookeeper registration node through a listener, and pull the latest configuration data to update the Bean object after the configuration changes; Step 6, MQ adapter implementation: Build an MQ adapter interface containing basic methods, and control the loading of specific implementation classes through the mq.type parameter in the configuration; Change the mq.type value in the configuration center from rocketmq to kafka. When the configuration is refreshed, the Spring container destroys the original RocketMQ instance and creates a Kafka connection factory according to the new configuration, and establishes producer and consumer connections; New messages are automatically routed to Kafka, and the existing messages continue to be consumed by the original queue until completion; Step 7, global link ID: Obtain the link ID through an interceptor and write it into the MDC table. When requesting an external interface, write the link ID into the header of the request to facilitate the transfer of the link ID between each service.

2. A method for implementing a general web development framework for full ciphertext transmission according to claim 1, characterized in that: Step 1 specifically includes the following: Step 1-1, when the user first accesses the system, the front end automatically generates a public key and a private key of a set of RSA asymmetric keys, and sends the public key to the back-end server through a secure channel; Step 1-2, the back end generates a national cipher symmetric key for data encryption, and encrypts the national cipher symmetric key using the RSA public key provided by the front end to obtain an encrypted key package and return it to the front end; Step 1-3, the front end uses the RSA private key to decrypt to obtain the SM4 symmetric key to establish an encrypted communication channel; Step 1-4, the front end uses the national cipher algorithm to encrypt the request body data to generate a ciphertext data block; Step 1-5, calculate the hash value of the original request body using the national cipher algorithm, and then combine the timestamp and random number to generate a final signature value to prevent data tampering; Step 1-6, combine the encrypted key, initialization vector, ciphertext, signature, timestamp and random number into a standard message format and send it to the back end.

3. A method for implementing a general web development framework for full ciphertext transmission according to claim 1, characterized in that: In Step 1, the key update process is automatically triggered periodically, and the old and new keys coexist for a set duration to enable the normal decryption of the requests being processed.

4. A method for implementing a general web development framework for full ciphertext transmission according to claim 1, characterized in that: Step 2 specifically includes the following steps: Step 2-1, perform cross-node nonce verification on the nonce parameter set of the request message stored in the Redis cluster through a distributed lock to ensure uniqueness in the cluster environment; Step 2-2, the back end receives the request and performs signature verification, and the signature verification includes time validity check, random number uniqueness verification and signature reconstruction comparison.

5. A method for implementing a general web development framework for full ciphertext transmission according to claim 4, characterized in that: Step 2-2 specifically includes the following steps: Step 2-2-1, Time Validity Check: Calculate the difference between the client timestamp and the server time. If it exceeds the set duration, the request is directly rejected. Step 2-2-2, Random Number Uniqueness Verification: Query Redis to check if there is a corresponding nonce parameter. If it exists, it is determined as a duplicate request. Step 2-2-3, Signature Reconstruction Comparison: Use the national cryptography algorithm to recalculate the signature value for the request parameters, timestamp, and nonce, and perform a consistency check with the signature in the request.

6. A method for implementing a general web development framework for full ciphertext transmission according to claim 1, characterized in that: The decryption steps of Step 3 are as follows: Step 3-1, Use the front-end RSA private key to decrypt the encrypted message to obtain the SM4 session key. Step 3-2, Use the SM4 key to decrypt the request body data to obtain JSON data. Step 3-3, Extract and verify the security parameters, which include timestamp, random number, and signature. Step 3-4, Convert the decrypted JSON data into the @RequestBody parameter object of the controller layer through the reflection mechanism. Step 3-5, Store the decrypted user information and key into the thread local variable.

7. A method for implementing a general web development framework for full ciphertext transmission according to claim 1, characterized in that: Step 4 specifically includes the following steps: Step 4-1, Intercept the method with the @FfcsPage annotation through the AOP aspect, and automatically obtain the paging parameters from the thread local variable; the paging parameters include the current page number page and the number of items per page limit. Step 4-2, Automatically splice the paging parameter statement in the MyBatis layer to form a paging logic statement. Step 4-3, Package the query result into a unified paging object containing the data list, total record count, and total number of pages. Step 4-4, Log Collection: Automatically record the method input parameters, return values, operator, and IP address information through bytecode enhancement technology. Step 4-5, Asynchronous Storage Optimization: Use the Disruptor high-performance queue to achieve asynchronous batch storage of logs. Step 4-6, Dynamic Content Support: Use the SpEL expression to record the dynamic information of the business.

8. A method for implementing a general web development framework for full ciphertext transmission according to claim 1, characterized in that: Step 5 specifically includes the following steps: Step 5-1, Listener Registration: Register a node listener with Zookeeper when SpringBoot starts to monitor configuration change events in real time. Step 5-2, Configuration Change Trigger: The operation and maintenance personnel modify the configuration node data through the Zookeeper client. Step 5-3, Dynamic Refresh Mechanism: Update the Bean object through the RefreshScope mechanism of Spring.

9. A method for implementing a general web development framework for full ciphertext transmission according to claim 1, characterized in that: Define an MQ adapter interface in Step 6 that includes basic methods for sending and receiving messages.

10. The implementation method of a general web development framework for full ciphertext transmission according to claim 1, characterized in that: In Step 7, within the self-service, modify the log4j log format and print the link ID to the log file to quickly retrieve logs based on the link ID.

Images