WO2019179068A1

WO2019179068A1 - Risk detection method and device, and mobile terminal and storage medium

Info

Publication number: WO2019179068A1
Application number: PCT/CN2018/104729
Authority: WO
Inventors: 孙成; 龙觉刚; 叶俊锋; 赖云辉; 罗先贤
Original assignee: 平安科技（深圳）有限公司
Priority date: 2018-03-22
Filing date: 2018-09-08
Publication date: 2019-09-26
Also published as: CN108615158A; CN108615158B

Abstract

A risk detection method and device, and a mobile terminal and a storage medium. The risk detection method comprises: selecting a service system, and setting a risk detection rule template in the service system, the risk detection rule template being internally provided with rule conditions and rule actions for execution, and a rule triggering threshold being set in the rule conditions (S1); setting a monitoring program to monitor all data requests received in the service system (S2); and determining whether the data requests are within a risk range or not according to the checking performed on the monitored data requests received in the service system by means of the rule triggering threshold in the risk detection rule template, and executing a corresponding strategy by means of the rule actions (S3). The method is simple and easy to use, and saves the labor and time cost. The detection rules are high in matching response speed and have small influences on the system.

Description

Risk detection method, device, mobile terminal and storage medium

The present application claims priority to Chinese Patent Application No. 201101239614.3, entitled "Risk Detection Method, Apparatus, Mobile Terminal, and Storage Medium", filed on March 22, 2018, the entire contents of which are incorporated by reference. In this application.

Technical field

The present application relates to the field of Internet risks, and in particular, to a risk detection method, apparatus, mobile terminal, and storage medium.

Background technique

In the real estate transaction business system, it is necessary to perform risk detection on various business operations, and correspondingly, various risk detection rules need to be inserted in the business logic. The risk detection rules in real estate transactions are usually implemented by software developers by modifying the back-end code of the business system; in the use of risk detection rules, business rules and risk detection are often linearly connected, when professional developers perform operational requests on the business. Access to risk detection rules is included; in addition, system risk detection rules and business rules are extremely difficult to split.

The defects of the prior art risk detection mainly include: the software developer manually modifies the background code, the operation is complicated, the response speed of the system is slowed down, and the access of other systems is inconvenient.

In view of the above defects, the technical solution proposes a risk detection system for rule modification and access in the real estate transaction system, which does not require professional software developers to modify, so as to reduce the difficulty of modifying the risk detection rules and ensure that the risk detection rules are not matched. Affects normal business requests without affecting normal system response speed.

Summary of the invention

The present application aims to propose a risk detecting method, apparatus, mobile terminal and storage medium to solve the deficiencies in the above background art. The modification of the traditional risk detection rules is limited to the need of professionals; the system access requirements are high, and it is not convenient for other systems to access and use; when the risk detection is performed, the response speed of the system normal service request is reduced.

In order to achieve the above object, the present application provides the following technical solutions:

A risk detection method includes: S1: selecting a service system, and setting a risk detection rule template in the service system, wherein the risk detection rule template is provided with a rule condition and a rule action for performing, where the rule condition is Setting a rule trigger threshold; S2: setting a listener to listen to all data requests received in the service system; S3: verifying the data request received by the monitoring service system through the rule trigger threshold in the risk detection rule template, and determining the data Whether the request is within the risk range and the corresponding action is executed by the rule action.

Based on the same technical concept, the present application further provides a risk detecting apparatus, where the risk detecting apparatus includes: a setting module, configured to select a service system, and set a risk detection rule template in the service system, the risk detection rule template a rule condition and a rule action for performing are set, and a rule trigger threshold is set in the rule condition; the listening module is configured to set a listener, and listen to all data requests received in the service system; The module is configured to check the data request received in the monitoring service system through the rule trigger threshold in the risk detection rule template, determine whether the data request is within the risk range, and execute the corresponding countermeasure by the rule action.

Based on the same technical concept, the present application further provides a mobile terminal comprising: a touch sensitive display; a memory; one or more processors; the one or more processors configured to perform the following steps:

S1: Select a service system, and set a risk detection rule template in the service system, where the risk detection rule template has a rule condition and a rule action, and the rule trigger threshold is set in the rule condition;

S2: setting a listener to listen to all data requests received in the service system;

S3: Checking the data request received in the monitoring service system by using the rule trigger threshold in the risk detection rule template, determining whether the data request is within the risk range, and performing corresponding countermeasures by using the rule action.

Based on the same technical concept, the present application also provides a storage medium storing computer readable instructions that, when executed by one or more processors, cause one or more processors to perform the following steps:

The above-mentioned risk detection method, device, mobile terminal and storage medium select a service system, and customize a risk detection rule template for risk detection according to its business function and other business systems with which data is exchanged, and set rules therein. Conditions and rule actions for execution; setting up a listener in the business system to listen for all data requests received in the business system; operating the business process to process the business logic and the application of the risk detection rules in an asynchronous thread, When the matching process between the request data monitoring and the risk detection risk detection rule template is performed, the system business logic runs normally, and the data request and the risk detection rule are matched to determine whether the request is within the risk range, and the corresponding action is performed by the rule action. Countermeasures.

DRAWINGS

Various other advantages and benefits will become apparent to those skilled in the art from a The drawings are only for the purpose of illustrating the preferred embodiments and are not intended to be limiting.

1 is a flowchart of an overall implementation of risk detection in an embodiment of the present application;

2 is a flow chart of setting a risk detection rule template in an embodiment of the present application;

3 is a flowchart of setting a listener program in an embodiment of the present application;

4 is a flowchart of a risk detection rule verification in an embodiment of the present application;

FIG. 5 is a structural structural diagram of a risk risk detecting apparatus according to an embodiment of the present application; FIG.

FIG. 6 is a schematic block diagram of an embodiment of a structure of a mobile terminal according to an embodiment of the present disclosure.

detailed description

The technical solutions in the embodiments of the present application are clearly and completely described in the following with reference to the drawings in the embodiments of the present application. It is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present application without departing from the inventive scope are the scope of the present application.

In an embodiment, as shown in FIG. 1 , the present application provides a technical solution:

A risk detection method, the risk detection method, comprising: S1: selecting a service system, setting a risk detection rule template in the service system, wherein the risk detection rule template is provided with a rule condition and a rule action for execution , setting a rule trigger threshold in the rule condition. The risk detection rule template is a risk detection rule template for risk detection set in the real estate transaction system, and has a rule condition for defining risk detection and a rule for executing the specified risk detection step. Action, the risk detection rule template is implemented by changing the rule condition set on the template and the rule action for execution when the update is needed. The risk detection means that the risk manager adopts various measures and methods to eliminate or reduce the risk entry or occurrence of the data request in the real estate transaction system, so as to reduce the loss of data information caused by the risk.

S2: Set the listener to listen to all data requests received in the business system. The intercepting program is to embed a Trojan program in the real estate transaction system for backing up all the data request contents in the real estate transaction system, and uploading to the fixed property in the real estate transaction system through a network connection or WIFI. Position; the listening principle is GSM, which encodes, encrypts, and interleaves the voice signal channel on the system channel, and forms a burst to be modulated and transmitted. At the receiving end of the real estate transaction system, the signal is demodulated, deinterleaved, channel decoded, and speech decoded, and then restored to a voice signal in the real estate transaction system; the GSM system uses narrowband time division multiple access (TDMA) in the transmission process. Technology, its bandwidth of each carrier frequency channel is 200KHz, 8 time slots per frame, theoretically allows one RF to perform 8 groups of interactions at the same time, each time slot is 0.577ms in length and the frame duration is 4.615ms, which is to divide the time. Periodically, each frame is divided into a plurality of time slots, and then according to a specific time gap allocation principle, the mobile phone user sends a signal to the base station in each frame for a specified time interval, and the base stations respectively specify In the time gap, different data request signals are received, and the base station also transmits signals to different real estate transaction systems according to a prescribed time interval, and each user receives signals in a specified time interval.

S3: Checking the data request received in the monitoring service system by using the rule trigger threshold in the risk detection rule template, determining whether the data request is within the risk range, and performing corresponding countermeasures by using the rule action. The data request in the real estate transaction system is verified, and the request data is judged to be within the risk range by comparing and matching the request data with the data template in the real estate transaction system. The corresponding countermeasures include shielding the IP address of the requesting party, the operation account issued by the locking request, and the like.

In one embodiment, as shown in FIG. 2, S1 includes S101 to S103:

S101: Select a service system, and customize a risk detection rule template for risk detection according to its business function and other business systems with which data is exchanged, and set rule conditions and rule actions for execution. A custom risk detection rule template is provided, which has a rule condition for defining risk detection and a rule action for performing the specified risk detection step. The rule conditions and the rule actions for execution cooperate to control the risk monitoring in the real estate transaction system.

A rule trigger threshold is set in the rule condition, and the threshold value, also called a threshold value, refers to a lowest value or a highest value that an effect can generate. The user sets a maximum value and a minimum value of the request data within a risk range as a rule threshold, and is used to verify whether the request data is within a risk range, and the user sets a risk threshold template in the background of the real estate transaction system. Can be updated. When a data request is received, it is determined whether the data request is within the risk range by matching the data request content with the rule trigger threshold.

S102: The service system loads a specific rule engine to parse the risk detection rule template, and generates a corresponding risk detection rule after importing the template, and the modification rule only needs to modify the template and import the online update rule.

The settings in the risk detection rule template include a rule name, a trigger condition, a priority, and an execution.

For example, parsing or displaying the risk detection rule template using the parse() method, as shown in Table 1:

The first parameter is the name of the view file (in this case, the file name is blog_template.php), and the second parameter is an associative array containing the data to be replaced by the template. In the above example, the template will contain two variables: {blog_title} and {blog_heading}.

It is not necessary to echo or otherwise process the result returned by the $this->parser->parse() method, which is automatically saved to the output class for delivery to the browser. However, if you want it to return data instead of saving it to the output class, you can set the third parameter to TRUE, as shown in Table 2:

$string=$this->parser->parse('blog_template',$data,TRUE);

In one embodiment, as shown in FIG. 3, S2 includes S201 to S202:

S201: setting a listener in the system for monitoring all data request contents;

Create a listener First select oracle on the computer, then select "Configuration and Move Tool" to open Oracle Net Manager; then select "Listener", click the "+" icon on the left to create the listener. The listener is configured to monitor the received data request and determine whether the content of the monitored data request is within the risk range.

S202: Store the monitored content to a preset position in the listener.

After listening to the content of the data request, the listener connects to the front-end codec through the computer system server, downloads the data through the streaming protocol, and then stores the monitored data request content in a preset location in the listener.

In one embodiment, as shown in FIG. 4, S3 includes S301 to S302:

S301: The corresponding risk detection rule is invoked according to the content of the data request, and the requested service function is matched with the rule trigger threshold function corresponding to the risk detection rule template.

The corresponding risk detection rule is invoked to determine whether the request is within the risk range according to the matching of the requesting service function and the rule corresponding to the risk detection risk detection rule template. The implementation of the rule trigger threshold may adopt a pre-made risk operation feature list, which stores a known risk operation feature, and may also store non-business data such as an underlying file access and operation, a call to a system level operation, and the like. Requesting or instructing the operational characteristics of the request in order to prevent security risks arising from exploitation of the vulnerabilities in the code itself;

S302: If the data request content is within the rule trigger threshold, there is a risk, and the corresponding countermeasure is executed according to the rule action for execution, and a warning prompt is issued;

If there is a risk, an instruction for performing a rule action in the risk detection rule template is executed according to the result of the matching. For example, the IP address of the requesting party is blocked, and the operation account issued by the locking request is blocked.

S303: If the data request content is not within the rule trigger threshold, there is no risk and is imported into the execution queue of the normal business logic.

The rule triggers the threshold matching according to the requested service function and the risk detection risk detection rule template, and determines that the request is directly processed through the normal service logical channel if there is no risk.

Based on the same technical concept, the present application further provides a risk detecting apparatus. As shown in FIG. 5, the risk detecting apparatus includes: a setting module, configured to select a service system, and configured to set a risk detection rule template in the service system. The risk detection rule template is provided with a rule condition and a rule action for performing, and a rule trigger threshold is set in the rule condition; the interception module is set to set a listener, and listens to all data requests received in the service system. The verification module is configured to check the data request received in the monitoring service system through the rule trigger threshold in the risk detection rule template, determine whether the data is in the risk range, and execute the corresponding countermeasure by the rule action. In this embodiment, different real estate transaction systems set different risk detection rules, and any risk detection rule has a set of identification rules for determining whether it is an illegal request; the rule trigger threshold uses a preset risk operation feature list, The list of risk operation features includes an underlying file access and a call to a system operation that is not a business class data request operation feature; the countermeasure includes masking the requestor IP address or an operation account issued by the lock request.

In an embodiment, the setting module includes: a rule setting module, configured to customize a risk detection rule template for risk detection according to a service function of the service system and other service systems with which data is exchanged, and set a rule condition therein And a rule action module for executing; the rule generation module is configured to load a specific rule engine to parse the risk detection rule template by the business system, and generate a corresponding risk detection rule after importing the template, and the modification rule only needs to modify and import the template. You can complete the online update rules.

In one embodiment, the listening module comprises: a listener setting module, configured to set a listener in the system, configured to listen to all data request content; and listen to the content storage module, and set to store the monitored content in the listener. Set the location.

In an embodiment, the verification module includes: a matching module, configured to: according to the monitored data request content, invoke a corresponding risk detection rule to match the requested service function with a rule trigger threshold function corresponding to the risk detection rule template; The countermeasure module is set to have a risk if the data request content is within the rule trigger threshold, execute the corresponding countermeasure according to the rule action for execution, and issue a warning prompt; the execution module is set to if the data request content is not at the rule trigger threshold Within there, there is no risk and it is imported into the execution queue of normal business logic.

Based on the same technical concept, the present application further provides a mobile terminal for implementing a method for detecting risk across mobile applications. As shown in FIG. 6 , for the convenience of description, only parts related to the embodiment of the present application are shown. For specific technical details not disclosed, please refer to the method part of the embodiment of the present application. The terminal may be any terminal device including a mobile phone, a tablet computer, a PDA (Personal Digital Assistant), a POS (Point of Sales), an in-vehicle computer, and the mobile terminal is used as a mobile phone as an example:

FIG. 6 is a block diagram showing a partial structure of a mobile phone related to a mobile terminal provided by an embodiment of the present application. Referring to FIG. 6, the mobile phone includes: a baseband processing module 410, a memory 420, an input unit 430, a display unit 440, a sensor 450, an audio circuit 460, a Wireless Fidelity (WiFi) module 470, a processor 480, and a power supply 490. component. It will be understood by those skilled in the art that the structure of the handset shown in FIG. 6 does not constitute a limitation to the handset, and may include more or less components than those illustrated, or some components may be combined, or different components may be arranged.

The baseband processing module 410 can be used to synthesize the baseband signal to be transmitted or to decode the received baseband signal. Specifically, the audio signal is compiled into a baseband code for transmission upon transmission; upon reception, the received baseband code is interpreted as an audio signal. At the same time, it is also responsible for the compilation of address information, text information (short message text, website and text), and picture information.

The memory 420 can be used to store software programs and modules, and the processor 480 executes various functional applications and data processing of the mobile phone by running software programs and modules stored in the memory 420. The memory 420 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application required for at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may be stored according to Data created by the use of the mobile phone (such as audio data, phone book, etc.). Moreover, memory 420 can include high speed random access memory, and can also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device.

The input unit 430 can be configured to receive input numeric or character information and to generate key signal inputs related to user settings and function controls of the handset. Specifically, the input unit 430 may include a touch panel 431 and other input devices 432. The touch panel 431, also referred to as a touch screen, can collect touch operations on or near the user (such as a user using a finger, a stylus, or the like on the touch panel 431 or near the touch panel 431. Operation), and drive the corresponding connecting device according to a preset program. Optionally, the touch panel 431 may include two parts: a touch detection device and a touch controller. Wherein, the touch detection device detects the touch orientation of the user, and detects a signal brought by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, converts the touch information into contact coordinates, and sends the touch information. The processor 480 is provided and can receive commands from the processor 480 and execute them. In addition, the touch panel 431 can be implemented in various types such as resistive, capacitive, infrared, and surface acoustic waves. In addition to the touch panel 431, the input unit 430 may also include other input devices 432. Specifically, other input devices 432 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control buttons, switch buttons, etc.), trackballs, mice, joysticks, and the like.

The display unit 440 can be used to display information input by the user or information provided to the user as well as various menus of the mobile phone. The display unit 440 can include a display panel 441. Alternatively, the display panel 441 can be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like. Further, the touch panel 431 can cover the display panel 441. When the touch panel 431 detects a touch operation on or near the touch panel 431, it transmits to the processor 480 to determine the type of the touch event, and then the processor 480 according to the touch event. The type provides a corresponding visual output on display panel 441. Although the touch panel 431 and the display panel 441 are used as two independent components to implement the input and input functions of the mobile phone in FIG. 6, in some embodiments, the touch panel 431 may be integrated with the display panel 441. Realize the input and output functions of the phone.

The handset may also include at least one type of sensor 450, such as a light sensor, motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display panel 441 according to the brightness of the ambient light, and the proximity sensor may close the display panel 441 and/or when the mobile phone moves to the ear. Or backlight. As a kind of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in all directions (usually three axes). When it is stationary, it can detect the magnitude and direction of gravity. It can be used to identify the gesture of the mobile phone (such as horizontal and vertical screen switching, related Game, magnetometer attitude calibration), vibration recognition related functions (such as pedometer, tapping), etc.; as for the mobile phone can also be configured with gyroscopes, barometers, hygrometers, thermometers, infrared sensors and other sensors, no longer Narration.

Audio circuit 460, speaker 461, and microphone 462 provide an audio interface between the user and the handset. The audio circuit 460 can transmit the converted electrical data of the received audio data to the speaker 461 for conversion to the sound signal output by the speaker 461; on the other hand, the microphone 462 converts the collected sound signal into an electrical signal by the audio circuit 460. After receiving, it is converted into audio data, and then processed by the audio data output processor 480, sent to the other mobile phone via the RF circuit 410, or outputted to the memory 420 for further processing.

WiFi is a short-range wireless transmission technology, and the mobile phone can help users to send and receive emails, browse web pages, and access streaming media through the WiFi module 470, which provides users with wireless broadband Internet access. Although FIG. 6 shows the WiFi module 470, it can be understood that it does not belong to the essential configuration of the mobile phone, and may be omitted as needed within the scope of not changing the essence of the present application.

The processor 480 is the control center of the handset, and connects various portions of the entire handset using various interfaces and lines, by executing or executing software programs and/or modules stored in the memory 420, and invoking data stored in the memory 420, executing The phone's various functions and processing data, so that the overall monitoring of the phone. Optionally, the processor 480 may include one or more processing units; preferably, the processor 480 may integrate an application processor and a modem processor, where the application processor mainly processes an operating system, a user interface, an application, and the like. The modem processor primarily handles wireless communications. It can be understood that the above modem processor may not be integrated into the processor 480.

The handset also includes a power source 490 (such as a battery) that supplies power to the various components. Preferably, the power source can be logically coupled to the processor 480 via a power management system to manage functions such as charging, discharging, and power management through the power management system.

Although not shown, the mobile phone may further include a camera, a Bluetooth module, and the like, and details are not described herein again.

In the embodiment of the present application, the processor 480 included in the terminal may perform the steps of the risk detecting method in the foregoing embodiment.

Based on the same technical concept, the present application also provides a storage medium storing computer readable instructions, which when executed by one or more processors, cause one or more processors to execute in the above embodiments The step of the risk detecting method, wherein the storage medium may be a non-volatile storage medium.

A person skilled in the art may understand that all or part of the various steps of the foregoing embodiments may be performed by a program to instruct related hardware. The program may be stored in a computer readable storage medium, and the storage medium may include: Read Only Memory (ROM), Random Access Memory (RAM), disk or optical disk.

It will be understood by those skilled in the art that all or part of the steps of implementing the above embodiments may be performed by a program to instruct related hardware, and the program may be stored in a computer readable storage medium, the above mentioned storage. The medium can be a read only memory, a magnetic disk or an optical disk or the like.

The above-described embodiments are only illustrative of some exemplary embodiments of the present application, and the description thereof is more specific and detailed, and is not to be construed as limiting the scope of the claims. It should be noted that a number of variations and modifications may be made by those skilled in the art without departing from the spirit and scope of the present application. Therefore, the scope of the invention should be determined by the appended claims.

Claims

A risk detection method, including:

S1: Select a service system, and set a risk detection rule template in the service system, where the risk detection rule template is provided with a rule condition and a rule action for performing, and a rule trigger threshold is set in the rule condition;

S2: setting a listener to listen to all data requests received in the service system;

S3: Checking the data request received in the monitoring service system by using the rule trigger threshold in the risk detection rule template, determining whether the data request is within the risk range, and performing corresponding countermeasures by using the rule action.
A risk detecting method according to claim 1, wherein said S1 comprises:

S101: Select a service system, and customize a risk detection rule template for risk detection according to its business function and other business systems with which data is exchanged, and set rule conditions and rule actions for execution;

S102: The service system loads a specific rule engine to parse the risk detection rule template, and generates a corresponding risk detection rule after importing the template, and the modification rule only needs to modify the template and import the online update rule.
A risk detecting method according to claim 1, wherein said S2 comprises:

S201: setting a listener in the system for monitoring all data request contents;

S202: Store the monitored content to a preset position in the listener.
A risk detecting method according to claim 1, wherein said S3 comprises:

S301: The corresponding risk detection rule is invoked according to the content of the data request, and the requested service function is matched with the rule trigger threshold function corresponding to the risk detection rule template.

S302: If the data request content is within the rule trigger threshold, there is a risk, and the corresponding countermeasure is executed according to the rule action for execution, and a warning prompt is issued;

S303: If the data request content is not within the rule trigger threshold, there is no risk and it is imported into the execution queue of the normal business logic.
The risk detecting method according to claim 1, wherein the risk detecting method further comprises: different risk detecting rules are set by different real estate transaction systems, and any risk detecting rule corresponds to a set of identifying rules for determining whether Is an illegal request.
The risk detection method according to claim 1, wherein the rule trigger threshold adopts a preset risk operation feature list, and the risk operation feature list includes an underlying file access and a non-business data request for invoking a system operation. Operating characteristics.
A risk detecting method according to claim 1, wherein said countermeasure comprises masking the requester IP address or an operation account issued by the lock request.
A risk detecting device comprising:

The setting module is configured to select a business system, and set a risk detection rule template in the business system, where the risk detection rule template has a rule condition and a rule action for execution, and the rule trigger threshold is set in the rule condition ;

a listening module, configured to set a listener, and listen to all data requests received in the business system;

The verification module is configured to check the data request received in the monitoring service system through the rule trigger threshold in the risk detection rule template, determine whether the data request is within the risk range, and execute the corresponding countermeasure by the rule action.
The risk detecting device according to claim 8, wherein the setting module comprises:

a rule setting module, configured to customize a risk detection rule template for risk detection according to a business function of the business system and other business systems with which data is exchanged, and set a rule condition and a rule action for execution;

The rule generation module is configured to load a specific rule engine to parse the risk detection rule template by the business system, and generate a corresponding risk detection rule after importing the template, and the modification rule only needs to modify the template and import the online update rule.
The risk detecting apparatus according to claim 8, wherein the monitoring module comprises:

The listener setting module is set to set a listener in the system for monitoring all data request contents;

The content storage module is monitored and configured to store the monitored content to a preset location in the listener.
The risk detecting apparatus according to claim 8, wherein the verification module comprises:

The matching module is configured to: according to the content of the monitored data request, invoke the corresponding risk detection rule, so that the requested service function matches the rule trigger threshold function corresponding to the risk detection rule template;

The countermeasure module is set to have a risk if the data request content is within the rule trigger threshold, and the corresponding countermeasure is executed according to the rule action for execution, and a warning prompt is issued;

The execution module is set so that if the data request content is not within the rule trigger threshold, there is no risk and it is imported into the execution queue of the normal business logic.
The risk detecting apparatus according to claim 8, wherein different real estate transaction systems set different risk detection rules, and any risk detection rule corresponds to a set of identification rules for determining whether the request is an illegal request;

The rule trigger threshold adopts a preset risk operation feature list, where the risk operation feature list includes an underlying file access and a call for non-business data request operation feature for system operation;

The countermeasure includes shielding the requester IP address or the operation account issued by the lock request.
A mobile terminal comprising: a touch sensitive display; a memory; one or more processors;

The one or more processors are configured to perform the following steps:

S1: Select a service system, and set a risk detection rule template in the service system, where the risk detection rule template has a rule condition and a rule action, and the rule trigger threshold is set in the rule condition;

S2: setting a listener to listen to all data requests received in the service system;

S3: Checking the data request received in the monitoring service system by using the rule trigger threshold in the risk detection rule template, determining whether the data request is within the risk range, and performing corresponding countermeasures by using the rule action.
The mobile terminal of claim 14, wherein said step S1 causes said processor to perform the following steps:

S101: Select a service system, and customize a risk detection rule template for risk detection according to its business function and other business systems with which data is exchanged, and set rule conditions and rule actions for execution;

S102: The service system loads a specific rule engine to parse the risk detection rule template, and generates a corresponding risk detection rule after importing the template, and the modification rule only needs to modify the template and import the online update rule.
The mobile terminal of claim 14, wherein said step S2 causes said processor to perform the following steps:

S201: setting a listener in the system, and setting to listen to all data request contents;

S202: Store the monitored content to a preset position in the listener.
The mobile terminal of claim 14, wherein said step S3 causes said processor to perform the following steps:

S301: The corresponding risk detection rule is invoked according to the content of the data request, and the requested service function is matched with the rule trigger threshold function corresponding to the risk detection rule template.

S302: If the data request content is within the rule trigger threshold, there is a risk, and the corresponding countermeasure is executed according to the rule action for execution, and a warning prompt is issued;

S303: If the data request content is not within the rule trigger threshold, there is no risk and is imported into the execution queue of the normal business logic.
A storage medium storing computer readable instructions that, when executed by one or more processors, cause one or more processors to perform the steps of:

S1: Select a service system, and set a risk detection rule template in the service system, where the risk detection rule template has a rule condition and a rule action, and the rule trigger threshold is set in the rule condition;

S2: setting a listener to listen to all data requests received in the service system;

S3: Checking the data request received in the monitoring service system by using the rule trigger threshold in the risk detection rule template, determining whether the data request is within the risk range, and performing corresponding countermeasures by using the rule action.
The storage medium of claim 18, wherein the computer readable instructions are executed by one or more processors such that the one or more processors perform the following steps:

S101: Select a service system, and customize a risk detection rule template for risk detection according to its business function and other business systems with which data is exchanged, and set rule conditions and rule actions for execution;

S102: The service system loads a specific rule engine to parse the risk detection rule template, and generates a corresponding risk detection rule after importing the template, and the modification rule only needs to modify the template and import the online update rule.
The storage medium of claim 18, wherein the computer readable instructions are executed by one or more processors such that the one or more processors perform the following steps:

S201: setting a listener in the system, and setting to listen to all data request contents;

S202: Store the monitored content to a preset position in the listener.
The storage medium of claim 18, wherein the computer readable instructions are executed by one or more processors such that the one or more processors perform the following steps:

S301: The corresponding risk detection rule is invoked according to the content of the data request, and the requested service function is matched with the rule trigger threshold function corresponding to the risk detection rule template.

S302: If the data request content is within the rule trigger threshold, there is a risk, and the corresponding countermeasure is executed according to the rule action for execution, and a warning prompt is issued;

S303: If the data request content is not within the rule trigger threshold, there is no risk and is imported into the execution queue of the normal business logic.