Request processing method and device based on dynamic token and electronic equipment

Abstract

The invention discloses a request processing method and device based on a dynamic token and electronic equipment. The method is applied to a back-end server, and comprises the following steps: receiving an original request and extracting a request path, if the request path exists in a locally cached legal path list, decrypting a dynamic token by using a private key to obtain plaintext data, and extracting an original authorization token and a corresponding generation timestamp from the plaintext data; a preset invalid token cache list is inquired, if the original authorization token does not exist in the invalid token cache list, the original authorization token is written into the invalid token cache list, the time difference between the current time of the server and the generated timestamp is calculated, and whether the time difference is smaller than a preset effective time threshold value or not is judged; and if the time difference is smaller than a preset effective time threshold, transmitting the original request to a corresponding service logic processing module to complete request processing based on the dynamic token. According to the method, data sniffing and hostile attack risks can be effectively prevented.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of data processing, and particularly relates to a request processing method and device based on a dynamic token and electronic equipment. BACKGROUND

[0002] With the continuous evolution of Internet technology, the front-end and back-end separation architecture has been widely applied in the development practice of modern Web systems. Under this architecture, the front-end is mainly responsible for the construction of the user interface and the implementation of the interaction logic, usually based on HTML, CSS and JavaScript technologies; the back-end focuses on business logic processing, data storage and service interface provision, exposing services to the outside through RESTful API or GraphQL protocols. The front-end and back-end communicate through HTTP / HTTPS protocol in a loosely coupled manner, effectively improving the maintainability, scalability and team collaboration efficiency of the system.

[0003] However, as the system functionality becomes increasingly complex, especially with the widespread introduction of third-party components (such as Swagger, Admin UI, OpenAPI documentation tools, etc.), the system's security exposure surface also expands. Attackers can use network sniffing tools (such as Wireshark, Fiddler, Burp Suite, etc.) to monitor and analyze communication traffic, thereby obtaining specific paths of API interfaces, request parameter formats, and Token used for authentication, and other key information. Once these sensitive data are stolen, attackers can simulate legitimate requests and implement malicious behaviors such as replay attacks, unauthorized access, or interface brute force enumeration, which seriously threatens the data security and service availability of the system.

[0004] Currently, the request processing technology has deficiencies in addressing the security protection needs in complex business environments, and lacks a security solution that can effectively defend against network sniffing and malicious attacks, has good compatibility, and has low modification cost. In particular, in the front-end and back-end separation architecture with high dynamicity and multiple service integrations, these security risks are particularly evident, and a new security mechanism is needed to address these challenges. SUMMARY

[0005] The present application aims to address the above-mentioned deficiencies in the prior art and proposes a request processing method, device and equipment based on a dynamic token. This solution can effectively prevent data sniffing and malicious attack risks while taking into account the compatibility and maintainability of the system, significantly reducing the cost of security mechanism deployment and system modification.

[0006] In a first aspect, the present application provides a request processing method based on a dynamic token, which is applied to a back-end server. The method comprises the following steps:

[0007] Step S1: receiving an original request from a client;

[0008] Wherein, the original request carries a dynamic token, the dynamic token is generated by the client splicing the original authorization token with the current timestamp and using the public key of the asymmetric encryption algorithm to encrypt;

[0009] Step S2: Extract the request path from the original request, and determine whether the request path exists in the locally cached legal path list:

[0010] If yes, go to step S3; if no, determine that the original request is invalid and end the process;

[0011] Step S3: Use the private key paired with the public key to decrypt the dynamic token, obtain the plaintext data, and extract the original authorization token and the corresponding generation timestamp from it;

[0012] Step S4: Query the preset invalid token cache list, and determine whether the original authorization token already exists in the invalid token cache list;

[0013] If yes, determine that the original request is invalid and end the process; if no, write the original authorization token to the invalid token cache list, and go to step S5;

[0014] Step S5: Calculate the time difference between the current server time and the generation timestamp, and determine whether the time difference is less than the preset valid time threshold;

[0015] If yes, go to step S6; if no, determine that the original request is invalid and end the process;

[0016] Step S6: Pass the original request to the corresponding business logic processing module to complete the request processing based on the dynamic token.

[0017] Further, the legal path list in step S2 is constructed by automatically scanning all controller paths in the project when the backend program starts, and cached in memory using the reflection mechanism.

[0018] Further, the original authorization token is a Token certificate issued by the backend to the frontend and cached in the client after the user successfully logs in.

[0019] Further, in step S2, if the request path does not exist in the legal path list, the method further includes: the backend server returns exception information to the client and pushes alarm information to the security management personnel.

[0020] Further, the end process is completed by the aspect-oriented programming technology in the pre-interception stage, so that the business controller does not need to be entered, and the process termination is realized by directly outputting an error response.

[0021] Further, step S3 specifically includes:

[0022] obtain a private key paired with the public key;

[0023] wherein the public key is stored in the client and the private key is stored in the backend server;

[0024] use the private key to perform decryption processing on the dynamic token using a preset asymmetric encryption algorithm to obtain decrypted plaintext data;

[0025] parse the plaintext data and extract the original authorization token and the generation timestamp corresponding to the original authorization token from the plaintext data according to a predetermined data format and rule.

[0026] Further, the asymmetric encryption algorithm is one of RSA, SM2 national encryption algorithm, or ECC elliptic curve encryption algorithm.

[0027] In a second aspect, the present application provides a request processing device based on a dynamic token, which is applied to a backend server, and the device comprises:

[0028] a receiving unit configured to receive an original request from a client;

[0029] wherein the original request carries a dynamic token, which is generated by the client by splicing an original authorization token with a current timestamp and then encrypted using a public key of an asymmetric encryption algorithm;

[0030] an extraction unit connected with the receiving unit and configured to extract a request path from the original request;

[0031] a first determination unit connected with the extraction unit and configured to determine whether the request path exists in a locally cached legal path list;

[0032] a processing unit connected with the first determination unit and configured to, when the first determination unit determines that the request path exists in the locally cached legal path list, decrypt the dynamic token using a private key paired with the public key, obtain plaintext data, and extract the original authorization token and the corresponding generation timestamp therefrom;

[0033] a query unit configured to query a preset invalid token cache list;

[0034] a second determination unit connected with the processing unit and the query unit respectively and configured to determine whether the original authorization token already exists in the invalid token cache list;

[0035] a calculation unit connected with the second determination unit and configured to, when the second determination unit determines that the original authorization token no longer exists in the invalid token cache list, calculate a time difference between a current time of the server and the generation timestamp;

[0036] A third determining unit, connected with the calculating unit, is configured to determine whether the time difference is less than a preset valid time threshold value;

[0037] A passing unit, connected with the third determining unit, is configured to pass the original request to a corresponding service logic processing module to complete the request processing based on the dynamic token when the third determining unit determines that the time difference is less than the preset valid time threshold value.

[0038] A terminating unit, connected with the first determining unit, the second determining unit and the third determining unit respectively, is configured to determine that the original request is invalid and terminate the process when the first determining unit determines that the request path does not exist in the legal path list in the local cache, or the second determining unit determines that the original authorization token already exists in the invalid token cache list, or the third determining unit determines that the time difference is greater than or equal to the preset valid time threshold value.

[0039] Further, the processing unit comprises:

[0040] An obtaining module is configured to obtain a private key paired with the public key;

[0041] The public key is stored in the client, and the private key is stored in the backend server.

[0042] A first processing module, connected with the obtaining module, is configured to use the private key to perform decryption processing on the dynamic token by using a preset asymmetric encryption algorithm, so as to obtain decrypted plaintext data.

[0043] A second processing module, connected with the first processing module, is configured to parse the plaintext data, and extract the original authorization token and the generation timestamp corresponding to the original authorization token from the plaintext data according to a predetermined data format and rule.

[0044] In a third aspect, the present application provides an electronic device, which comprises a memory and a processor, and the memory stores a computer program, when the processor runs the computer program stored in the memory, the processor executes the request processing method based on the dynamic token according to the first aspect.

[0045] The original authorization token and the timestamp are spliced in the client, and the dynamic token is generated by encrypting with the public key, and the backend sequentially performs path legality verification, private key decryption, invalid cache comparison and timeliness verification on the received request. This scheme effectively prevents data sniffing and malicious attack risks while considering system compatibility and maintainability, significantly reducing the deployment and system transformation cost of the security mechanism. The specific beneficial effects are as follows:

[0046] 1. The confidentiality of sensitive information in the transmission process is enhanced.

[0047] The application encrypts the "original authorization token + generated timestamp" to generate a dynamic token using an asymmetric encryption public key on the client side, and the backend uses a matching private key to decrypt to obtain plaintext. In this way, the authentication information always exists in the form of ciphertext during transmission, and even if it is intercepted by a network sniffing tool, the original Token cannot be directly parsed, which can effectively prevent sensitive information leakage and improve the confidentiality and security of authentication data during transmission.

[0048] 2. White list control and automatic maintenance of interface access.

[0049] The application maintains an automatically generated legal path list in the backend local cache, and judges whether the path is in the list when the request arrives, thereby realizing white list control of interface access path. Combined with the means of automatically scanning the controller and loading the legal path by reflection when the system starts, non-legitimate paths can be automatically intercepted without manual configuration or modification of business code, effectively defending against interface enumeration and path detection attacks, and supporting fast iteration of the system and dynamic expansion of the interface.

[0050] 3. High-performance implementation of replay protection.

[0051] The application queries the preset invalid token cache list and judges whether the original authorization token obtained by decryption exists, and if not, writes it into the cache, thereby detecting and preventing the reuse of dynamic tokens, and preventing attackers from implementing replay attacks by replaying legitimate requests. This mechanism is implemented based on memory cache (such as Redis, Caffeine, etc.), and has high concurrent processing capability and low delay response characteristics, while ensuring security and system performance.

[0052] 4. Strict time window verification mechanism.

[0053] The application calculates the time difference between the current time of the server and the client-generated timestamp and judges whether it is less than the preset valid time threshold, and only allows requests within a limited time range (for example, within 10 seconds) to pass, thereby enhancing the anti-replay capability, ensuring the freshness and real-time of the request, and preventing malicious reuse of delayed submission or historical requests.

[0054] 5. Non-intrusive, secure logic centralized processing.

[0055] The application centralizes path filtering, dynamic token decryption, invalid cache verification, and timeliness verification in the backend unified processing, and does not depend on modification of the existing business controller. Combined with aspect-oriented programming (AOP) technology, the whole process verification can be completed before the request enters the business logic, which not only retains the compatibility of the original authentication system (such as JWT, OAuth2.0), but also avoids large-scale modification of the core business code of the front and back ends, thereby significantly reducing the implementation cost and technical risk of system security upgrade.

[0056] In summary, the application adopts a four-fold protection mechanism of "dynamic token + path whitelist + timestamp + invalid cache", which is progressive and synergistic, can not only improve the overall security of the system, but also has good configurability and scalability, is suitable for various front-end and back-end separation architectures, micro-service environments and third-party component integration scenarios, and has wide applicable prospects and practical value. BRIEF DESCRIPTION OF DRAWINGS

[0057] The accompanying drawings are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain the principles of the application. The above and other features and advantages will become more apparent from the detailed description of the example embodiments, taken in conjunction with the accompanying drawings, in which:

[0058] Figure 1 A schematic diagram of the request processing method based on dynamic tokens in the embodiments of the application is shown in the figure.

[0059] Figure 2 A flowchart of the request processing method based on dynamic tokens in the embodiments of the application is shown in the figure.

[0060] Figure 3 A schematic diagram of the request processing device based on dynamic tokens in the embodiments of the application is shown in the figure.

[0061] Figure 4 An architecture diagram of the electronic device in the embodiments of the application is shown in the figure.

[0062] Reference signs: 10, receiving unit, 20, extraction unit, 30, first determination unit, 40, processing unit, 50, query unit, 60, second determination unit, 70, calculation unit, 80, third determination unit, 90, transmission unit, 31, end unit, 100, processor, 200, memory. DETAILED DESCRIPTION

[0063] To enable those skilled in the art to better understand the technical solutions of the application, the embodiments of the application will be further described in detail below with reference to the accompanying drawings.

[0064] It can be understood that the specific embodiments and drawings described herein are only used to explain the application, and not to limit the application.

[0065] It can be understood that the embodiments in the application and the features in the embodiments can be combined with each other without conflict.

[0066] It can be understood that, for the convenience of description, only the parts related to the application are shown in the drawings of the application, and the parts unrelated to the application are not shown in the drawings.

[0067] It can be understood that each unit and module involved in the embodiments of the present application can correspond to only one entity structure, or can be composed of multiple entity structures, or multiple units and modules can be integrated into one entity structure.

[0068] It can be understood that the functions and steps marked in the flowcharts and block diagrams of the present application can occur in an order different from that marked in the accompanying drawings, without conflict.

[0069] It can be understood that the flowcharts and block diagrams of the present application show the possible implementation architecture, functions and operations of the system, device, equipment and method according to the embodiments of the present application. Each block in the flowchart or block diagram can represent a unit, module, program segment, code, which contains executable instructions for implementing the specified functions. Moreover, each block or combination of blocks in the block diagram and flowchart can be implemented by a hardware-based system for implementing the specified functions, or by a combination of hardware and computer instructions.

[0070] It can be understood that the units and modules involved in the embodiments of the present application can be implemented in software or hardware, for example, the units and modules can be located in a processor.

[0071] Embodiment 1:

[0072] In the context of the current widespread application of front-end and back-end separation architecture, various Web systems generally integrate open-source management components such as Swagger. The interface paths exposed by default in such components are extremely easy to be captured by network sniffing tools, providing convenience for attackers to implement malicious behaviors such as interface detection and unauthorized access. However, the security protection mechanisms in the prior art have many shortcomings. First, although authentication mechanisms such as JWT or OAuth2.0 can achieve basic identity verification, the stateless nature of Token makes it difficult to actively revoke once it is leaked, and there is a risk of interception and replay in a continuous monitoring environment. Second, protection by encrypting paths or changing default addresses often has limited effect due to compatibility issues or the inability to fundamentally hide the real path. In addition, IP whitelisting and other strategies are easily bypassed by proxies and cannot meet the needs of high-security scenarios. These problems are particularly prominent in Web applications that integrate third-party management interfaces, use stateless authentication mechanisms, or have interface exposure risks, such as microservice systems built on frameworks such as Spring Boot and Node.js, as well as high-security scenarios such as government, finance, and enterprise management systems. To address these issues, the present embodiment proposes a request processing method based on dynamic tokens, aiming to solve the problems of API path exposure, authentication Token recovery difficulty, poor compatibility of protection mechanisms, and high cost of transformation in the prior art. This method generates a dynamic token containing a timestamp and an original Token by encrypting the original Token with a public key on the front end, and automatically builds a legitimate path whitelist on the back end for private key decryption, path verification, time validation, and replay detection. This method effectively resists sniffing and malicious exploitation while achieving non-intrusive security protection, significantly reducing the implementation cost of system security upgrades, and can be widely used in API access control, replay attack prevention, and sensitive path protection.

[0073] As shown in Figure 1 The present embodiment includes steps S1 to S6.

[0074] Step S1: Receive the original request from the client. The original request carries a dynamic token, which is generated by concatenating the original authorization token with the current timestamp and encrypting it with the public key of an asymmetric encryption algorithm on the client side.

[0075] Specifically, the original authorization token is a Token credential issued by the back end to the front end after a successful user login and cached on the client side.

[0076] Step S2: Extract the request path from the original request and determine whether the request path exists in the locally cached legitimate path list: if the request path does not exist in the locally cached legitimate path list, determine that the original request is invalid and end the process; if the request path exists in the locally cached legitimate path list, proceed to step S3.

[0077] As a specific implementation, the legal path list in step S2 is constructed by automatically scanning all controller paths in the project when the backend program is started and cached in the memory by using the reflection mechanism.

[0078] In step S2, if the request path does not exist in the legal path list, the method further includes: the backend server returns exception information to the client and pushes alarm information to the security management personnel.

[0079] Step S3: decrypt the dynamic token using a private key paired with the public key, obtain plaintext data, and extract the original authorization token and the corresponding generation timestamp therefrom.

[0080] As a specific implementation, step S3 specifically includes:

[0081] obtaining a private key paired with the public key;

[0082] wherein the public key is stored in the client and the private key is stored in the backend server;

[0083] using the private key to perform decryption processing on the dynamic token using a preset asymmetric encryption algorithm to obtain decrypted plaintext data;

[0084] parsing the plaintext data and extracting the original authorization token and the generation timestamp corresponding to the original authorization token from the plaintext data according to a predetermined data format and rule.

[0085] As a more specific implementation, the asymmetric encryption algorithm is one of RSA, SM2 national encryption algorithm, or ECC elliptic curve encryption algorithm.

[0086] Step S4: query the preset invalid token cache list and determine whether the original authorization token already exists in the invalid token cache list.

[0087] If the original authorization token already exists in the invalid token cache list, it is determined that the original request is invalid and the process is ended; if the original authorization token does not exist in the invalid token cache list, the original authorization token is written into the invalid token cache list and step S5 is entered.

[0088] Step S5: calculate the time difference between the current time of the server and the generation timestamp and determine whether the time difference is less than a preset valid time threshold.

[0089] If the time difference is greater than or equal to the preset valid time threshold, it is determined that the original request is invalid and the process is ended; if the time difference is less than the preset valid time threshold, step S6 is entered.

[0090] Specifically, the end process is completed by the aspect-oriented programming technology in the pre-interception stage, so that the business controller does not need to be entered, and the process termination is realized by directly outputting an error response.

[0091] Step S6: The original request is passed to the corresponding business logic processing module to complete the request processing based on the dynamic token.

[0092] The implementation process of the embodiment is specifically as shown in the figure and specifically includes 21 steps, which are specifically as follows: Figure 2

[0093] Step 1. Asymmetric encryption algorithm generates a key pair.

[0094] In the backend initialization stage, the system generates a pair of public and private keys by using an asymmetric encryption algorithm (such as RSA, SM2 national encryption algorithm, etc.). The key pair is used for subsequent encryption and decryption of the dynamic token, to ensure the confidentiality of the authentication information in the transmission process.

[0095] Step 2. The public key is distributed to the front end.

[0096] The generated public key is provided to the front-end client through a secure method (such as a configuration file, interface exposure, certificate distribution, etc.). The front end uses the public key to encrypt data containing sensitive information, to ensure that only the backend holding the paired private key can decrypt it.

[0097] Step 3. The private key is stored locally in the backend.

[0098] The private key paired with the public key is securely saved by the backend and is not exposed externally. The private key is used for subsequent decryption of received dynamic tokens and is the core key of the entire security mechanism. It is usually stored in a key library (such as Java Keystore, HSM, or KMS) protected by access control.

[0099] Step 4. Automatically configure and load the controller class with permissions.

[0100] When the system starts, the backend automatically scans all controller classes with specific annotations (such as @RestController, @RequestMapping, etc.) through the reflection mechanism, to identify all externally accessible API interfaces.

[0101] Step 5. Build a list of legal paths and cache.

[0102] ​Based on the scanning results of step 4, the system automatically generates a whitelist list containing all legal API paths and caches it in memory (such as ConcurrentHashMap, Redis, or Caffeine Cache) for subsequent request path verification, without the need for manual configuration to achieve path-level access control.

[0103] Step 6. Issue original authorization token upon successful login.

[0104] After the user completes identity authentication (such as account password login), the backend generates and returns an original authorization token (such as JWT or OAuth2.0 Bearer Token) as the identity credential for the user session, which is used for subsequent requests.

[0105] Step 7. Cache dynamic token on the front end.

[0106] To prevent repeated requests or improve user experience, the front end can temporarily cache the generated dynamic token. This cache is mainly used to avoid frequent encryption and sending of the same operation, and can also be used for front-end cooperation in the anti-replay strategy.

[0107] Step 8. User triggers request (start).

[0108] The user performs an operation through the front-end interface (such as clicking a button or submitting a form), triggering an API request. This behavior marks the starting point of the request process.

[0109] Step 9. Call interface function.

[0110] The front end calls the corresponding business interface function according to the user's operation, prepares the required parameters and header information for the request, and enters the request construction phase.

[0111] Step 10. Execute dynamic header generation function.

[0112] The interface function calls the "dynamic header generation function", which is responsible for constructing the encrypted authentication header. The specific operations include: obtaining the original authorization token obtained in step 6; obtaining the current client local timestamp (unit: milliseconds); concatenating the two into a plaintext string with a fixed separator (such as "|"): "Original Token|Timestamp"; using the public key provided in step 2 to perform asymmetric encryption on the string, generating a dynamic token in ciphertext form.

[0113] Step 11. Package and send request information.

[0114] The generated dynamic token is written into the HTTP request header (e.g., X-Dynamic-Token field) along with other necessary parameters to construct a complete HTTP request, which is sent to the backend server via HTTPS protocol.

[0115] Step 12. Backend path filter intercepts the request.

[0116] After the request reaches the backend, it first passes through the global path filter (which can be implemented based on AOP or Servlet Filter), extracts the request URI path, and prepares for legality verification.

[0117] Step 13. Determine if the path exists in the legal path list.

[0118] The path filter queries the legal path whitelist cached in step 5 to determine if the current request path matches any entry: if it does not exist, it means that the request target is an illegal or unregistered interface, and immediately returns a 404 or 403 error, ending the flow; if it exists, the request is allowed to continue to the next authentication verification link.

[0119] Step 14. Front-end UI displays request failure.

[0120] If intercepted at any verification link (path illegal, Token invalid, decryption failure, timeout, etc.), the backend returns an error status code (such as 403, 401) and error information, and the front-end captures and displays a "request failed" prompt on the UI, informing the user that the operation was unsuccessful.

[0121] Step 15. Token interceptor performs preliminary verification.

[0122] The request enters the Token interceptor (such as Spring Interceptor), which checks if the dynamic token already exists in the invalid token cache list. This list is used to record the dynamic tokens that have been used to prevent replay attacks.

[0123] Step 16. Determine if the dynamic token is in the invalid list.

[0124] If the current dynamic token is already recorded in the invalid list, it indicates that the request may be a repeated submission or malicious replay, and the system directly rejects and returns an abnormal response; otherwise, it continues to the decryption and timeliness verification phase.

[0125] Step 17. Invalid Token list (periodically destroyed).

[0126] To prevent the cache from growing indefinitely, the system sets a timed task to periodically clean up entries in the invalid Token list that have exceeded their expiration period (e.g., records that have exceeded 10 minutes). This mechanism balances security and performance, ensuring anti-replay capabilities while not affecting system operation efficiency.

[0127] Step 18. Decrypt the dynamic token and verify the timestamp.

[0128] The private key saved in step 3 is used to decrypt the dynamic token, restoring the original plaintext data ("original Token | timestamp") and splitting it by the delimiter to obtain two fields: the original authorization token is extracted; the timestamp generated by the client is extracted; then the time difference between the server's current time and the timestamp is calculated: if the time difference exceeds the preset threshold (e.g., 10 seconds), it is considered an expired request and access is denied; if the time difference is within the valid window, the request is considered real-time and processing is allowed to continue.

[0129] Step 19. Forward to the original interceptor and controller to process business.

[0130] After verification, the system returns the original authorization token to the original authentication interceptor (e.g., JWT verifier) to complete the standard identity verification process, and finally forwards the request to the target business controller to execute specific logic and generate response data.

[0131] Step 20. Front-end UI displays request success.

[0132] After the backend returns a successful response, the front-end receives the data and displays a "request success" prompt and related result information on the user interface, completing the normal interaction closed loop.

[0133] Step 21. Process ends.

[0134] Regardless of success or failure, this request processing flow ends here, resources are released, and the next request is triggered.

[0135] The flow of this embodiment starts from key generation (step 1), goes through path whitelist construction (steps 4~5), user request triggering (step 8), front-end dynamic token generation (steps 9~11), back-end multi-layer verification (steps 12~18), and finally realizes secure business processing (step 19) and result feedback (steps 20 / 14), forming a complete closed-loop security mechanism. The entire process does not require modification of existing business code, has high compatibility, strong security, and low invasiveness, effectively resisting risks such as interface exposure, Token leakage, and replay attacks.

[0136] The embodiment provides a request processing method based on a dynamic token, and aims at the problems that an interface path exposed by an open source component such as Swagger under a current front-end and back-end separation architecture is easy to be sniffed and utilized, a token of a stateless authentication mechanism such as JWT or OAuth2.0 is difficult to be actively revoked after being leaked and is easy to be attacked by replay, and a traditional encryption path or an IP white list has poor compatibility or limited effect, etc. The method comprises the following steps: the front end uses a public key to splice and encrypt an original authorization token and a timestamp to generate a dynamic token; the back end automatically scans and caches a legal path white list when the system starts; after receiving a request, the back end performs path legality verification, private key decryption of the dynamic token, invalid token list anti-replay detection and timestamp expiration verification in sequence; and finally, the original token is processed by an original authentication mechanism and is forwarded to a business logic. The whole process does not need to invade existing business codes, realizes effective resistance to interface detection, unauthorized access, token replay and other attacks, has high compatibility, strong security and low modification cost, and is suitable for web system security protection in high-security scenarios such as government affairs, finance and enterprise management.

[0137] Embodiment 2

[0138] As shown in Figure 3 The embodiment provides a request processing device based on a dynamic token, which is applied to a back-end server, and the device comprises:

[0139] A receiving unit 10 is used for receiving an original request from a client;

[0140] The original request carries a dynamic token, and the dynamic token is generated by splicing an original authorization token and a current timestamp and then encrypting the dynamic token by using a public key of an asymmetric encryption algorithm.

[0141] An extracting unit 20 is connected with the receiving unit 10 and is used for extracting a request path from the original request;

[0142] A first determining unit 30 is connected with the extracting unit 20 and is used for judging whether the request path exists in a local cached legal path list;

[0143] A processing unit 40 is connected with the first determining unit 30 and is used for, when the first determining unit 30 judges that the request path exists in the local cached legal path list, decrypting the dynamic token by using a private key matched with the public key, obtaining plaintext data, and extracting an original authorization token and a corresponding generation timestamp from the plaintext data;

[0144] A querying unit 50 is used for querying a preset invalid token cache list;

[0145] A second determining unit 60 is connected with the processing unit 40 and the querying unit 50 respectively, and is used for judging whether the original authorization token exists in the invalid token cache list;

[0146] The computing unit 70 is connected with the second determining unit 60, and is configured to calculate a time difference between a current time of the server and the generation timestamp when the second determining unit 60 determines that the original authorization token does not exist in the invalid token cache list;

[0147] The third determining unit 80 is connected with the computing unit 70, and is configured to determine whether the time difference is less than a preset valid time threshold;

[0148] The passing unit 90 is connected with the third determining unit 80, and is configured to pass the original request to a corresponding business logic processing module to complete the request processing based on the dynamic token when the third determining unit 80 determines that the time difference is less than the preset valid time threshold;

[0149] The ending unit 31 is connected with the first determining unit 30, the second determining unit 60 and the third determining unit 80 respectively, and is configured to determine that the original request is invalid and end the process when the first determining unit 30 determines that the request path does not exist in the local cache legal path list, or the second determining unit 60 determines that the original authorization token exists in the invalid token cache list, or the third determining unit 80 determines that the time difference is greater than or equal to the preset valid time threshold.

[0150] As a specific implementation, the processing unit 40 includes:

[0151] The obtaining module is configured to obtain a private key paired with the public key;

[0152] The public key is stored in the client, and the private key is stored in the backend server;

[0153] The first processing module is connected with the obtaining module, and is configured to use the private key to perform decryption processing on the dynamic token by using a preset asymmetric encryption algorithm, to obtain decrypted plaintext data;

[0154] The second processing module is connected with the first processing module, and is configured to parse the plaintext data, and extract the original authorization token and the generation timestamp corresponding to the original authorization token from the plaintext data according to a predetermined data format and rule.

[0155] The device in this embodiment can execute the method in embodiment 1.

[0156] Embodiment 3:

[0157] As shown in Figure 4 The electronic device includes a memory 200 and a processor 100, and the memory 200 stores a computer program, and when the processor 100 runs the computer program stored in the memory 200, the processor 100 executes the request processing method based on the dynamic token according to embodiment 1.

[0158] It is understood that the above embodiments are only exemplary for illustrating the principles of the present application, and the present application is not limited thereto. Various modifications and improvements can be made by those skilled in the art without departing from the spirit and scope of the present application, and these modifications and improvements are also considered to be within the scope of the present application.

Claims

1. A request processing method based on dynamic tokens, the method being applied to a backend server, characterized in that, The method includes the following steps: Step S1: Receive the original request from the client; The original request carries a dynamic token, which is generated by the client by concatenating the original authorization token with the current timestamp and then encrypting it with the public key of an asymmetric encryption algorithm. Step S2: Extract the request path from the original request and determine whether the request path exists in the locally cached list of valid paths. If yes, proceed to step S3; otherwise, determine that the original request is invalid and end the process. Step S3: Decrypt the dynamic token using the private key paired with the public key to obtain plaintext data, and extract the original authorization token and the corresponding generation timestamp from it; Step S4: Query the preset invalid token cache list and determine whether the original authorization token already exists in the invalid token cache list; If yes, then the original request is determined to be invalid and the process ends; if no, then the original authorization token is written to the invalid token cache list and proceeds to step S5. Step S5: Calculate the time difference between the server's current time and the generated timestamp, and determine whether the time difference is less than a preset effective time threshold; If yes, proceed to step S6; otherwise, determine that the original request is invalid and end the process. Step S6: Pass the original request to the corresponding business logic processing module to complete the request processing based on the dynamic token.

2. The request processing method based on dynamic tokens according to claim 1, characterized in that, The list of valid paths in step S2 is built by automatically scanning all controller paths in the project when the backend program starts and caching them in memory using a reflection mechanism.

3. The request processing method based on dynamic tokens according to claim 1, characterized in that, The original authorization token is a token issued by the backend to the frontend and cached on the client side after the user successfully logs in.

4. The request processing method based on dynamic tokens according to claim 1, characterized in that, In step S2, if the requested path does not exist in the list of valid paths, the method further includes: The backend server returns exception information to the client and pushes alarm information to security management personnel.

5. The request processing method based on dynamic tokens according to claim 1, characterized in that, The termination process is completed in the pre-interception stage by aspect-oriented programming technology, thus eliminating the need to enter the business controller and terminating the process by directly outputting an error response.

6. The request processing method based on dynamic tokens according to any one of claims 1 to 5, characterized in that, Step S3 specifically includes: Obtain the private key paired with the public key; The public key is stored in the client, and the private key is stored in the backend server. Using the private key, the dynamic token is decrypted using a preset asymmetric encryption algorithm to obtain the decrypted plaintext data; The plaintext data is parsed, and the original authorization token and the corresponding generation timestamp are extracted from the plaintext data according to a predetermined data format and rules.

7. The request processing method based on dynamic tokens according to claim 6, characterized in that, The asymmetric encryption algorithm is one of RSA, SM2 national cryptographic algorithm, or ECC elliptic curve cryptography algorithm.

8. A request processing device based on a dynamic token, the device being applied to a backend server, characterized in that, The device includes: The receiving unit is used to receive raw requests from the client; The original request carries a dynamic token, which is generated by the client by concatenating the original authorization token with the current timestamp and then encrypting it with the public key of an asymmetric encryption algorithm. An extraction unit, connected to the receiving unit, is used to extract the request path from the original request; The first determination unit, connected to the extraction unit, is used to determine whether the request path exists in the local cache of a list of valid paths; The processing unit, connected to the first determination unit, is used to decrypt the dynamic token using a private key paired with the public key when the first determination unit determines that the request path exists in the list of legal paths in the local cache, to obtain plaintext data, and to extract the original authorization token and the corresponding generation timestamp from it. The query unit is used to query a preset cache list of invalid tokens; The second determination unit, connected to the processing unit and the query unit respectively, is used to determine whether the original authorization token already exists in the expired token cache list; A calculation unit, connected to the second determination unit, is used to calculate the time difference between the server's current time and the generated timestamp when the second determination unit determines that the original authorization token no longer exists in the expired token cache list. The third determination unit is connected to the calculation unit and is used to determine whether the time difference is less than a preset effective time threshold. The transmission unit, connected to the third determination unit, is used to transmit the original request to the corresponding business logic processing module when the third determination unit determines that the time difference is less than a preset effective time threshold, so as to complete the request processing based on the dynamic token. The termination unit is connected to the first determination unit, the second determination unit, and the third determination unit respectively. It is used to determine that the original request is invalid and terminate the process when the first determination unit determines that the request path does not exist in the local cached list of valid paths, or the second determination unit determines that the original authorization token exists in the cached list of invalid tokens, or the third determination unit determines that the time difference is greater than or equal to a preset valid time threshold.

9. The request processing apparatus based on dynamic tokens according to claim 8, characterized in that, The processing unit includes: The acquisition module is used to acquire the private key paired with the public key; The public key is stored in the client, and the private key is stored in the backend server. The first processing module, connected to the acquisition module, is used to use the private key and a preset asymmetric encryption algorithm to decrypt the dynamic token to obtain the decrypted plaintext data. The second processing module, connected to the first processing module, is used to parse the plaintext data and extract the original authorization token and the generation timestamp corresponding to the original authorization token from the plaintext data according to a predetermined data format and rules.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and when the processor runs the computer program stored in the memory, the processor executes the request processing method based on dynamic tokens according to any one of claims 1 to 7.

Images