Request verification method and device, and computer readable storage medium

Abstract

This invention relates to, but is not limited to, the field of information processing, and provides a request verification method, apparatus, and computer-readable storage medium. The method includes: receiving request information and identifying its information type; analyzing the request information through a risk control center to obtain a suspicious verification result; recalibrating the suspicious verification result according to the importance level in the request information; when the suspicious verification result indicates the request is a normal request, forwarding the request to the application service requested by the request information; when the suspicious verification result indicates the request is a suspicious request, forwarding the request to a verification service and sending the information type to the client for verification redirection. The technical solution of this invention can separate the originally tightly coupled application service and verification service. This allows application services to adapt to the verification service without additional modifications after changes to the verification service, while also distinguishing the differences between various application services and reasonably verifying requests to application services.

Description

Technical Field

[0001] This invention relates to, but is not limited to, the field of information processing, and particularly to a request verification method, apparatus, and computer-readable storage medium. Background Technology

[0002] Internet applications often encounter abnormal requests such as malicious web crawlers and credential stuffing attacks. To defend against these abnormal requests, identity verification services can be used. An identity verification service is a public, fully automated program that can distinguish whether a user is a computer or a human, thus preventing malicious requests.

[0003] In related technologies, application services and verification services interact to intercept and verify requests. However, as services become larger, interfaces increase, and services become more numerous, the coupling between application services and verification services becomes higher. If the verification service is modified, all application services may need to be modified and adapted, causing great inconvenience. At the same time, if application services and verification services are decoupled, it is impossible to distinguish the differences between various application services on the verification service, thus making it impossible to reasonably verify requests to application services. Summary of the Invention

[0004] The following is an overview of the subject matter described in detail herein. This overview is not intended to limit the scope of the claims.

[0005] This invention provides a request verification method, apparatus, and computer-readable storage medium, which reduces the coupling between application services and verification services. As a result, after the verification service is modified, the application service can adapt to the verification service without additional modifications. Furthermore, based on the decoupling of application services and verification services, the differences between various application services are further distinguished, and requests to application services are verified reasonably.

[0006] In a first aspect, embodiments of the present invention provide a request verification method, including:

[0007] Receive request information from the client;

[0008] Identify the information type of the request information;

[0009] The risk control center performs identity verification analysis on the request information to obtain suspicious verification results.

[0010] The suspicious verification results should be recalibrated based on the importance level included in the request information;

[0011] When the suspicious verification result indicates that the request corresponding to the request information is a normal request, the request is forwarded to the application service requested by the request information;

[0012] When the suspicious verification result indicates that the request is suspicious, the request is forwarded to the verification service, and the information type is sent to the client, so that the client performs verification and redirection based on the information type.

[0013] In some embodiments, the suspicious verification result includes a suspicious score;

[0014] The step of recalibrating the suspicious verification result based on the importance level included in the request information includes:

[0015] An evaluation coefficient is determined based on the importance level, and the suspicious score is readjusted based on the evaluation coefficient.

[0016] When the suspicious score exceeds the preset suspicious score, the suspicious verification result is determined to be a suspicious request;

[0017] If the suspicious score is lower than the preset suspicious score, the suspicious verification result is determined to be a normal request.

[0018] In some embodiments, obtaining a suspicious verification result by performing identity verification analysis on the request information through the risk control center includes:

[0019] The request information is sent to the risk control center using a message middleware for identity verification and analysis.

[0020] Receive the suspicious verification results returned by the risk control center.

[0021] In some embodiments, obtaining a suspicious verification result by performing identity verification analysis on the request information through the risk control center includes:

[0022] Get local information;

[0023] The local information and the risk control center perform identity verification analysis on the request information to obtain suspicious verification results.

[0024] In some embodiments, the local information includes available resource information and pre-stored suspicious request information, wherein the available resource information is used to characterize all available service resources, and the pre-stored suspicious request information is used to characterize a set of suspicious requests;

[0025] The step of obtaining a suspicious verification result by performing identity verification analysis on the request information using the local information and the risk control center includes:

[0026] Obtain available resource information and pre-stored suspicious request information for local verification;

[0027] When a request corresponding to the pre-stored suspicious request information is detected, the suspicious verification result of the request information is determined to be a suspicious request; or...

[0028] When it is detected that the available resource information does not contain the service resource to be accessed by the request corresponding to the request information, the suspicious verification result of the request information is determined to be a suspicious request; or...

[0029] When it is detected that there is no request corresponding to the request information in the pre-stored suspicious request information, and the available resource information contains the service resources that the request corresponding to the request information wants to access, the request information is sent to the risk control center for identity verification analysis to obtain the suspicious verification result of the request information returned by the risk control center.

[0030] In some embodiments, after obtaining a suspicious verification result by performing identity verification analysis on the request information using local information and a risk control center, the method further includes:

[0031] Update the available resource information and / or the pre-stored suspicious request information based on the suspicious verification results.

[0032] In some embodiments, after forwarding the request to the verification service, the method further includes:

[0033] When it is detected that the request has been forwarded to the verification service, the verification result returned by the client is received;

[0034] When the verification result indicates that the request is a normal request, the request is forwarded to the application service requested by the request information;

[0035] When the verification result indicates that the request is a suspicious request, the request is forwarded to the verification service, and the information type is sent to the client, so that the client performs verification and redirection based on the information type.

[0036] In some embodiments, after detecting that the request has been forwarded to the verification service and receiving the verification result returned by the client, the method further includes:

[0037] Obtain available resource information and pre-stored suspicious request information, wherein the available resource information is used to represent all available service resources, and the pre-stored suspicious request information is used to represent a set of suspicious requests;

[0038] The available resource information and the pre-stored suspicious request information are updated based on the verification results and the request information.

[0039] In a second aspect, embodiments of the present invention also provide a request verification apparatus, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the request verification method as described in the first aspect.

[0040] Thirdly, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions for performing the request verification method as described in the first aspect.

[0041] This invention includes the following steps: receiving request information from a client; identifying the information type of the request information; analyzing the request information to obtain a suspicious verification result; if the suspicious verification result indicates that the request corresponding to the request information is a normal request, forwarding the request to the application service requested by the request information; or, if the suspicious verification result indicates that the request is a suspicious request, forwarding the request to the verification service and sending the information type to the client, so that the client performs verification and redirection based on the information type. According to the solution provided by this invention, upon receiving a request, the request is verified and analyzed, and the analysis result is used to determine whether the request is a suspicious request. If it is a suspicious request, the request is forwarded to the verification service; otherwise, the request is forwarded to the application service requested by the request. This separates the originally tightly coupled application service and verification service. Thus, after changes to the verification service, the application service can adapt to the verification service without additional modifications. Furthermore, based on the decoupling of the application service and the verification service, the differences between various application services are further distinguished, and requests to the application service are verified reasonably.

[0042] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0043] The accompanying drawings are provided to further understand the technical solutions of the present invention and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the technical solutions of the present invention, and do not constitute a limitation on the technical solutions of the present invention.

[0044] Figure 1 This is a flowchart of a request verification method provided in one embodiment of the present invention;

[0045] Figure 2 yes Figure 1 The flowchart of the specific method for step S140 in the embodiment shown is as follows;

[0046] Figure 3 yes Figure 1 The flowchart of the specific method for step S130 in the embodiment shown is as follows;

[0047] Figure 4 yes Figure 1 Another specific method flowchart for step S130 in the illustrated embodiment;

[0048] Figure 5 yes Figure 1 The flowchart illustrates the specific method after forwarding the request to the verification service in step S160 of the illustrated embodiment.

[0049] Figure 6 yes Figure 5 A flowchart illustrating the specific method following step S710 in the illustrated embodiment;

[0050] Figure 7 This is a schematic diagram of a request processing flow based on Nginx provided in another embodiment of the present invention;

[0051] Figure 8 This is a schematic diagram of an architecture for request processing using MySQL and Nginx, provided in another embodiment of the present invention;

[0052] Figure 9 This is a structural diagram of a request verification device provided in another embodiment of the present invention. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0054] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, or the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0055] This invention provides a request verification method, apparatus, and computer-readable storage medium. The method includes: receiving request information from a client; identifying the information type of the request information; analyzing the request information to obtain a suspicious verification result; if the suspicious verification result indicates that the request corresponding to the request information is a normal request, forwarding the request to the application service requested by the request information; or, if the suspicious verification result indicates that the request is a suspicious request, forwarding the request to a verification service and sending the information type to the client, so that the client performs verification redirection based on the information type. According to the solution provided by this invention, upon receiving a request, the request is verified and analyzed, and the analysis result is used to determine whether the request is a suspicious request. If it is a suspicious request, the request is forwarded to the verification service; otherwise, the request is forwarded to the application service requested by the request. This separates the originally tightly coupled application service and verification service. Thus, after changes to the verification service, the application service can adapt to the verification service without additional modifications. Furthermore, based on the decoupling of the application service and the verification service, the differences between various application services are further distinguished, and requests to the application service are verified reasonably.

[0056] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results. In other words, artificial intelligence is a comprehensive technology within computer science that attempts to understand the essence of intelligence and produce a new kind of intelligent machine that can react in a way similar to human intelligence.

[0057] Artificial intelligence (AI) studies the design principles and implementation methods of various intelligent machines, enabling them to perceive, reason, and make decisions. Fundamental AI technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning. With the advancement of AI research, its applications are expanding into various fields, such as smart homes, intelligent customer service, virtual assistants, smart speakers, intelligent marketing, autonomous driving, robotics, and smart healthcare. It is believed that with further technological development, AI will be applied in even more areas and play an increasingly important role.

[0058] Machine Learning (ML) is a multidisciplinary field that involves probability theory, statistics, approximation theory, convex analysis, algorithm complexity theory, and many other disciplines. It specifically studies how computers can simulate or implement human learning behavior to acquire new knowledge or skills and reorganize existing knowledge structures to continuously improve their performance.

[0059] Machine learning is the core of artificial intelligence and the fundamental way to endow computers with intelligence. Its applications span all areas of artificial intelligence. Machine learning and deep learning typically include techniques such as artificial neural networks, belief networks, reinforcement learning, transfer learning, and inductive learning.

[0060] It should be noted that the request verification method in this embodiment of the invention can be applied to scenarios of Internet request identity verification, such as distinguishing whether the request is sent by a computer or a person, identifying whether it is a suspicious request based on the request history, etc. The request verification method in this embodiment of the invention can identify whether the received request is a suspicious request and perform different service forwarding processing based on the verification result.

[0061] First, let's clarify some of the terms used in this invention:

[0062] Verification services can be programs that distinguish between users who are computers and humans, preventing abnormal behaviors or malicious requests such as: malicious password cracking, vote rigging, forum spamming, malicious web scraping, credential stuffing, and brute-force login attempts against a specific registered user. They generally include CAPTCHA verification, image verification, click verification, and swipe verification.

[0063] A risk control center typically includes a gateway, management system, rule engine, big data storage warehouse, and big data computing engine. Based on information such as the number of client requests per unit time, blacklists / whitelists, and historical records, the risk control system can asynchronously analyze and record requests according to certain rules to identify suspicious requests. Specifically, the gateway receives requests from similar systems, helping to identify the reliability of the requests; the management system maintains request-related information, which can include the request URI, type (API, HTML page), source IP, User-Agent, Cookie, and the number of requests per unit time. Whenever developers add a new API, the management system automatically adds the API information to the request-related information; the rule engine analyzes whether a request is suspicious; the big data storage warehouse stores the requests that need to be verified, providing a large amount of reliable data to the rule engine for more accurate analysis; and the big data computing engine filters usable request data, improving the validity of the requests used for analysis.

[0064] The embodiments of the present invention will be further described below with reference to the accompanying drawings.

[0065] like Figure 1 As shown, Figure 1 This is a flowchart of a request verification method provided in one embodiment of the present invention. The method includes, but is not limited to, steps S110, S120, S130, S140, S150, and S160.

[0066] Step S110: Receive request information from the client;

[0067] Understandably, request information may include the request URI, type (API, HTML page), source IP, User-Agent, Cookie, and other information.

[0068] Step S120: Identify the information type of the request information;

[0069] It's worth noting that the received request information can be compared with pre-stored request-related information in the database. When a matching request is found, the request type can be retrieved from the pre-stored information. Furthermore, request-related information can be stored in Redis, and when the server uses Nginx for request processing, Ngx_Lua's shared memory can also be used to store this information.

[0070] Furthermore, in this embodiment of the invention, both a database and Redis can be used to store request-related information simultaneously. When the server uses Nginx for request processing, both the database and shared memory provided by Ngx_Lua can be used to store request-related information. Using a database, and then using Redis or shared memory provided by Ngx_Lua to store request-related information, ensures that request-related information is maintained stably in the database for a long period, alleviates high-concurrency access to the database, and improves request response speed.

[0071] It's also worth noting that when using a database, and further utilizing Redis or Ngx_Lua's shared memory to store request-related information, all relevant request information can be stored in the database first. For example, whenever a new interface is added to the application service, the request-related information for that new interface is added to the database, thus maintaining all request-related information in the database. Then, the request-related information in the database is periodically transferred to Redis or Ngx_Lua's shared memory. When a client request is received, the received request information is compared with the pre-stored request-related information in Redis or Ngx_Lua's shared memory. When a matching request is found, the corresponding request type can be obtained from the pre-stored request-related information, thereby alleviating high-concurrency access to the database and improving request response speed. Furthermore, the timeliness of transferring request-related information from the database can be improved by shortening the time interval or using a distributed approach.

[0072] It should also be noted that the pre-stored request-related information may include the request URI, information type (interface, HTML page), etc.; the shared memory provided by Redis or Ngx_Lua mentioned above can also use other data storage methods.

[0073] For example, in this embodiment of the invention, when using Nginx for request processing and applying MySQL and Ngx_Lua to store request-related information in shared memory, the request-related information, such as the request URI and information type (interface, HTML page), can be maintained in a MySQL table first. Each time a new interface is added, the relevant information is added to the table. Then, the request-related information stored in the MySQL table is periodically transferred to the shared memory provided by Ngx_Lua. When Nginx receives a request, it compares the request information with the request-related information stored in the shared memory provided by Ngx_Lua to obtain the information type of the request.

[0074] Step S130: The risk control center performs identity verification analysis on the request information to obtain suspicious verification results;

[0075] It should be noted that upon receiving a request, the request information can be sent to the risk control center for identity verification and analysis to obtain the analyzed suspicious verification results. Alternatively, the request information can be compared and analyzed with pre-stored suspicious request information to obtain the analyzed suspicious verification results. Furthermore, the request information can be analyzed by combining the risk control center's analysis with pre-stored suspicious request information, thus ensuring both analysis speed and the accuracy of the suspicious verification results.

[0076] For example, when the embodiments of the present invention are applied to the situation where the risk control center and pre-stored suspicious request information are combined to analyze the request information, for example, after receiving a request, the request information is first compared and analyzed with the pre-stored suspicious request information. When the request cannot be found from the pre-stored suspicious request information, the request information is then sent to the risk control center for identity verification analysis and the analyzed suspicious verification result is obtained. By combining the request information with the pre-stored suspicious request information for analysis, both the speed of analysis and the accuracy of the suspicious verification result can be guaranteed.

[0077] It should also be noted that the request information may include the number of requests per unit time. After the request information is sent to the risk control center, the risk control center will perform identity verification and analysis on the request information based on the number of requests per unit time, the pre-stored request blacklists and whitelists, historical records, and other information in the request information.

[0078] Additionally, it's worth noting that when the server receives a request, it recalculates the request count per unit time based on previously recorded data and updates the new count in the database and / or Redis. This allows for rapid updates to the request count per unit time. When the server uses Nginx for request processing, the recalculated request count per unit time can also be updated in the shared memory provided by Ngx_Lua.

[0079] For example, in this embodiment of the invention, only the database is used to store request-related information. The unit time in the request count per unit time is set to 1 hour. When the server receives a request, it checks whether the statistical time in the request count per unit time is within 1 hour. If it is within 1 hour, the original request count per unit time is incremented by 1, indicating that another access was made within the unit time. If it is not within 1 hour, the request count per unit time is set to 1, indicating that the number of accesses increases from 0 to 1 within the new unit time. This reduces the time consumed in the calculation process, thereby quickly updating the request count per unit time. Furthermore, updating the request count per unit time in the shared memory provided by Redis or Ngx_Lua follows the same steps, which will not be elaborated here. After updating the request count per unit time, the server sends the latest request information to the risk control center. The risk control center performs identity verification analysis based on the new request count per unit time, pre-stored request blacklists and whitelists, historical records, and other information in the request information.

[0080] Furthermore, it is understandable that after the server sends a request to the risk control center for identity verification analysis, the risk control center will return a suspicious verification result to the server.

[0081] Step S140: Recalibrate the suspicious verification results according to the importance level included in the request information;

[0082] It should be noted that the importance of various application services varies depending on the type of business and the focus of related interests. Therefore, the importance of requests corresponding to various application services also varies. Based on the different levels of importance, the requirements for passing the request also differ. Therefore, it can be understood that the request information may contain the importance level of the corresponding application service. The importance level can be used to block or relax the passage of the request based on the degree of importance, further distinguishing the differences between various application services and reasonably verifying the request to the application service.

[0083] Step S150: When the suspicious verification result shows that the request corresponding to the request information is a normal request, the request is forwarded to the application service requested by the request information.

[0084] Step S160: When the suspicious verification result indicates that the request is suspicious, the request is forwarded to the verification service, and the information type is sent to the client so that the client can perform verification and redirection according to the information type.

[0085] It's important to note that the suspicious verification result can include a suspicious flag, which determines whether the request is legitimate or suspicious. When the suspicious verification result indicates a suspicious request, it is forwarded to the verification service. Since requests can have different types (e.g., an HTML page or an API), the client needs to perform different verification redirects based on the type (e.g., if the URI is an HTML page, the client is redirected to the verification page for verification; if the URI is an API, the server can return a response code to notify the client that the request failed and requires verification). At this point, information type needs to be sent to the client so that the client can cooperate with the verification service to perform different verification redirects based on the different request types.

[0086] For example, in an embodiment of the present invention, after receiving a request, the server identifies the request as an HTML page type through pre-stored request information and analyzes the request as a suspicious request through pre-stored suspicious request information. At this time, the server forwards the request to the verification service. The server then sends the request information type to the client, and the client is redirected to the corresponding HTML verification page for verification based on the information type.

[0087] Additionally, refer to Figure 2 In one embodiment, the suspicious verification result may include, but is not limited to, a suspicious score. Based on this, Figure 1 Step S140 in the illustrated embodiment includes, but is not limited to, steps S210 and S220:

[0088] Step S210: Determine the evaluation coefficient based on the importance level, and readjust the suspicious score based on the evaluation coefficient;

[0089] Step S220: When the suspicious score exceeds the preset suspicious score, the suspicious verification result is determined to be a suspicious request;

[0090] Step S230: When the suspicious score is lower than the preset suspicious score, the suspicious verification result is determined to be a normal request.

[0091] It is understandable that the importance of various application services varies depending on the type of business and the focus of related interests. Therefore, the importance of requests corresponding to various application services also varies. Based on the different importance, the requirements for request approval also vary. Based on this, the following proposes various embodiments for identity verification analysis based on importance level.

[0092] It should be noted that when a request is sent to the risk control center, the center can assign a suspicion score to determine the level of suspicion. If the suspicion score exceeds a preset value, the request will be deemed suspicious. However, sometimes, some application services that require frequent user requests may be mistakenly identified as suspicious, causing unnecessary trouble for users. With the introduction of importance levels, the suspicion score can be modified accordingly. The modification can be done by determining an evaluation coefficient based on the importance level. After obtaining the evaluation coefficient, the original suspicion score can be added to or subtracted to obtain a new suspicion score.

[0093] For example, the suspiciousness score can be from 1 to 100, and the preset suspiciousness score can be 50. When the suspiciousness score of a request exceeds 50, the server will determine the request as a suspicious request. The importance level can be divided into 1 to 20. Taking the importance level as equal to the evaluation coefficient as an example (i.e., when the value of the importance level is equal to the value of the evaluation coefficient), when the importance level is 8 or below, the evaluation coefficient can be subtracted from the original suspiciousness score to obtain the final suspiciousness score. For example, in some embodiments of the present invention, the risk control center receives a request information and analyzes that the suspiciousness score of the request is 55. However, the importance level in the request information is 7. Due to the influence of the importance level, the final suspiciousness score of the request can be the difference between the suspiciousness score and the importance level, that is, the final suspiciousness score is 48. Since 48 does not exceed 50, after receiving the suspiciousness verification result, the server will finally re-determine that the request is a normal request suspiciousness verification result. This result fully considers the important indicators of the request and reduces the possibility of misjudging relatively unimportant requests as suspicious requests.

[0094] For example, the suspiciousness score can be from 1 to 90, and the preset suspiciousness score can be 60. When the suspiciousness score of a request exceeds 60, the server will determine the request as a suspicious request. The importance level can be divided into 1 to 15. Taking the evaluation coefficient as twice the importance level as an example (that is, when the value of the evaluation coefficient is equal to twice the value of the importance level), when the importance level is 10 or above, the evaluation coefficient can be added to the original suspiciousness score to obtain the final suspiciousness score. For example, in some embodiments of the present invention, the risk control center receives a request information and analyzes that the suspiciousness score of the request is 55. However, the importance level in the request information is 3. At this time, it can be determined that the evaluation coefficient is twice the importance level, that is, 6. Due to the influence of the evaluation coefficient, the final suspiciousness score of the request can be the sum of the suspiciousness score and the evaluation coefficient, that is, the final suspiciousness score is 61. Since 61 exceeds 60, after receiving the suspiciousness verification result, the server will finally re-determine that the request is a suspicious request. This result fully considers the important indicators of the request and strengthens the protection of important application services.

[0095] It should be noted that the preset suspicious score, importance level, and evaluation coefficient can be set according to the actual importance of the application service. The calculation method of adding or subtracting the importance level on the original suspicious score can also be adjusted. For example, the importance level can be between 0 and 1.5. Taking the importance level equal to the evaluation coefficient as an example, the evaluation coefficient can be used as a multiplication factor to multiply the original suspicious score to obtain a final suspicious score. The importance level can also be used as the weighting basis for suspicious request analysis, thereby changing the impact of information such as the number of client requests per unit time and historical records on the suspicious score in combination with the importance of the application service.

[0096] Based on the above embodiments of the present invention, it can be understood that the importance level allows the application service to still reflect the importance of the application service to some extent after the application service and the verification service are decoupled, further distinguishing the differences between various application services, and making different verification strategies to reasonably verify requests to the application service.

[0097] Additionally, refer to Figure 3 In one embodiment, Figure 1 Step S130 in the illustrated embodiment includes, but is not limited to, steps S310 and S320:

[0098] Step S310: Use message middleware to send request information to the risk control center for identity verification and analysis;

[0099] Step S320: Receive the suspicious verification result returned by the risk control center.

[0100] It's worth noting that using message queues to send request information to the risk control center allows the server to forward the request information to the risk control center at the appropriate time due to the queueing and asynchronous mechanisms of the message queue. This avoids waiting time due to invalid tasks and improves the efficiency of processing request information. Furthermore, message queues can separate the request processing server and the risk control center, thereby decoupling business logic and reducing interaction and maintenance costs.

[0101] Understandably, message middleware can include Kafka, ActiveMQ, RabbitMQ, RocketMQ, etc.

[0102] Additionally, refer to Figure 4 In one embodiment, Figure 1 Step S130 in the illustrated embodiment includes, but is not limited to, steps S410 and S420:

[0103] Step S410: Obtain local information;

[0104] Step S420: The identity verification analysis of the request information is performed using local information and the risk control center to obtain suspicious verification results.

[0105] It should be noted that local information can be stored in a database or Redis. When the server uses Nginx to process requests, it can also use Ngx_Lua's shared memory to store local information. In addition, local information can be stored in both a database and Redis, which will not be elaborated on here.

[0106] Additionally, it should be noted that local information can be resource address information related to the request, such as URI, URL, etc., or historical suspicious requests that can help identify suspicious requests, etc., which will not be elaborated on here.

[0107] Additionally, it should be noted that in this embodiment of the invention, in addition to utilizing local information, further identity verification can be performed in conjunction with the risk control center to make the verification results more accurate. For example, if the received request is identified as a normal request through local information, the request information corresponding to the request can be further forwarded to the risk control center for identification to obtain a more accurate verification result.

[0108] In another embodiment, the local information may include, but is not limited to, available resource information and pre-stored suspicious request information. It should be noted that the available resource information is used to characterize all available service resources, and the pre-stored suspicious request information is used to characterize the set of suspicious requests. Based on this, step S400 in the above embodiment includes, but is not limited to, step S510 and judgment C520.

[0109] Step S510: Obtain available resource information and pre-stored suspicious request information for local verification;

[0110] It should be noted that available resource information can be stored in a database, or in Redis. When the server uses Nginx for request processing, it can also use Ngx_Lua's shared memory to store available resource information.

[0111] Furthermore, in this embodiment of the invention, both a database and Redis can be used simultaneously to store available resource information. When the server uses Nginx for request processing, both the database and shared memory provided by Ngx_Lua can be used to store available resource information. By using a database and then using Redis or shared memory provided by Ngx_Lua as a data transfer station to store available resource information, request-related information can be maintained stably in the database for a long period, and high-concurrency access to the database can be alleviated, thus improving request response speed.

[0112] It's also worth noting that pre-stored suspicious request information can include client identifiers such as the request's source IP, User-Agent, and cookies. This information can be stored in a database or via Redis. When the server uses Nginx for request processing, Ngx_Lua's shared memory can also be used to store the pre-stored suspicious request information. Furthermore, both a database and Redis can be used simultaneously when storing pre-stored suspicious request information. Using a database and then employing Redis or Ngx_Lua's shared memory as a data intermediary to store pre-stored suspicious request information ensures long-term stable maintenance of this information in the database, alleviates high-concurrency access to the database, and improves request response speed.

[0113] In C520, if a request corresponding to a pre-stored suspicious request is detected, the suspicious verification result of the request is determined to be a suspicious request; or...

[0114] When it is detected that the available resource information does not contain the service resource that the request wants to access, the suspicious verification result of the request information is determined to be a suspicious request.

[0115] It should be noted that the suspicious request verification result can include a suspicious flag, which can be used to determine whether the request is a normal request or a suspicious request. When a request corresponding to the requested information is detected in the pre-stored suspicious request information, a suspicious flag can be added to the suspicious request verification result to confirm that the request information's suspicious verification result is a suspicious request. At the same time, the newly identified suspicious request is added to the pre-stored suspicious request information to improve the speed of subsequent suspicious request analysis.

[0116] Additionally, it should be noted that when the available resource information does not include the service resource requested, that is, the target application requested may not exist, a suspicious flag can be added to the suspicious verification result to determine that the suspicious verification result of the request information is a suspicious request. The request information can then be added to the pre-stored suspicious request information. This can greatly reduce the number of invalid requests by reducing the time required for verification, and may even block invalid requests.

[0117] Furthermore, it's understandable that when available resource information doesn't include the requested service resource, it might be because the currently obtained available resource information hasn't been updated in a timely manner. For example, when using a database and Redis to store available resource information, with Redis as a data intermediary, the available resource information in Redis might not include the requested service resource. However, this doesn't mean the available resource information in the database doesn't include it. In this case, the available resource information in Redis can be updated based on the database, ensuring the accuracy of the available resource information. Alternatively, if only the database is used to store available resource information, the update time of the available resource information might be very close to the time the available resource information was obtained, leading to discrepancies between the obtained information and the actual situation. In this case, the available resource information can be obtained again to ensure its accuracy. Alternatively, only the additional newly added parts of the available resource information can be obtained, ensuring accuracy while reducing the amount of data accessed and thus reducing the access burden.

[0118] In the C520 judgment, a judgment can also be added: when it is detected that there is no corresponding request in the pre-stored suspicious request information, and the available resource information contains the service resource that the corresponding request wants to access, the request information is sent to the risk control center for identity verification analysis to obtain the suspicious verification result of the request information returned by the risk control center.

[0119] Understandably, when there is no request in the pre-stored suspicious request information, and the available resource information contains the service resource that the request wants to access, meaning that the information stored locally cannot guarantee that the request is a normal request, the request information can be sent to the risk control center for further identity verification and analysis to improve the accuracy of analyzing suspicious requests.

[0120] It is also understandable that after the server performs identity verification analysis on the requested information to the risk control center, the risk control center will return a suspicious verification result to the server.

[0121] Additionally, in one embodiment, in Figure 4 In the illustrated embodiment, after obtaining a suspicious verification result, the process further includes, but is not limited to, step S600:

[0122] Step S600: Update the available resource information and / or pre-stored suspicious request information based on the suspicious verification results and request information.

[0123] It should be noted that when the suspicious request verification result indicates that the request is suspicious, the request can be added to the pre-stored suspicious request information; when the suspicious request verification result indicates that the request is normal, and the request is present in the pre-stored suspicious request information, the request is removed from the pre-stored suspicious request information; when the suspicious request verification result indicates that the request is normal, and the request is not present in the available resource information, the address and other information of the service resource that the request information seeks to access can be added to the available resource information to ensure the accuracy and timeliness of the available resource information.

[0124] Understandably, when the address and other information of the service resource to be accessed by the request are added to the available resource information, if the target of the request still does not exist, the request can be regarded as a suspicious request and forwarded to the verification service. The relevant information of the service resource to be accessed by the request is removed from the available resource information and added to the pre-stored suspicious request information. By reducing the time required for verification, the number of invalid requests can be greatly reduced, or even invalid requests can be blocked.

[0125] Additionally, it should be noted that the suspicious verification result may include a suspicious flag, which can be used to determine whether the request is a normal request or a suspicious request.

[0126] Additionally, refer to Figure 5 In one embodiment, Figure 1 After forwarding the request to the verification service in step S160 of the illustrated embodiment, the steps also include, but are not limited to, steps S710, S720, and S730:

[0127] Step S710: When it is detected that the request has been forwarded to the verification service, receive the verification result returned by the client;

[0128] Understandably, when a request is forwarded to the authentication service, the client needs to authenticate itself, and after authentication, an authentication result will be returned.

[0129] Step S720: When the verification result shows that the request is a normal request, the request is forwarded to the application service requested by the request information.

[0130] Step S730: When the verification result indicates that the request is a suspicious request, the request is forwarded to the verification service, and the information type is sent to the client so that the client performs verification and redirection according to the information type.

[0131] It's important to note that the verification result can be determined by whether the request passes verification. If the verification flag is present, the request is considered legitimate; otherwise, it's deemed suspicious. If the request is legitimate, it's forwarded to the application service requested by the request information. If the request is suspicious, it's forwarded to the verification service, and the request type information is sent to the client. This allows the client to cooperate with the verification service to perform different verification redirects based on the request type. Furthermore, if the request is suspicious, it can remain on the verification page without further redirection until verification is successful, reducing the server's access load.

[0132] Additionally, refer to Figure 6 In one embodiment, Figure 5 Following step S710 in the illustrated embodiment, there are, but are not limited to, steps S810 and S820:

[0133] Step S810: Obtain available resource information and pre-stored suspicious request information, wherein the available resource information is used to characterize all available service resources, and the pre-stored suspicious request information is used to characterize the set of suspicious requests;

[0134] It should be noted that available resource information can be stored in a database, or in Redis. When the server uses Nginx for request processing, it can also use Ngx_Lua's shared memory to store available resource information.

[0135] Furthermore, in this embodiment of the invention, both a database and Redis can be used simultaneously to store available resource information. When the server uses Nginx for request processing, both the database and shared memory provided by Ngx_Lua can be used to store available resource information. By using a database and then using Redis or shared memory provided by Ngx_Lua as a data transfer station to store available resource information, request-related information can be maintained stably in the database for a long period, and high-concurrency access to the database can be alleviated, thus improving request response speed.

[0136] It's important to note that pre-stored suspicious request information can include client identifiers such as the request's source IP, User-Agent, and cookies. This information can be stored in a database or via Redis. When the server uses Nginx for request processing, Ngx_Lua's shared memory can also be used to store the pre-stored suspicious request information. Furthermore, both a database and Redis can be used simultaneously when storing pre-stored suspicious request information. Using a database along with Redis or Ngx_Lua's shared memory as a data intermediary ensures long-term stable maintenance of the pre-stored suspicious request information in the database, alleviates high-concurrency access to the database, and improves request response speed.

[0137] Step S820: Update the available resource information and pre-stored suspicious request information based on the verification results and request information.

[0138] It should be noted that if the verification result indicates that the request is a suspicious request, the request can be added to the pre-stored suspicious request information; if the verification result indicates that the request is a normal request, and the request is present in the pre-stored suspicious request information, the request can be removed from the pre-stored suspicious request information; if the verification result indicates that the request is a normal request, and the request is not present in the available resource information, the address and other information of the service resource that the request information seeks to access can be added to the available resource information to ensure the accuracy of the available resource information.

[0139] Understandably, when the address and other information of the service resource to be accessed by the request are added to the available resource information, if the target of the request still does not exist, the request can be regarded as a suspicious request and forwarded to the verification service. The relevant information of the service resource to be accessed by the request is removed from the available resource information and added to the pre-stored suspicious request information. By reducing the time required for verification, the number of invalid requests can be greatly reduced, or even invalid requests can be blocked.

[0140] Additionally, it should be noted that suspicious verification results may include a verification flag indicating whether the verification passed. This flag can be used to determine whether the request passed verification, i.e., whether the request is a normal request or a suspicious request.

[0141] Additionally, refer to Figure 7 , Figure 7 This is a schematic diagram of a request processing flow based on Nginx provided in another embodiment of the present invention.

[0142] like Figure 7As shown in this embodiment of the invention, firstly, Nginx receives a request and can obtain client identifiers such as the source IP, User-Agent, and Cookie from the request. Then, it compares the request with all pre-stored request information in the shared memory provided by Ngx_Lua to check if the request exists in the shared memory. If the request exists, it can choose to send the request to the risk control center for further analysis or directly forward the request to the specific application service. If the request does not exist in the shared memory or is sent to the risk control center for further analysis, it is considered a valid request, and the client enters the verification page. When the user passes the verification, the request-related information in the shared memory can be cleared, and then it can be updated to ensure the accuracy of the request-related information in the shared memory. If the verification fails, the client can choose to remain on the verification page. After successful verification, the client identifiers such as the source IP, User-Agent, and Cookie are sent to the risk control center for storage as data to be considered during analysis. Finally, the verified request is forwarded to the specific application service. This technical solution separates the application service from the verification service, thereby decoupling the application service from the verification service.

[0143] Additionally, refer to Figure 8 , Figure 8 This is a schematic diagram of an architecture for request processing using MySQL and Nginx, provided in another embodiment of the present invention. Figure 9 In this embodiment of the invention, after receiving a request, Nginx identifies the request type by periodically acquiring relevant request information, enabling the client to perform verification based on different request types. Nginx can also forward the request to the risk control center for suspicious request analysis and store the analyzed suspicious requests in shared memory provided by Ngx_Lua to speed up the next verification analysis. When the analysis shows that the request is a normal request, it is forwarded to the corresponding application service. When the analysis shows that the request is a suspicious request, it is connected to the verification service, thereby separating the application service from the verification service and completing the decoupling of the application service and the verification service.

[0144] Additionally, refer to Figure 9 Another embodiment of the present invention also provides a request verification device, the device 1000 including: a memory 1010, a processor 1020 and a computer program stored in the memory 1010 and executable on the processor 1020.

[0145] The processor 1020 and the memory 1010 can be connected via a bus or other means.

[0146] The non-transient software program and instructions required to implement the request verification method of the above embodiments are stored in the memory 1010. When executed by the processor 1020, the request verification method in the above embodiments is executed, for example, the method described above is executed. Figure 1 Method steps S110 to S160, Figure 2 Method steps S210 to S230, Figure 3 Method steps S310 to S320, step S400 Figure 4 Method steps S510 to S540, step S600 Figure 5 Method steps S710 to S730, Figure 6 The method steps S810 to S820 are described above. The apparatus embodiments described above are merely illustrative; the units described as separate components may or may not be physically separated, i.e., they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0147] Furthermore, one embodiment of the present invention provides a computer-readable storage medium storing computer-executable instructions that are executed by a processor or controller, for example, by a processor in the above-described request verification device embodiment, causing the processor to perform the request verification method in the above-described embodiment, for example, performing the above-described... Figure 1 Method steps S110 to S160, Figure 2 Method steps S210 to S230, Figure 3 Method steps S310 to S320, step S400 Figure 4 Method steps S510 to S540, step S600 Figure 5 Method steps S710 to S730, Figure 6The method steps S810 to S820 are described above. Those skilled in the art will understand that all or some of the steps and systems disclosed in the above-disclosed methods can be implemented as software, firmware, hardware, or suitable combinations thereof. Some or all physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible by a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0148] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of the present invention.

Claims

1. A request verification method, applied to a server, the method comprising: Receive request information from the client; Identify the information type of the request information; The risk control center performs identity verification analysis on the request information to obtain suspicious verification results, wherein the suspicious verification results include a suspicious score; The process of recalibrating the suspicious verification result based on the importance level included in the request information includes: determining an evaluation coefficient based on the importance level; when the importance level is less than a preset level threshold, subtracting the evaluation coefficient from the suspicious score to obtain a corrected suspicious score; when the importance level is greater than the preset level threshold, adding the evaluation coefficient to the suspicious score to obtain a corrected suspicious score; when the corrected suspicious score exceeds a preset suspicious score, determining the suspicious verification result as a suspicious request; and when the corrected suspicious score is lower than the preset suspicious score, determining the suspicious verification result as a normal request. When the suspicious verification result indicates that the request corresponding to the request information is a normal request, the request is forwarded to the application service requested by the request information; When the suspicious verification result indicates that the request is suspicious, the request is forwarded to the verification service, and the information type is sent to the client, so that the client performs verification and redirection based on the information type.

2. The method of claim 1, wherein, The step of obtaining suspicious verification results by performing identity verification analysis on the request information through the risk control center includes: The request information is sent to the risk control center using a message middleware for identity verification and analysis. Receive the suspicious verification results returned by the risk control center.

3. The method of claim 1, wherein, The step of obtaining suspicious verification results by performing identity verification analysis on the request information through the risk control center includes: Get local information; The local information and the risk control center perform identity verification analysis on the request information to obtain suspicious verification results.

4. The method of claim 3, wherein, The local information includes available resource information and pre-stored suspicious request information, wherein the available resource information is used to represent all available service resources, and the pre-stored suspicious request information is used to represent a set of suspicious requests; The step of obtaining a suspicious verification result by performing identity verification analysis on the request information using the local information and the risk control center includes: Obtain available resource information and pre-stored suspicious request information for local verification; When a request corresponding to the pre-stored suspicious request information is detected, the suspicious verification result of the request information is determined to be a suspicious request; or... When it is detected that the available resource information does not contain the service resource to be accessed by the request corresponding to the request information, the suspicious verification result of the request information is determined to be a suspicious request; or... When it is detected that there is no request corresponding to the request information in the pre-stored suspicious request information, and the available resource information contains the service resources that the request information wants to access, the request information is sent to the risk control center for identity verification analysis to obtain the suspicious verification result of the request information returned by the risk control center.

5. The method according to claim 4, characterized in that, After obtaining a suspicious verification result by performing identity verification analysis on the request information using local information and the risk control center, the method further includes: Update the available resource information and / or the pre-stored suspicious request information based on the suspicious verification results and the request information.

6. The method according to claim 1, characterized in that, After forwarding the request to the verification service, the method further includes: When it is detected that the request has been forwarded to the verification service, the verification result returned by the client is received; When the verification result indicates that the request is a normal request, the request is forwarded to the application service requested by the request information; When the verification result indicates that the request is a suspicious request, the request is forwarded to the verification service, and the information type is sent to the client, so that the client performs verification and redirection based on the information type.

7. The method according to claim 6, characterized in that, After detecting that the request has been forwarded to the verification service and receiving the verification result returned by the client, the method further includes: Obtain available resource information and pre-stored suspicious request information, wherein the available resource information is used to represent all available service resources, and the pre-stored suspicious request information is used to represent a set of suspicious requests; The available resource information and the pre-stored suspicious request information are updated based on the verification results and the request information.

8. A request verification device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, when the processor executes the computer program, it implements the request verification method as described in any one of claims 1 to 7.

9. A computer-readable storage medium storing computer-executable instructions for performing the request verification method as described in any one of claims 1 to 7.

Images