Abnormal request determination method and device, equipment, storage medium and program product
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BIGO TECH PTE LTD
- Filing Date
- 2022-06-09
- Publication Date
- 2026-06-19
Smart Images
Figure CN115048639B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the fields of computer and internet technology, and in particular to a method, apparatus, device, storage medium, and program product for determining abnormal requests. Background Technology
[0002] In the fields of computers and the Internet, it is necessary to intercept some abnormal requests in order to avoid performing unnecessary operations or to improve system security.
[0003] In related technologies, certain static security policies are set on the server to intercept abnormal requests from specific users. For example, the server obtains static information such as the IP (Internet Protocol) address of some specific unauthorized users in advance, and sets corresponding static security policies to block the information sent by the unauthorized users.
[0004] However, the above method can only intercept abnormal requests known to be sent by illegitimate users, and cannot effectively intercept abnormal requests that have not yet been determined to be sent by illegitimate users. Summary of the Invention
[0005] This application provides a method, apparatus, device, storage medium, and program product for determining abnormal requests.
[0006] According to one aspect of the embodiments of this application, a method for determining abnormal requests is provided, the method comprising:
[0007] Obtain feature information of the target request, wherein the feature information of the target request is used to indicate the features corresponding to the target request;
[0008] Based on m security strategies, m scores corresponding to the target request are determined according to the feature information of the target request; wherein, the m security strategies and the m scores are in one-to-one correspondence, and the score corresponding to the i-th security strategy among the m security strategies is used to indicate the probability that the target request determined based on the i-th security strategy is an abnormal request, where m is an integer greater than 1 and i is a positive integer less than or equal to m.
[0009] The total score of the target request is determined based on the m scores corresponding to the target request;
[0010] If the total score of the target request meets the conditions, then the target request is determined to be the abnormal request.
[0011] According to one aspect of the embodiments of this application, an apparatus for determining abnormal requests is provided, the method comprising:
[0012] An information acquisition module is used to acquire feature information of a target request, wherein the feature information of the target request is used to indicate the features corresponding to the target request;
[0013] The scoring determination module is used to determine m scores corresponding to the target request based on m security policies and the feature information of the target request; wherein, the m security policies and the m scores are in one-to-one correspondence, and the score corresponding to the i-th security policy among the m security policies is used to indicate the probability that the target request determined based on the i-th security policy is an abnormal request, where m is an integer greater than 1 and i is a positive integer less than or equal to m;
[0014] The total score determination module is used to determine the total score of the target request based on the m scores corresponding to the target request;
[0015] The request judgment module is used to determine that the target request is the abnormal request if the total score of the target request meets the conditions.
[0016] According to one aspect of the embodiments of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the above-described method for determining abnormal requests.
[0017] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, the storage medium storing a computer program, the computer program being loaded and executed by a processor to implement the above-described method for determining abnormal requests.
[0018] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including computer instructions stored in a computer-readable storage medium, wherein a processor reads from the computer-readable storage medium and executes the computer instructions to implement the above-described method for determining abnormal requests.
[0019] The technical solutions provided in this application have at least the following beneficial effects:
[0020] By acquiring the characteristic information of the target request, a total score is calculated based on this information. Then, based on this total score, it is determined whether the target request is an anomalous request. This method of anomalous request identification does not rely on known unauthorized users; even requests not yet identified as being from unauthorized users can be effectively identified and blocked. Furthermore, multiple security strategies are used to determine the total score of the target request. These strategies generate multiple scores for the target request, which are then calculated to obtain the total score. This allows for anomaly detection of the target request from multiple perspectives, making the final determination more accurate. Attached Figure Description
[0021] Figure 1 This is a schematic diagram of the implementation environment of a solution provided in one embodiment of this application;
[0022] Figure 2 This is a flowchart of a method for determining abnormal requests provided in one embodiment of this application;
[0023] Figure 3 This is a flowchart of a method for determining abnormal requests provided in another embodiment of this application;
[0024] Figure 4 This is a flowchart of a method for determining abnormal requests provided in another embodiment of this application;
[0025] Figure 5 This is an architecture diagram of a method for determining abnormal requests provided in one embodiment of this application;
[0026] Figure 6 This is a block diagram of an apparatus for determining abnormal requests provided in one embodiment of this application;
[0027] Figure 7 This is a block diagram of an apparatus for determining abnormal requests provided in another embodiment of this application. Detailed Implementation
[0028] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.
[0029] Please refer to Figure 1 This diagram illustrates an implementation environment provided by one embodiment of the present application. This implementation environment can be implemented as a system for determining abnormal requests. The implementation environment may include: a terminal device 10 and a server 20.
[0030] Terminal device 10 can be an electronic device such as a mobile phone, tablet computer, PC (Personal Computer), wearable device, VR (Virtual Reality) device, and AR (Augmented Reality) device. A client application with the target application can be installed and running on terminal device 10. In this embodiment, the type of target application is not limited; for example, the target application can be a short video application, a social application, a live streaming application, a lifestyle service application, etc.
[0031] Server 20 can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server providing cloud computing services. Server 20 can be the backend server for the aforementioned target application, used to provide backend services to the clients of the target application.
[0032] Terminal device 10 and server 20 can communicate via a network.
[0033] In some embodiments, the client of the terminal device 10 can send a target request to the server 20. After receiving the target request, the server 20 can process the target request. In some embodiments, before processing the target request, the server 20 can first determine whether the target request is an abnormal request using the technical solution provided in the method embodiments of this application. If the target request is not an abnormal request, the server 20 will process the target request. Otherwise, if the target request is an abnormal request, the server 20 can choose not to process the target request, for example, by intercepting the target request or not responding to it.
[0034] Furthermore, the content requested by the target request can vary depending on the application scenario. For example, the target request could be a verification code sending request, a data provision request, an image processing request, a data storage request, etc. This application does not specifically limit the content of the target request.
[0035] Please refer to Figure 2 This document illustrates a flowchart of a method for determining abnormal requests according to an embodiment of this application. The execution entity of this method may be... Figure 1 In the implementation environment of the illustrated scheme, server 20 can be used to execute each step, such as those performed by the server of the target application. The method may include at least one of the following steps (110-140):
[0036] Step 110: Obtain the feature information of the target request. The feature information of the target request is used to indicate the features corresponding to the target request.
[0037] After receiving a target request from a target user, the server obtains the characteristic information of the target request. A target request is a request used to obtain subsequent operations; after agreeing to the target request, the operations required in the target request are executed. The characteristic information refers to the features of the target request. For example, when the target request is a verification code sending request, the characteristic information includes the basic information of the target request and the metadata of the target request. For instance, if the target content of the target request is an SMS message, the basic information of the target request could be the mobile phone number and the type of request information. Based on the mobile phone number, the country and carrier of the mobile phone number can be analyzed. The type of request information can correspond to the scenario in which the user initiated the request, such as registration, login, or balance withdrawal. The metadata of the target request includes the request time, the platform initiating the request (Android, iOS, Web, etc.), the version of the app (Application) initiating the request, the IP (Internet Protocol) address initiating the target request, and the device ID (identifier).
[0038] Step 120: Based on n security policies, determine n scores corresponding to the target request according to the feature information of the target request; wherein, the n security policies and the n scores are in one-to-one correspondence, and the score corresponding to the i-th security policy among the n security policies is used to indicate the probability that the target request determined based on the i-th security policy is an abnormal request, where n is an integer greater than 1 and i is a positive integer less than or equal to n.
[0039] A security policy is a scoring mechanism used to score the characteristic information of a target request. n security policies are n different security policies; by scoring the characteristic information of the target request using these n different security policies, n scores are obtained.
[0040] In some embodiments, the security policy is assumed to score the request information type and the platform initiating the request based on the characteristic information of the target request. For example, the request information type can be divided into three types: registration, login, and balance withdrawal, with corresponding scores of 5, 4, and 3. Similarly, the platform initiating the request can be divided into three platforms: Android, iOS, and Web, with corresponding scores of 6, 5, and 6. Therefore, under this security policy, if the characteristic information of the target request is registration information on the Android platform, its corresponding score is 5+6=11; if the characteristic information of the target request is balance withdrawal on the iOS platform, its corresponding score is 3+5=8. Optionally, the score of the characteristic information of the target request can also be calculated by weighted summation. This application does not limit the calculation method of the score.
[0041] Step 130: Determine the total score of the target request based on the n scores corresponding to the target request.
[0042] In some embodiments, the feature information of the target request is scored according to different security policies, resulting in multiple scores. The total score of the target request is then determined based on these multiple scores. For example, the total score of the target request can be the sum of multiple scores; alternatively, the total score of the target request can be a weighted sum of multiple scores, where the weight value of each score is related to its corresponding security policy. The specific method for calculating the total score of the target request is described below.
[0043] Step 140: If the total score of the target request meets the conditions, then the target request is determined to be an abnormal request.
[0044] In some embodiments, whether a target request is an anomalous request is determined based on whether the total score of the target request meets certain conditions. If the total score of the target request meets the conditions, the target request is determined to be an anomalous request; if the total score of the target request does not meet the conditions, the target request is determined not to be an anomalous request.
[0045] In some embodiments, the above condition is that the total score of the target request is greater than or equal to a threshold. For example, the threshold is set to 30. If the total score of the target request is greater than or equal to 30, the target request is determined not to be an abnormal request; if the total score of the target request is less than 30, the target request is determined to be an abnormal request. For example, if the total score of the target request is 23, then the target request is an abnormal request.
[0046] The technical solution provided in this application obtains the feature information of the target request, calculates the total score of the target request based on the feature information, and then determines whether the target request is an abnormal request based on the total score. This method of identifying abnormal requests does not rely on known illegal users; even requests not yet identified as being sent by illegal users can be effectively identified and blocked. Furthermore, in determining the total score of the target request, multiple security strategies are comprehensively used. Multiple security strategies are used to determine multiple scores corresponding to the target request, and these multiple scores are then calculated to obtain the total score. This allows for anomaly judgment of the target request from multiple different perspectives, making the final judgment result more accurate.
[0047] Please refer to Figure 3 This illustrates a flowchart of a method for determining abnormal requests according to another embodiment of this application. The entity executing this method may be... Figure 1 In the implementation environment of the illustrated scheme, server 20 can be used to execute each step, such as those performed by the server of the target application. The method may include at least one of the following steps (210-250):
[0048] Step 210: Obtain the feature information of the target request. The feature information of the target request is used to indicate the feature corresponding to the target request. The feature information of the target request includes: n feature components of the target request, each feature component is used to indicate a feature corresponding to the target request, and n is an integer greater than 1.
[0049] Based on the constituent parts of the target request's characteristic information, n characteristic components of the target request are determined. For example, the characteristic information of the target request can be divided into mobile phone number, request information type, request time, platform initiating the request, APP version initiating the request, IP address initiating the target request, and device ID. This determines 6 characteristic components of the target request, each corresponding one-to-one with one of the aforementioned 6 different characteristic information components. Assuming there are n characteristic components, a target request can be represented as:
[0050] R = (r 1, r2,…,r n )
[0051] Where R represents the user request, r i Let be the i-th feature component, where n is a positive integer and i is a positive integer less than or equal to n.
[0052] Step 220: For the i-th security policy, obtain at least one feature component related to the i-th security policy from the n feature components of the target request; among the feature components related to the two different security policies, there is at least one different feature component.
[0053] In some embodiments, the feature component corresponding to the i-th security policy can be one feature component, or two or more feature components. Furthermore, the feature components corresponding to different security policies are different. For example, when the feature components related to the i-th security policy are the request information type and the platform initiating the request, the feature components related to other security policies cannot be the same as the feature components of the i-th security policy. Optionally, when the score of the target request's feature information is calculated using a weighted summation method, the feature components corresponding to different security policies can be the same, but their corresponding feature component weights are different. Depending on the different weights, the calculated score will also be different.
[0054] Step 230: Determine the score corresponding to the i-th security policy based on at least one feature component related to the i-th security policy.
[0055] Based on the feature components of the i-th security policy, the corresponding feature components in the target request are calculated to obtain the score corresponding to the i-th security policy. The specific calculation formula is as follows:
[0056] g i =Si (R), i = 1, 2, ..., m
[0057] Among them, S i Let S represent the i-th security policy. i It is a function that takes R as input and outputs a positive number, representing S. i The security policy's corresponding score g i .
[0058] In some embodiments, the method further includes the following steps before step 230: obtaining abnormal request data from historical request records, wherein the abnormal request data includes feature information corresponding to multiple historical abnormal requests; performing statistical analysis on the feature information corresponding to multiple historical abnormal requests to determine the i-th security policy and at least one feature component related to the i-th security policy.
[0059] Historical request records are requests recorded prior to the target request. These records can be a subset of requests recorded before the target request, or all requests recorded before the target request. For example, historical request records may include target requests that were detected as abnormal. Optionally, historical request records may include all target requests. Historical abnormal requests are abnormal requests within the historical request records, and abnormal request data is data extracted from these historical abnormal requests.
[0060] Statistical analysis involves analyzing the characteristic information corresponding to multiple historical abnormal requests to determine the characteristic components in various security policies. The statistical analysis results are obtained by performing statistical analysis on the characteristic information of multiple historical abnormal requests in the historical request records. These results contain the data corresponding to the characteristic information. For example, when the characteristic component corresponding to the i-th security policy is a mobile phone number, the mobile phone number data is obtained from the statistical analysis results to determine the mobile phone number-related characteristic components in the i-th security policy. Similarly, when the characteristic components corresponding to the i-th security policy are a mobile phone number and a request time, the mobile phone number data and request time data are obtained from the statistical analysis results to determine the individual characteristic components related to the mobile phone number and request time in the i-th security policy.
[0061] Because different security strategies focus on different feature components, they can score the same target request using different feature components. This allows the target request to be evaluated from different perspectives, making the target request scoring more accurate and diverse, and thus more precise and comprehensive.
[0062] In addition, by performing statistical analysis on abnormal request data in historical request records, the characteristic components in the security policy are determined, making the determined characteristic components in the security policy more consistent with historical records, and making the scoring of target requests by the security policy more accurate and consistent with historical records.
[0063] Step 240: Based on the weight values corresponding to the m security policies, perform a weighted calculation on the m scores to obtain the total score of the target request.
[0064] In some embodiments, the total score of the target request is calculated using a weighted summation method. For example, suppose the security policy scores the request information type and the platform initiating the request based on the characteristic information of the target request. The request information type can be divided into three types: registration, login, and balance withdrawal, with corresponding scores of 5, 4, and 3. The platform initiating the request can be divided into three types: Android, iOS, and Web, with corresponding scores of 6, 5, and 6. The weight for the request information type is 2, and the weight for the platform initiating the request is 3. Therefore, under this security policy, if the target content of the target request is registration information on the Android platform, its corresponding score is 5*2 + 6*3 = 28. If the target content of the target request is balance withdrawal information on the iOS platform, its corresponding score is 3*2 + 5*3 = 21.
[0065] In some embodiments, the total score is calculated as follows:
[0066]
[0067] Where M is the filtering model, which can also be understood as the scoring calculation model. This model can include various security policies to calculate the total score corresponding to the target request, w i This represents the weight value corresponding to the i-th security policy, where m is a positive integer and i is a positive integer less than or equal to m. This is the calculated score and weight value corresponding to the i-th security policy. G is the total score of the target request.
[0068] In some embodiments, the method provided in this application further includes the following steps: obtaining an interception evaluation index of a processed request that matches the i-th security policy, wherein the interception evaluation index is used to indicate the interception effect of the abnormal request; and updating the weight value corresponding to the i-th security policy according to the interception evaluation index corresponding to the i-th security policy.
[0069] Interception evaluation metrics are used to indicate the effectiveness of a server in intercepting abnormal requests. The relationship between interception evaluation metrics and interception effectiveness is determined by their definition. Optionally, a higher interception evaluation metric indicates better interception effectiveness; for example, an interception evaluation metric might indicate the success rate of intercepting abnormal requests. Optionally, a lower interception evaluation metric might also indicate better interception effectiveness; for example, an interception evaluation metric might indicate the probability of an abnormal request not being intercepted.
[0070] The weight value corresponding to the i-th security policy can be calculated not only through statistical analysis of the feature information corresponding to multiple historical abnormal requests, but also by updating the weight value corresponding to the i-th security policy based on the determination of abnormal requests. For example, when a target request containing the feature components corresponding to the i-th security policy is determined to be an abnormal request, the weight value corresponding to the i-th security policy can be increased or decreased.
[0071] In some embodiments, updating the weight value corresponding to the i-th security policy based on the interception evaluation index corresponding to the i-th security policy includes the following steps: obtaining the change gradient of the interception evaluation index corresponding to the i-th security policy in multiple time intervals; adjusting the weight value corresponding to the i-th security policy upward or downward according to the change gradient.
[0072] For example, when the target content of the target request is a CAPTCHA, the interception evaluation index is determined based on the verification rate of the CAPTCHA information corresponding to the target requests with the same feature components across multiple time intervals. Since the verification rate of normal CAPTCHA information is very high, while the verification rate of abnormal CAPTCHA information is relatively low, the verification rate of CAPTCHA information can be used to determine whether the user sending the information is an abnormal user. At the same time, target requests sent by abnormal users are usually considered abnormal requests by default.
[0073] At this point, if the verification rate of the CAPTCHA information corresponding to the target request with the same feature component is lower, then its corresponding interception evaluation index should be higher. If the verification rate of the CAPTCHA information increases in the next time period, the gradient of change is positive, and its interception evaluation index decreases. Therefore, the weights can be updated by detecting changes in the verification rate in different time intervals. Suppose that the SMS verification rate is 60% in the time window of 12:00-12:05, and drops to 30% in the next time window of 12:05-12:10, then the gradient of change is -30%. The model will increase the weight w0 of the corresponding strategy S0 by Δw, making this strategy more important in the entire filtering model and easier to filter SMS requests that match the APP version 1303 and SMS type LOGIN. Conversely, if the verification rate of this strategy dimension increases, the gradient of change is positive, then w0 is subtracted by Δw, making the SMS interception probability of this dimension decrease. Assume the current time window is t.i The previous time window was t. i-1 CR(t) represents the validation rate within the time window t. This process is formally represented as follows:
[0074]
[0075] Alternatively, the weights can be updated by monitoring the relationships between multiple different versions of the app, calculated as follows:
[0076]
[0077] Here, CURVER represents the latest version of the currently released app, diff(r1, CURVER) represents the difference between the requesting version r1 and the latest version, and CheckIfHackedType(r2) indicates whether the requested SMS type r2 is included in the SMS types frequently used to initiate abnormal requests; if included, it returns 1. The above formula assigns weights of 0.7 and 0.3 to the processing results of the two components respectively, considering that in actual business scenarios, most normal users will always use a newer version of the app. If the version used is too old, there is a greater probability that the user is not a normal user, therefore, the weight is higher than that of the SMS type. Using a similar approach, we can combine historical request records and business characteristics to construct more different security strategies.
[0078] By updating the weight values of the security policy according to the gradient changes of the interception evaluation index in different time intervals, the model can be continuously updated as it is used to deal with the detection of abnormal requests after the feature information is updated, so that the server can better intercept abnormal requests.
[0079] Step 250: If the total score of the target request meets the conditions, then the target request is determined to be an abnormal request.
[0080] Step 250 has been described in the above embodiments and will not be repeated here.
[0081] This embodiment employs multiple security strategies that focus on different feature components. Because different security strategies focus on different feature components, they can score the same target request based on different feature components. This allows the target request to be evaluated from different perspectives, making the target request scoring more accurate and diverse, and ultimately more precise and comprehensive.
[0082] In addition, by performing statistical analysis on abnormal request data in historical request records, the characteristic components in the security policy are determined, making the determined characteristic components in the security policy more consistent with historical records, and making the scoring of target requests by the security policy more accurate and consistent with historical records.
[0083] In addition, by updating the weight values of the security policy according to the gradient changes of the interception evaluation index in different time intervals, the model can be continuously updated as it is used to deal with the detection of abnormal requests after the feature information is updated, so that the server can better intercept abnormal requests.
[0084] The following section uses an SMS sending request as an example to illustrate the technical solution of this application.
[0085] like Figure 4 As shown, a flowchart of a method for determining abnormal requests provided in another embodiment of this application is illustrated. The execution entity of this method may be... Figure 1 The server 20 in the implementation environment of the illustrated scheme can be executed by the server of the target application, such as the steps. The method may include at least one of the following steps (310-350).
[0086] Step 310: Obtain the feature information of the SMS sending request. The feature information of the SMS sending request is used to indicate the features corresponding to the SMS sending request.
[0087] In some embodiments, such as Figure 5 As shown, Figure 5 An example diagram illustrates the architecture of a method for determining abnormal requests. Figure 5 In the process, the SMS service platform entry point (server) obtains the user request R (SMS sending request) and obtains the characteristic information of the user request R.
[0088] Step 320: For the i-th security strategy, obtain at least one feature component related to the i-th security strategy from the n feature components of the SMS sending request.
[0089] The feature information of an SMS sending request contains n feature components, and each security policy contains at least one of the n feature components. When scoring an SMS sending request using the i-th security policy, the corresponding feature component is first obtained from the feature information of the SMS sending request based on the feature components of the i-th security policy.
[0090] Step 330: Determine the score corresponding to the i-th security policy based on at least one feature component related to the i-th security policy.
[0091] Based on the feature components corresponding to the feature information of the obtained SMS sending request, the score of the i-th security policy for the SMS sending request is calculated.
[0092] Step 340: Based on the weight values corresponding to the m security policies, perform a weighted calculation on the m scores to obtain the total score of the SMS sending request.
[0093] The server scores the feature information using m security policies, obtaining m scores. Then, based on the weight values corresponding to each of the m security policies, it calculates the total score of the SMS sending request through a weighted summation. Optionally, these weight values can be updated as the method for determining abnormal SMS messages is executed; this update process has been described in the embodiments above.
[0094] In some embodiments, such as Figure 5 As shown, the server scores the feature information of user request R through a filtering model, and applies various security policies in the security policy module. Figure 5 Five security policies (S1, S2, S3, S4, and S5) are used to score the characteristic information of user requests, and the total score is calculated by weighted summation. The weights of each security policy are obtained through the security decision weight optimization module (interception evaluation index), and the data for this module is obtained from the server cache.
[0095] Step 350: If the total score of the SMS sending request meets the conditions, then the SMS sending request is determined to be an abnormal request.
[0096] Whether an SMS retrieval request is an anomalous request is determined based on whether the total score of the request meets certain conditions. In some embodiments, such as... Figure 5 As shown, the interception decision module determines whether the user request R corresponding to the total score is an abnormal request by judging whether the total score exceeds the business interception threshold.
[0097] The calculation methods for the security policy scores, the calculation methods for the total scores, the calculation methods for the weight values, and the update methods for the weight values in this embodiment have been described in the above embodiments and will not be repeated here.
[0098] This embodiment takes SMS sending requests as an example. By obtaining the feature information of SMS sending requests, multiple scores corresponding to the SMS sending requests are determined through various security strategies. The multiple scores are then weighted and summed to obtain a total score. The total score is then used to determine whether the SMS sending request is an abnormal request. By filtering out some abnormal SMS sending requests through the server, the harassment of users by abnormal SMS messages is reduced, and the cost of SMS sending is also reduced.
[0099] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.
[0100] Please refer to Figure 6 This diagram illustrates a block diagram of an apparatus for determining abnormal requests according to an embodiment of this application. The apparatus has the function of implementing the aforementioned method for determining abnormal requests; this function can be implemented in hardware or by hardware executing corresponding software. The apparatus can be a computer device or can be installed within a computer device. The apparatus 600 may include: an information acquisition module 610, a scoring determination module 620, a total score determination module 630, and a request judgment module 640.
[0101] The information acquisition module 610 is used to acquire feature information of the target request, wherein the feature information of the target request is used to indicate the features corresponding to the target request.
[0102] The scoring determination module 620 is used to determine m scores corresponding to the target request based on m security policies and the feature information of the target request; wherein, the m security policies and the m scores are in one-to-one correspondence, and the score corresponding to the i-th security policy among the m security policies is used to indicate the probability that the target request determined based on the i-th security policy is an abnormal request, where m is an integer greater than 1 and i is a positive integer less than or equal to m.
[0103] The total score determination module 630 is used to determine the total score of the target request based on the m scores corresponding to the target request.
[0104] The request judgment module 640 is used to determine that the target request is the abnormal request if the total score of the target request meets the conditions.
[0105] In some embodiments, such as Figure 7 As shown, the feature information of the target request includes: n feature components of the target request, each feature component is used to indicate a feature corresponding to the target request, where n is an integer greater than 1; the scoring determination module 620 further includes: a component acquisition unit 621 and a scoring acquisition unit 622.
[0106] The component acquisition unit 621 is used to acquire at least one feature component related to the i-th security policy from the n feature components of the target request for the i-th security policy.
[0107] The scoring acquisition unit 622 is used to determine the score corresponding to the i-th security policy based on at least one feature component related to the i-th security policy.
[0108] In some embodiments, among the feature components associated with two different security policies, there is at least one different feature component.
[0109] In some embodiments, the component acquisition unit 621 is further configured to acquire abnormal request data from historical request records, the abnormal request data including feature information corresponding to multiple historical abnormal requests respectively; perform statistical analysis on the feature information corresponding to the multiple historical abnormal requests respectively, and determine the i-th security policy and at least one feature component related to the i-th security policy.
[0110] In some embodiments, the total score determination module 630 is further configured to perform a weighted calculation on the m scores according to the weight values corresponding to the m security policies respectively, so as to obtain the total score of the target request.
[0111] In some embodiments, the total score determination module 630 is further configured to obtain an interception evaluation index for processed requests that match the i-th security policy, the interception evaluation index being used to indicate the interception effect of abnormal requests; and to update the weight value corresponding to the i-th security policy according to the interception evaluation index corresponding to the i-th security policy.
[0112] In some embodiments, the total score determination module 630 is further configured to obtain the change gradient of the interception evaluation index corresponding to the i-th security strategy in multiple time intervals; and adjust the weight value corresponding to the i-th security strategy upward or downward according to the change gradient.
[0113] This embodiment acquires the feature information of the target request, calculates the total score of the target request based on the feature information, and then determines whether the target request is an abnormal request based on the total score. This method of identifying abnormal requests does not rely on known unauthorized users; even requests not yet identified as being sent by unauthorized users can be effectively identified and blocked. Furthermore, in determining the total score of the target request, multiple security strategies are used comprehensively. Multiple security strategies are used to determine multiple scores corresponding to the target request, and these multiple scores are then calculated to obtain the total score. This allows for anomaly judgment of the target request from multiple different perspectives, making the final judgment result more accurate.
[0114] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the content structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.
[0115] In an exemplary embodiment, a computer device is also provided, the computer device including a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the above-described method for determining abnormal requests.
[0116] In an exemplary embodiment, a computer-readable storage medium is also provided, wherein a computer program is stored in the storage medium, the computer program being loaded and executed by a processor to implement the method for determining the aforementioned abnormal request. Optionally, the aforementioned computer-readable storage medium may be ROM (Read-Only Memory), RAM (Random Access Memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, and optical data storage device, etc.
[0117] In an exemplary embodiment, a computer program product is also provided, the computer program product including computer instructions stored in a computer-readable storage medium, wherein a processor reads from the computer-readable storage medium and executes the computer instructions to implement the above-described method for determining abnormal requests.
[0118] It should be understood that "multiple" as used herein refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, the step numbers described herein are merely illustrative of one possible execution order. In some other embodiments, the steps may not be executed in numerical order, such as two steps with different numbers being executed simultaneously, or two steps with different numbers being executed in the reverse order of the illustration. This application does not limit this.
Claims
1. A method of determining an abnormal request, characterized by, The method includes: Obtain the feature information of the SMS sending request, which is used to indicate the characteristics corresponding to the SMS sending request; the feature information of the SMS sending request includes mobile phone number, request information type, request time, platform initiating the request, APP version of the application initiating the request, Internet Protocol address (IP address) and device identifier (ID) initiating the SMS sending request; Based on m security strategies, m scores corresponding to the SMS sending request are determined according to the feature information of the SMS sending request; wherein, the m security strategies and the m scores are in one-to-one correspondence, and the score corresponding to the i-th security strategy among the m security strategies is used to indicate the probability that the SMS sending request determined based on the i-th security strategy is an abnormal request, where m is an integer greater than 1 and i is a positive integer less than or equal to m. The total score of the SMS sending request is determined based on the m scores corresponding to the SMS sending request. If the total score of the SMS sending request meets the conditions, then the SMS sending request is determined to be an abnormal request; The feature information of the SMS sending request includes: n feature components of the SMS sending request, each feature component is used to indicate a feature corresponding to the SMS sending request, where n is an integer greater than 1; Based on m security policies, and according to the feature information of the SMS sending request, m scores are determined corresponding to the SMS sending request, including: Obtain abnormal request data from historical request records. The abnormal request data includes feature information corresponding to multiple historical abnormal requests. Perform statistical analysis on the feature information corresponding to the multiple historical abnormal requests to determine the i-th security policy and at least one feature component related to the i-th security policy. For the i-th security strategy, at least one feature component related to the i-th security strategy is obtained from the n feature components of the SMS sending request; The score corresponding to the i-th security policy is determined based on at least one feature component related to the i-th security policy. Among the feature components associated with the two different security policies, there is at least one different feature component.
2. The method according to claim 1, characterized in that, The step of determining the total score of the SMS sending request based on the m scores corresponding to the SMS sending request includes: Based on the weight values corresponding to the m security strategies, the m scores are weighted and calculated to obtain the total score of the SMS sending request.
3. The method according to claim 2, characterized in that, The method further includes: Obtain the interception evaluation index of the processed requests that match the i-th security policy, the interception evaluation index being used to indicate the interception effect of abnormal requests; The weight value corresponding to the i-th security strategy is updated based on the interception evaluation index corresponding to the i-th security strategy.
4. The method of claim 3, wherein, The step of updating the weight value corresponding to the i-th security strategy based on the interception evaluation index corresponding to the i-th security strategy includes: Obtain the interception evaluation index corresponding to the i-th security strategy and its gradient change over multiple time intervals; Based on the change gradient, the weight value corresponding to the i-th security strategy is adjusted up or down.
5. A device for determining abnormal requests, characterized in that, The device includes: The information acquisition module is used to acquire the feature information of the SMS sending request. The feature information of the SMS sending request is used to indicate the characteristics corresponding to the SMS sending request. The feature information of the SMS sending request includes mobile phone number, request information type, request time, platform that initiated the request, APP version that initiated the request, Internet Protocol address (IP address) and device identifier (ID) that initiated the SMS sending request. The scoring determination module is used to determine m scores corresponding to the SMS sending request based on m security policies and the feature information of the SMS sending request; wherein, the m security policies and the m scores are in one-to-one correspondence, and the score corresponding to the i-th security policy among the m security policies is used to indicate the probability that the SMS sending request determined based on the i-th security policy is an abnormal request, where m is an integer greater than 1 and i is a positive integer less than or equal to m; The total score determination module is used to determine the total score of the SMS sending request based on the m scores corresponding to the SMS sending request. The request judgment module is used to determine that the SMS sending request is the abnormal request if the total score of the SMS sending request meets the conditions. The feature information of the SMS sending request includes: n feature components of the SMS sending request, each feature component is used to indicate a feature corresponding to the SMS sending request, where n is an integer greater than 1; The scoring determination module includes: a component acquisition unit and a scoring acquisition unit; The component acquisition unit is used to acquire abnormal request data from historical request records, the abnormal request data including feature information corresponding to multiple historical abnormal requests; and to perform statistical analysis on the feature information corresponding to the multiple historical abnormal requests to determine the i-th security policy and at least one feature component related to the i-th security policy. The component acquisition unit is further configured to, for the i-th security policy, acquire at least one feature component related to the i-th security policy from the n feature components of the SMS sending request; The scoring acquisition unit is further configured to determine the score corresponding to the i-th security policy based on at least one feature component related to the i-th security policy. Among the feature components associated with the two different security policies, there is at least one different feature component.
6. A computer device, comprising: The computer device includes a processor and a memory, the memory storing a computer program that is loaded and executed by the processor to implement the method as described in any one of claims 1 to 4.
7. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which is loaded and executed by a processor to implement the method as described in any one of claims 1 to 4.
8. A computer program product, characterised in that, The computer program product includes computer instructions stored in a computer-readable storage medium, which a processor reads from and executes to implement the method as described in any one of claims 1 to 4.