A risk user detection method and device, computer equipment and a storage medium

Abstract

The embodiment of the application belongs to the field of artificial intelligence and big data, is applied to the field of smart city, and relates to a risk user detection method, which comprises the following steps: acquiring a target node path of a to-be-detected user, the to-be-detected user being a user logged in outside a target application, and the target node path being a node path of the to-be-detected user outside the target application; performing feature extraction processing on the target node path to obtain a target node path feature; performing risk detection on the target node path feature through a preset risk control engine to obtain a risk detection result; and determining whether the to-be-detected user is a risk user based on the risk detection result. The application further provides a risk user detection device, a computer device and a storage medium. The application solves the problem that the identification time period of abnormal activity paths of users is long, resource consumption is large, and risk users cannot be blocked in real time.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence and big data technology, and in particular to a method, apparatus, computer equipment and storage medium for detecting risky users. Background Technology

[0002] User path behavior analysis currently relies heavily on event tracking data. Event tracking requires significant manpower and resources, and with a large user base and numerous event tracking records, the computational workload for generating user paths is substantial, resulting in a large number and complexity of user paths.

[0003] By analyzing user activity paths, it is possible to effectively identify black and gray market users. Offline models cover more comprehensive user path data and have better identification effects for users who mass-farm accounts. However, they cannot solve the problem of users who quickly receive and redeem coupons in batches and cannot block them in real time. LSTM models are often used to represent user context path information, but they cannot learn time features and cannot provide explanations for false positives.

[0004] Currently, internet apps are widely used, but a large number of users are still active only outside of apps. As a result, the current risk protection capabilities outside of apps (on the web side) have significant deficiencies, such as limited fields obtained by SDKs, weak environment detection capabilities, and the risk of web-side fields being tampered with.

[0005] Therefore, there is an urgent need for a risk user detection method to solve the problem that the existing methods for identifying abnormal user activity paths are time-consuming and resource-intensive, resulting in the inability to block risk users in real time. Summary of the Invention

[0006] The purpose of this application is to propose a risk user detection method, device, computer equipment, and storage medium to solve the problem that the identification of abnormal user activity paths is time-consuming and resource-intensive, resulting in the inability to block risk users in real time. Its main purpose is to enable immediate blocking of risks, provide strong interpretability, reduce user complaint rates, and improve work efficiency.

[0007] To address the aforementioned technical problems, this application provides a risky user detection method, which employs the following technical solution:

[0008] Obtain the target node path of the user to be detected, wherein the user to be detected is a user who logs in outside the target application, and the target node path is the node path of the user to be detected outside the target application;

[0009] The target node path is subjected to feature extraction processing to obtain the target node path features;

[0010] The target node path features are used to perform risk detection through a preset risk control engine to obtain risk detection results;

[0011] Based on the risk detection results, it is determined whether the user to be detected is a risk user.

[0012] Furthermore, the step of obtaining the target node path of the user to be detected includes:

[0013] Retrieve the node path of the user record;

[0014] Extract the node path of the recorded user to obtain node path data;

[0015] Based on the node path data, the user to be detected is determined, and the target node path of the user to be detected is obtained.

[0016] Furthermore, the step of obtaining the node path of the recorded user includes:

[0017] Create a user list, which includes users who log in from outside the target application;

[0018] Record user path information within a preset time period;

[0019] Based on the user list and the user path records within the preset time period, obtain the node path of the recorded user.

[0020] Furthermore, the step of determining the user to be detected based on the node path data and obtaining the target node path of the user to be detected includes:

[0021] The node path data is processed using a preset algorithm to obtain frequent itemsets of the node paths;

[0022] Based on the frequent itemsets of the node paths, the user to be detected is determined, and the target node path of the user to be detected is obtained.

[0023] Furthermore, the step of performing feature extraction processing on the target node path to obtain the target node path features includes:

[0024] Determine the user request field data to be detected in the node path;

[0025] The target node path features are obtained by performing feature extraction processing on the user request field data to be detected using preset empirical rules.

[0026] Furthermore, after the step of determining whether the user to be detected is a risk user based on the risk detection result, the method further includes:

[0027] If the user to be detected is a risky user, then the user will be blocked and added to the blacklist.

[0028] Furthermore, after the step of intercepting and escalating the user to the blacklist if the user to be detected is a risky user, the method further includes:

[0029] If a user on the blacklist submits a login request, which includes the username and password parameters passed by the user, then the user can log in using strong authentication.

[0030] If the login is successful, the blacklisted user will be cleared.

[0031] To address the aforementioned technical problems, this application also provides a risk user detection device, which employs the following technical solution:

[0032] The first acquisition module is used to acquire the target node path of the user to be detected, wherein the user to be detected is a user who logs in outside the target application, and the target node path is the node path of the user to be detected outside the target application;

[0033] The processing module is used to perform feature extraction processing on the target node path to obtain the target node path features;

[0034] The risk detection module is used to perform risk detection on the target node path features through a preset risk control engine to obtain risk detection results;

[0035] The determination module is used to determine whether the user to be detected is a risk user based on the risk detection results.

[0036] To address the aforementioned technical problems, this application also provides a computer device that employs the following technical solution:

[0037] The computer device includes a memory and a processor. The memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the risk user detection method described in any one of the embodiments of this application.

[0038] To address the aforementioned technical problems, this application also provides a computer-readable storage medium, employing the technical solution described below:

[0039] The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the risk user detection method described in any one of the embodiments of the present invention.

[0040] Compared with the prior art, the embodiments of this application have the following advantages: by obtaining the target node path of the user to be detected, the user to be detected is a user logged in outside the target application, the target node path is the node path of the user to be detected outside the target application, and the target node path is subjected to feature extraction processing to obtain the target node path features, and the target node path features are subjected to risk detection through a preset risk control engine to obtain the risk detection result, and the risk detection result is used to determine whether the user to be detected is a risky user, thus solving the problem that the identification of abnormal user activity paths is time-consuming and resource-intensive, resulting in the inability to block risky users in real time. Attached Figure Description

[0041] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 This is an exemplary system architecture diagram to which this application can be applied;

[0043] Figure 2 A flowchart of an embodiment of the risk user detection method according to this application;

[0044] Figure 3 yes Figure 2 A flowchart of a specific implementation of step S201;

[0045] Figure 4 yes Figure 3 A flowchart of a specific embodiment of step S2011;

[0046] Figure 5 yes Figure 3 A flowchart of a specific embodiment of step S2013;

[0047] Figure 6 yes Figure 2 A flowchart of a specific embodiment of step S202;

[0048] Figure 7 yes Figure 2 A flowchart of a specific embodiment following step S203;

[0049] Figure 8 yes Figure 7 A flowchart of a specific embodiment following step S701;

[0050] Figure 9This is a schematic diagram of the structure of one embodiment of the risk user detection device according to this application;

[0051] Figure 10 yes Figure 9 A schematic diagram of the structure of the first acquisition module 901 in a specific embodiment;

[0052] Figure 11 yes Figure 10 A schematic diagram of the structure of the first acquisition submodule 9011 in a specific embodiment;

[0053] Figure 12 yes Figure 10 A schematic diagram of a specific embodiment of the second data cleaning module 9013;

[0054] Figure 13 yes Figure 9 A schematic diagram of the structure of the first processing module 902 in a specific embodiment;

[0055] Figure 14 yes Figure 9 A schematic diagram of another specific embodiment of the medium-risk user detection device 900;

[0056] Figure 15 yes Figure 9 A schematic diagram of another specific embodiment of the medium-risk user detection device 900;

[0057] Figure 16 This is a schematic diagram of the structure of one embodiment of the computer device according to this application. Detailed Implementation

[0058] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.

[0059] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0060] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0061] like Figure 1 As shown, system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0062] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0063] Terminal devices 101, 102, and 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III), MP4 players (Moving Picture Experts Group Audio Layer IV), laptops, and desktop computers, etc.

[0064] Server 105 can be a server that provides various services, such as a backend server that supports the pages displayed on terminal devices 101, 102, and 103.

[0065] It should be noted that the risk user detection method provided in this application embodiment is generally executed by a server / terminal device, and correspondingly, the risk user detection device is generally set in the server / terminal device.

[0066] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0067] Continue to refer to Figure 2 A flowchart of an embodiment of the risk user detection method according to this application is shown. The risk user detection method includes the following steps:

[0068] Step S201: Obtain the target node path of the user to be detected.

[0069] In this embodiment, the risk user detection method operates on electronic devices (e.g., Figure 1 The server / terminal device shown can receive risk user detection requests from terminal devices via wired or wireless connections. It should be noted that the aforementioned wireless connection methods may include, but are not limited to, 3G / 4G / 5G connections, WiFi connections, Bluetooth connections, WiMAX connections, Zigbee connections, UWB (ultra-wideband) connections, and other currently known or future-developed wireless connection methods.

[0070] The aforementioned terminal devices can be various terminal devices equipped with remote interactive functions such as personal assistants and intelligent customer service.

[0071] The aforementioned risk user detection methods can be applied to online risk user query and online risk user management.

[0072] Specifically, the aforementioned electronic devices can be used for risk detection in different industries, such as medical, insurance, financial, and retail.

[0073] The users to be tested are those logged in outside the target application, and the target node path is the node path of the users to be tested outside the target application.

[0074] The users to be detected can be users marked on the gray list, users who are active outside the target application, and users who log in on the web side using their username and password.

[0075] The aforementioned node paths can be key node paths, such as the paths of users at key nodes such as registration, login, activities, receiving coupons, viewing coupon details, and redeeming orders.

[0076] After obtaining the user to be detected, the electronic device first determines the target node path of the user to be detected.

[0077] Step S202: Perform feature extraction processing on the target node path to obtain the target node path features.

[0078] In this embodiment, the above-mentioned feature extraction process can be to extract representative and distinguishable features, or it can be anomaly feature extraction process.

[0079] The above-mentioned node path features can be node path anomaly features.

[0080] Specifically, rules of thumb can be used to extract features from the target node path to obtain the user's node path features.

[0081] Furthermore, the aforementioned rule of thumb can be the 3-sigma rule, which is used to quickly extrapolate normal distribution data with known mean and standard deviation.

[0082] It should be noted that feature extraction processing is performed on the target node path to obtain the abnormal features of the target node path.

[0083] Step S203: The path features of the target node are used for risk detection through a preset risk control engine to obtain the risk detection results.

[0084] In this embodiment, the aforementioned preset risk control engine can be a real-time risk control engine. A risk control engine is a software system based on technologies such as machine learning and artificial intelligence, which can automatically monitor and control risks, thereby improving the risk management capabilities and efficiency of enterprises.

[0085] The aforementioned target node path features can be abnormal features of the target node path.

[0086] The aforementioned preset risk control engine targets each URI in frequent paths. If any of the following exceeds the threshold within 24 hours: number of provinces with IP addresses, number of cities with IP addresses, number of IP addresses, number of user agents, number of requests from the same IP address, or number of users requesting from the same IP address, then the user's request will be blocked.

[0087] The URI mentioned above can be understood as a user's identity identifier. The IP (Internet Protocol) mentioned above is a network layer protocol in the TCP / IP architecture, used to identify the logical address of a computer on the Internet.

[0088] The aforementioned risk detection is a process of assessing and analyzing a target to identify potential risks and threats.

[0089] The risk detection results include information such as whether the user under test poses a security risk, as well as the severity and likelihood of such risks.

[0090] It should be noted that, based on the target node path characteristics, the target node path characteristics are monitored for risk through a preset risk engine to obtain risk detection results.

[0091] Step S204: Based on the risk detection results, determine whether the user to be detected is a risk user.

[0092] In this embodiment, after obtaining the risk detection result, the electronic device can determine whether the user to be detected is a risky user based on the risk detection result.

[0093] The risk detection results include information such as whether the user under test poses a security risk, as well as the severity and likelihood of such risks.

[0094] The aforementioned high-risk users refer to users who may pose a risk, including but not limited to hackers, virus creators, and some ordinary users.

[0095] In one embodiment, if the user to be detected is a risky user, the user is blocked in real time and upgraded to a blacklist for application to the overall risk control blocking.

[0096] In another embodiment, the activities associated with frequent paths of users outside the target application and blacklisted users are reported to the rights and benefits platform daily for dynamic adjustment of the target group and rights and benefits items. At the same time, the historical rights and benefits of blacklisted users are revoked.

[0097] In another embodiment, blacklisted users need to log in to the target application through a strong verification method set by the login scenario. Strong verification methods include facial recognition, voice recognition, and other strong verification methods. If the verification is successful, the blacklisted user is cleared, removed from the blacklist, and their normal usage permissions are restored.

[0098] This application obtains the target node path of the user to be detected, where the user is a user logged in outside the target application, and the target node path is the node path of the user outside the target application. It then performs feature extraction processing on the target node path to obtain target node path features, and uses the target node path features to perform risk detection through a preset risk control engine to obtain risk detection results. Using the risk detection results, it determines whether the user to be detected is a risky user. This solves the problem that the identification of abnormal user activity paths takes a long time and consumes a lot of resources, resulting in the inability to block risky users in real time.

[0099] Continue to refer to Figure 3 It shows that in Figure 2 A flowchart illustrating a specific implementation of step S201. Step S201 specifically includes the following steps:

[0100] S2011, Get the node path of the user record.

[0101] In this embodiment, the user recorded above can be a user who logs in from outside the target application.

[0102] The above-mentioned node path refers to the key node path, which can be the path of key nodes such as registration, login, activities, receiving coupons, viewing coupon details, and redemption and order placement.

[0103] S2012, extract the node path of the recorded user to obtain node path data.

[0104] In this embodiment, the path extraction described above may be the extraction of path information from the starting node to the ending node.

[0105] The above node path data includes all the nodes the user traverses.

[0106] S2013: Based on node path data, determine the user to be detected and obtain the target node path of the user to be detected.

[0107] In this embodiment, after obtaining node path data, the electronic device can determine the user to be detected and obtain the target node path of the user to be detected through the node path data.

[0108] The users to be tested are those logged in outside the target application, and the target node path is the node path of the users to be tested outside the target application.

[0109] This application obtains the node paths of recorded users, extracts the node paths of recorded users to obtain node path data, and determines the users to be detected based on the node path data, thereby obtaining the target node paths of the users to be detected. This can narrow the scope of the monitored user group and shorten the range of user behavior path points, thereby reducing computing time and resources.

[0110] Continue to refer to Figure 4 , showed Figure 3 A flowchart illustrating a specific embodiment of step S2011. Step S2011 specifically includes the following steps:

[0111] Step S20111: Create a user list.

[0112] In this embodiment, the user list includes users logged in outside the target application. These users can be active users outside the app.

[0113] Specifically, the entry criteria refer to accounts that initiate login requests on the web and log in using username and password; the exit criteria refer to accounts that initiate login requests within the app (Android / iOS client) and log in successfully.

[0114] Step S20112: Record the user path records within a preset time period.

[0115] In this embodiment, the preset time can be 15 days, 30 days, or other similar periods.

[0116] The aforementioned user path records refer to user critical path records. These path records include user request field data in the registration, login, activity, coupon redemption, coupon viewing details, and order redemption stages, such as: request URI, referrer, user_agent, account user's province, IP, IP's province, IP's city, and request time.

[0117] Specifically, the records for the past 15 days document user request data during the registration, login, activity, coupon redemption, coupon details viewing, and order redemption processes, including: request URI, referrer, user_agent, user's province, IP address, IP address's province, IP address's city, and request time. The records for the past 30 days also document user request data during the same process.

[0118] Step S20113: Based on the user list and user path records within a preset time period, obtain the node path of the recorded user.

[0119] In this embodiment, the electronic device obtains the user list and user path records within a preset time period, and can obtain the node path of the recorded user through the user list and user path records within a preset time period.

[0120] The above node paths can be key node paths, such as registration, login, activities, and coupon redemption.

[0121] Specifically, a path record is created by starting with the user's login URI and ending with the URI before the user's next login.

[0122] The record format is [uri1,uri2,uri3,…,urin], where uri is recorded sequentially.

[0123] The record format for all user paths is: use1:{[uri111,uri112,uri113,…,uri11n],[uri121,uri122,uri123,…,uri12n],…[uri1m1,uri1m2,uri1m3,…,uri1mn]}

[0124] usek{[urik11,urik12,urik13,…,urik1n],[urik21,urik22,urik23,…,urik2n],…[urikm1,urikm2,urikm3,…,urikmn]}.

[0125] This application improves the accuracy of risk application by establishing a user list, recording user path records within a preset time period, and obtaining the node paths of recorded users based on the user list and user path records within the preset time period.

[0126] Continue to refer to Figure 5 , showed Figure 3A flowchart illustrating a specific embodiment of step S2013. Step S2013 specifically includes the following steps:

[0127] S20131. Process the node path data using a preset algorithm to obtain frequent itemsets of the node paths.

[0128] In this embodiment, after obtaining node path data, the electronic device can process the node path data using a preset algorithm to obtain frequent itemsets of the node path.

[0129] The aforementioned preset algorithm can be the FP-growth algorithm, which is an association analysis algorithm that can compress a database that provides frequent itemsets into a frequent pattern tree (FP-tree) while still retaining the itemset association information.

[0130] Specifically, the FP-TREE generated by the FP-growth algorithm above mines items that appear together, that is, it mines the correlation between events, but it cannot retain the chronological order of events. It only sorts events by the size of the support, and the results of frequent items differ from the actual time sequence of events.

[0131] Furthermore, improvements were made to the FP-growth algorithm, including:

[0132] a. Create an item header table. Iterate through all users' URI path records, sequentially splitting each frequent pair of items into two-item frequent sets and obtaining the count (support) of each frequent pair of items. For example, [uri111,uri112,uri113,…,uri11n] is split into [uri111,uri112], [uri112,uri113],…,[uri11n-1,uri11n]. The item header table records all frequent pairs of items in the path and their frequency, sorted in descending order of frequency, and removing items with a frequency less than 2.

[0133] The aforementioned URIs can be understood as user identifiers, and the aforementioned URI paths represent users who belong to a subset of frequent paths.

[0134] b. For each data point that has been split into frequent 2-items, remove the non-frequent 2-items and sort them in descending order of the support of the 2-items.

[0135] c. Construct an FP-tree with null as the root node. Insert the first data item processed in step b, setting the count of all nodes to 1. For example, null->[uri111,uri112]:1->[uri112,uri113]:1. Nodes are inserted sequentially in order, with the previous 2-itemset becoming the parent node of the next 2-itemset. Subsequent data is then inserted in sequence. If a common ancestor exists, only the new node needs to be added. The count of each node changes with the insertion of new data; if a duplicate node is inserted, its count is incremented by 1. This process continues until all path data has been inserted.

[0136] d. Mining frequent itemsets: Based on the leaf nodes of the FP-TREE, obtain the FP subtree, set the count of the leaf node to the count of each node in the subtree, and delete nodes with a count lower than 2. Obtain the frequent N-itemsets of each leaf node, and retain the frequent 1-itemsets of the leaf nodes. For example, mining frequent 2-itemsets like {[uri111,uri112]:106,[uri112,uri113]:92}.

[0137] e. Frequent N-itemset processing selection: Traverse frequent itemsets. If the header URI of the first item in the set is not a login or registration URI, remove the frequent itemset. Merge elements of frequent N-itemsets: If every two adjacent elements in the set can be directly merged, such as {[A,B]:2,[B,D]:2}, where two adjacent sub-items are the same, they can be merged and converted to [A,B,D]. If not all two adjacent elements can be directly merged, remove the frequent itemset, such as {[A,B]:2,[B,D]:2,[C,B]:1}, where the last two items cannot be merged, i.e., the order is not continuous.

[0138] The aforementioned frequent itemsets refer to itemsets that appear frequently in the node path.

[0139] S20132. Based on the frequent itemsets of the node path, determine the user to be detected and obtain the target node path of the user to be detected.

[0140] In this embodiment, after obtaining the frequent itemsets of the node path, the electronic device can determine the user to be detected and obtain the target node path of the user to be detected through the frequent itemsets of the node path.

[0141] The users to be detected are those who log in outside the target application, and may be users with frequent path associations.

[0142] The target node path mentioned above refers to the node path of the user to be detected outside the target application, and it can be a frequent path.

[0143] Furthermore, based on frequent paths, we can obtain associated user groups and exclude users from infrequent paths.

[0144] Specifically, by identifying the associated users of frequent paths based on the frequent itemsets of node paths, the scope can be further narrowed, reducing the amount of subsequent computation.

[0145] This application processes node path data using a preset algorithm to obtain frequent itemsets of node paths. Based on these frequent itemsets, it identifies the user to be monitored and obtains the target node path of the user to be monitored. This can narrow the scope of the monitored user group and shorten the range of user behavior path points, thereby reducing computation time and resources.

[0146] Continue to refer to Figure 6 , showed Figure 2 A flowchart illustrating a specific embodiment of step S202. Step S202 specifically includes the following steps:

[0147] S2021. Determine the user request field data to be detected in the node path.

[0148] In this embodiment, the above-mentioned request field data may be the request URI, referrer, user_agent (the province where the user belongs), IP address, province where the IP address belongs, city where the IP address belongs, and request time, etc.

[0149] The URI mentioned above can be understood as a user's identity identifier. The IP (Internet Protocol) mentioned above is a network layer protocol in the TCP / IP architecture, used to identify the logical address of a computer on the Internet.

[0150] S2022. The user request field data to be detected is processed by feature extraction using preset rules of thumb to obtain the target node path features.

[0151] In this embodiment, after obtaining the user request field data to be detected, the electronic device can perform feature extraction processing on the user request field data to be detected using preset empirical rules to obtain the target node path features.

[0152] The aforementioned pre-set rule of thumb can be the 3-sigma rule, which is used to quickly extrapolate normal distribution data with known mean and standard deviation.

[0153] Specifically, the complete path of the user request field data includes the number of provinces, cities, IPs, user_agents, number of requests from the same IP, and number of users requesting from the same IP.

[0154] Using the 3-sigma rule, upper limit thresholds μ+3σ are obtained for the number of IP provinces, IP cities, IPs, user_agents, the number of requests from the same IP, and the number of users making requests from the same IP. Here, μ is the mean, and σ is the standard deviation.

[0155]

[0156]

[0157] The above feature extraction process can extract representative and distinctive features, or it can be anomaly feature extraction.

[0158] The above-mentioned node path features can be node path anomaly features.

[0159] This application improves the accuracy of risk application by determining the user request field data to be detected in the node path and using the user request field data to be detected to perform feature extraction processing through preset empirical rules.

[0160] Continue to refer to Figure 7 , showed Figure 2 A flowchart illustrating a specific embodiment following step S203. After step S203, the above-described risk user detection method further includes the following steps:

[0161] S701. If the user to be detected is a risky user, then the user will be blocked and added to the blacklist.

[0162] In this embodiment, the above-mentioned interception refers to blocking or obstruction.

[0163] The aforementioned blacklist is a mechanism used to restrict access by malicious users. Users who are blacklisted will be unable to access the target application services.

[0164] In one embodiment, the activities associated with frequent paths of blacklisted users outside the application are reported to the rights and benefits platform daily for dynamic adjustment of the target groups and rights items; at the same time, the historical rights of blacklisted users are revoked.

[0165] In another embodiment, blacklisted users are applied to the overall risk control interception.

[0166] Specifically, users outside the target application who are to be detected will be added to the blacklist of active users outside the target application once they match the pre-defined abnormal characteristics of the risk control engine.

[0167] This application can immediately block risks by intercepting and escalating users to a blacklist if the user being tested is deemed a risky user, and it is explainable.

[0168] Continue to refer to Figure 8 , showed Figure 7 A flowchart illustrating a specific embodiment following step S701. After step S701, the above-described risk user detection method further includes the following steps:

[0169] S801. Obtain the login request of a blacklisted user. If the login request includes the username and password parameters passed by the user, then log in through strong verification.

[0170] In this embodiment, the login request includes the username and password provided by the user. The login request refers to a piece of data sent to the server after the user enters their username and password on the login page and clicks the "Login" button. After receiving this data, the server processes the user's authentication and returns a result, either successful or unsuccessful.

[0171] The aforementioned account and password parameters refer to the user's account and password information, which are key information used for login verification.

[0172] The aforementioned strong verification can be a strong verification method such as face recognition or voice recognition.

[0173] Specifically, users on the blacklist who are active outside the target application are required to log in using strong verification methods in the login scenario.

[0174] After receiving a login request from a user on the blacklist, the electronic device can log in using the username and password parameters provided by the user, and then perform strong verification.

[0175] S802. If the login is successful, the blacklisted user will be cleared.

[0176] In this embodiment, the above-mentioned whitewashing process can be understood as removing blacklisted users from the blacklist in order to restore the users' normal usage rights.

[0177] Specifically, if the verification passes normally and the login is successful, the blacklisted user will be cleared and removed from the blacklist.

[0178] This application obtains login requests from blacklisted users, including the username and password parameters provided by the user, and performs strong verification to log in. If the login is successful, the blacklisted user is cleared, which can reduce the user complaint rate and improve the accuracy of risky applications.

[0179] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use 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.

[0180] Foundational artificial intelligence 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. This application can be applied to the fields of artificial intelligence and big data, thereby promoting the construction of smart cities.

[0181] This application falls under the field of smart cities, and this solution can promote the construction of smart cities.

[0182] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware with computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When executed, the program can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0183] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0184] Further reference Figure 9 As a response to the above Figure 2 The implementation of the method shown in this application provides an embodiment of a risk user detection device, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0185] like Figure 9 As shown, the risk user detection device 900 described in this embodiment includes: a first acquisition module 901, a processing module 902, a risk detection module 903, and a determination module 904. Wherein:

[0186] The first acquisition module 901 is used to acquire the target node path of the user to be detected, wherein the user to be detected is a user who logs in outside the target application, and the target node path is the node path of the user to be detected outside the target application.

[0187] The first processing module 902 is used to perform feature extraction processing on the target node path to obtain the target node path features;

[0188] The risk detection module 903 is used to perform risk detection on the target node path features through a preset risk control engine to obtain the risk detection result.

[0189] The determination module 904 is used to determine whether the user to be detected is a risk user based on the risk detection result.

[0190] In this embodiment, the target node path of the user to be detected is obtained. The user to be detected is a user logged in outside the target application, and the target node path is the node path of the user to be detected outside the target application. Feature extraction processing is performed on the target node path to obtain target node path features. The target node path features are then used to perform risk detection through a preset risk control engine to obtain risk detection results. The risk detection results are then used to determine whether the user to be detected is a risky user. This solves the problem that the identification of abnormal user activity paths takes a long time and consumes a lot of resources, resulting in the inability to block risky users in real time.

[0191] See Figure 10 ,for Figure 9 A schematic diagram of a specific embodiment of the first acquisition module 901 is shown. The first acquisition module 901 includes a first acquisition submodule 9011, a path extraction submodule 9012, and a second acquisition submodule 9013. Wherein:

[0192] The first acquisition submodule 9011 is used to acquire the node path of the user record;

[0193] The path extraction submodule 9012 is used to extract the node path of the recorded user to obtain node path data;

[0194] The second acquisition submodule 9013 is used to determine the user to be detected based on the node path data, and to acquire the target node path of the user to be detected.

[0195] In this embodiment, by acquiring the node path of the recorded user and extracting the path of the recorded user to obtain node path data, and by determining the user to be detected based on the node path data, the target node path of the user to be detected can be obtained, thereby narrowing the scope of the monitored user group and shortening the range of user behavior path points, thus reducing computation time and resources.

[0196] See Figure 11 ,for Figure 10 A schematic diagram of a specific embodiment of the first acquisition submodule 9011 is shown. The first acquisition submodule 9011 includes an establishment unit 90111, a recording unit 90112, and an acquisition unit 90113. Wherein:

[0197] Establishment unit 90111 is used to establish a user list, which includes users who log in from outside the target application;

[0198] Recording unit 90112 is used to record user path records within a preset time period;

[0199] The acquisition unit 90113 is used to acquire the node path of the recorded user based on the user list and the user path records within the preset time period.

[0200] In this embodiment, by establishing a user list, recording user path records within a preset time period, and obtaining the node path of the recorded user based on the user list and the user path records within the preset time period, the accuracy of risk application can be improved.

[0201] See Figure 12 ,for Figure 10 A schematic diagram of a specific embodiment of the second acquisition submodule 9013 is shown. The second acquisition submodule 9013 includes a data processing unit 90131 and a data processing unit 90132. Wherein:

[0202] The data processing unit 90131 is used to process the node path data through a preset algorithm to obtain the frequent itemsets of the node path;

[0203] The data processing unit 90132 is used to determine the user to be detected based on the frequent itemsets of the node path, and to obtain the target node path of the user to be detected.

[0204] In this embodiment, by processing the node path data through a preset algorithm, frequent itemsets of the node paths are obtained. Based on the frequent itemsets of the node paths, the user to be detected is determined, thereby obtaining the target node path of the user to be detected. This can narrow the scope of the monitored user group and shorten the range of user behavior path points, reducing computation time and resources.

[0205] See Figure 13 ,for Figure 9 A schematic diagram of the structure of the first processing module 902 in a specific embodiment is shown. The first processing module 902 includes a determining submodule 9021 and a processing submodule 9022. Wherein:

[0206] The determination submodule 9021 is used to determine the user request field data to be detected in the node path;

[0207] The processing submodule 9022 is used to perform feature extraction processing on the user request field data to be detected using preset empirical rules to obtain the target node path features.

[0208] In this embodiment, by determining the user request field data to be detected in the node path, and using the user request field data to be detected to perform feature extraction processing through preset empirical rules, the target node path features are obtained, thereby improving the accuracy of risk application.

[0209] See Figure 14 ,for Figure 9 A schematic diagram of a specific embodiment of the medium-risk user detection device 900 is shown. The risk user detection device 900 also includes a second processing module 905.

[0210] in:

[0211] The second processing module 905 is used to intercept and upgrade the user to the blacklist if the user to be detected is a risky user.

[0212] In this embodiment, by intercepting and escalating the user to the blacklist if the user to be detected is a risky user, the risk can be blocked immediately, and the system is explainable.

[0213] See Figure 15 ,for Figure 9 A schematic diagram of a specific embodiment of the medium-risk user detection device 900 is shown. The risk user detection device 900 further includes a second acquisition module 906 and a third processing module 907. Wherein:

[0214] The second acquisition module 906 is used to acquire login requests from blacklisted users. The login request includes the account and password parameters passed by the user, and then login is performed through strong verification.

[0215] The third processing module 907 is used to clear the blacklist user if the login is successful.

[0216] In this embodiment, by obtaining the login request of a blacklisted user, which includes the user's account and password parameters, and performing strong verification to log in, if the login is successful, the blacklisted user is cleared, which can reduce the user complaint rate and improve the accuracy of risky applications.

[0217] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 16 , Figure 16 This is a basic structural block diagram of the computer device in this embodiment.

[0218] The computer device 16 includes a memory 161, a processor 162, and a network interface 163 that are interconnected via a system bus. It should be noted that only the computer device 16 with components 161-163 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described here is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0219] The computer device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device can interact with the user via a keyboard, mouse, remote control, touchpad, or voice control.

[0220] The memory 161 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disk, etc.

[0221] In some embodiments, the memory 161 may be an internal storage unit of the computer device 16, such as a hard disk or RAM of the computer device 16. In other embodiments, the memory 161 may also be an external storage device of the computer device 16, such as a plug-in hard disk, SmartMedia Card (SMC), Secure Digital (SD) card, Flash Card, etc., provided on the computer device 16. Of course, the memory 161 may include both the internal storage unit and its external storage device of the computer device 16. In this embodiment, the memory 161 is typically used to store the operating system and various application software installed on the computer device 16, such as computer-readable instructions for risk user detection methods. In addition, the memory 161 may also be used to temporarily store various types of data that have been output or will be output. The processor 162 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip in some embodiments. The processor 162 is typically used to control the overall operation of the computer device 16. In this embodiment, the processor 162 is used to execute computer-readable instructions stored in the memory 161 or process data, such as executing computer-readable instructions of the risk user detection method.

[0222] The network interface 163 may include a wireless network interface or a wired network interface, which is typically used to establish communication connections between the computer device 16 and other electronic devices.

[0223] In this embodiment, the impact data of the system in the knowledge base can be used to generate risk user detection for users affected by the target system under test. This allows users to intuitively understand the impact range of the target system under test. Based on the impact range of the target system under test, the impact of changes can be assessed more accurately and quickly, irrelevant interference points can be eliminated, regression test cases can be simplified, and the omission of impact points in the early assessment can be avoided. This prevents the discovery of some unprocessed correlations when various systems are developed and integrated during the later stages of integration testing. At best, it requires development time to supplement the logic; at worst, the solution design may need to be scrapped and redone, thereby improving the efficiency of project development.

[0224] This application also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the risk user detection method described above.

[0225] In this embodiment, the impact data of the system in the knowledge base can be used to generate risk user detection for users affected by the target system under test. This allows users to intuitively understand the impact range of the target system under test. Based on the impact range of the target system under test, the impact of changes can be assessed more accurately and quickly, irrelevant interference points can be eliminated, regression test cases can be simplified, and the omission of impact points in the early assessment can be avoided. This prevents the discovery of some unprocessed correlations when various systems are developed and integrated during the later stages of integration testing. At best, it requires development time to supplement the logic; at worst, the solution design may need to be scrapped and redone, thereby improving the efficiency of project development.

[0226] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0227] Obviously, the embodiments described above are only some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the patent scope of this application. This application can be implemented in many different forms; rather, the purpose of providing these embodiments is to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this application.

Claims

1. A method for detecting risky users, characterized in that, Includes the following steps: Obtain the target node path of the user to be detected, wherein the user to be detected is a user who logs in outside the target application, and the target node path is the node path of the user to be detected outside the target application; The target node path is subjected to feature extraction processing to obtain the target node path features; The target node path features are used to perform risk detection through a preset risk control engine to obtain risk detection results; Based on the risk detection results, determine whether the user to be detected is a risk user; The step of obtaining the target node path of the user to be detected includes: Retrieve the node path of the user record; Extract the node path of the recorded user to obtain node path data; Based on the node path data, the user to be detected is determined, and the target node path of the user to be detected is obtained. The step of performing feature extraction processing on the target node path to obtain the target node path features includes: Determine the request field data of the user to be detected in the node path; The request field data of the user to be detected is processed by feature extraction using a preset rule of thumb to obtain the target node path features, wherein the preset rule of thumb is the 3-sigma rule.

2. The risk user detection method according to claim 1, characterized in that, The steps for obtaining the node path of the user record include: Create a user list, which includes users who log in from outside the target application; Record user path information within a preset time period; Based on the user list and the user path records within the preset time period, obtain the node path of the recorded user.

3. The risk user detection method according to claim 2, characterized in that, The steps of determining the user to be detected based on the node path data and obtaining the target node path of the user to be detected include: The node path data is processed using a preset algorithm to obtain frequent itemsets of the node paths; Based on the frequent itemsets of the node paths, the user to be detected is determined, and the target node path of the user to be detected is obtained.

4. The risk user detection method according to claim 1, characterized in that, After the step of determining whether the user to be detected is a risk user based on the risk detection result, the method further includes: If the user to be detected is a risky user, then the user will be blocked and added to the blacklist.

5. The risk user detection method according to claim 4, characterized in that, After the step of blocking and escalating the user to the blacklist if the user to be detected is a risky user, the method further includes: If a user on the blacklist submits a login request, which includes the username and password parameters passed by the user, then the user can log in using strong authentication. If the login is successful, the blacklisted user will be cleared.

6. A risk user detection device, characterized in that, The risk user detection device implements the steps of the risk user detection method as described in any one of claims 1 to 5, wherein the risk user detection device comprises: The first acquisition module is used to acquire the target node path of the user to be detected, wherein the user to be detected is a user who logs in outside the target application, and the target node path is the node path of the user to be detected outside the target application; The processing module is used to perform feature extraction processing on the target node path to obtain the target node path features; The risk detection module is used to perform risk detection on the target node path features through a preset risk control engine to obtain risk detection results; The determination module is used to determine whether the user to be detected is a risk user based on the risk detection results.

7. A computer device comprising a memory and a processor, the memory storing computer-readable instructions, wherein the processor, when executing the computer-readable instructions, implements the steps of the risk user detection method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the risk user detection method as described in any one of claims 1 to 5.

Images