CN111614624A - Risk detection method, device, system and storage medium - Google Patents
Risk detection method, device, system and storage medium Download PDFInfo
- Publication number
- CN111614624A CN111614624A CN202010334181.7A CN202010334181A CN111614624A CN 111614624 A CN111614624 A CN 111614624A CN 202010334181 A CN202010334181 A CN 202010334181A CN 111614624 A CN111614624 A CN 111614624A
- Authority
- CN
- China
- Prior art keywords
- information
- link
- service request
- safety
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/951—Indexing; Web crawling techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
- G06F21/6263—Protecting personal data, e.g. for financial or medical purposes during internet communication, e.g. revealing personal data from cookies
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6281—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database at program execution time, where the protection is within the operating system
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
- H04L63/1425—Traffic logging, e.g. anomaly detection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/145—Countermeasures against malicious traffic the attack involving the propagation of malware through the network, e.g. viruses, trojans or worms
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
- G06F2221/033—Test or assess software
Abstract
The embodiment of the specification provides a risk detection method, a risk detection device, a risk detection system and a storage medium, wherein first safety information of a service call link in a client is acquired; second safety information of a service request processing link in the server side; and then comprehensively analyzing the first safety information and the second safety information, and determining whether the service request has risks, so that full-link risk prevention and control of the service are realized.
Description
Technical Field
The embodiment of the specification relates to the technical field of computers, in particular to a risk detection method, a risk detection device, a risk detection system and a storage medium.
Background
With the development of Internet technology, applications of mobile APP, Internet of Things (IoT) device side, and the like are becoming more and more widespread. The security risks faced by mobile APP, IoT devices, etc. also come with it and become more and more complex with the development of business. Therefore, how to perform comprehensive security protection on the mobile APP, the IoT device, and the like in order to ensure the secure use of the mobile APP, the IoT device, and the like and guarantee the benefits of the user and the service platform becomes a problem to be solved urgently.
Disclosure of Invention
The embodiment of the specification provides a risk detection method, a risk detection device, a risk detection system and a storage medium.
In a first aspect, an embodiment of the present specification provides a risk detection method, including: acquiring first security information of a service call link passing through a client in a process from service request initiation to sending, wherein the first security information comprises: link information of the service call link and/or characteristic information of a first key link node preset in the service call link; acquiring second security information of a processing link of the service request in a server, wherein the second security information comprises: link information of the processing link and/or characteristic information of a second key link node preset in the processing link; and determining whether the service request has risks according to the first safety information and the second safety information.
In a second aspect, embodiments of the present specification provide a method for risk detection, the method including: a client initiates a service request, collects first security information of a service call link passing through the process from the initiation to the sending of the service request, and sends the service request and the first security information to a server, wherein the first security information comprises: link information of the service call link and/or characteristic information of a first key link node preset in the service call link; the server processes the received service request and collects second safety information of a processing link of the service request, wherein the second safety information comprises: link information of the processing link and/or characteristic information of a second key link node preset in the processing link; and the server determines whether the service request has risks according to the first safety information and the second safety information.
In a third aspect, embodiments of the present specification provide a risk detection apparatus, including: a first obtaining module, configured to obtain first security information of a service invocation link that a client passes through from a service request initiation to a sending process, where the first security information includes: link information of the service call link and/or characteristic information of a first key link node preset in the service call link; a second obtaining module, configured to obtain second security information of a processing link of the service request in a server, where the second security information includes: link information of the processing link and/or characteristic information of a second key link node preset in the processing link; and the detection module is used for determining whether the service request has risks according to the first safety information and the second safety information.
In a fourth aspect, embodiments of the present specification provide a risk detection system, the system including: client and server, wherein: the client is configured to initiate a service request, collect first security information of a service call link that passes through from the initiation of the service request to the sending of the service request, and send the service request and the first security information to a server, where the first security information includes: link information of the service call link and/or characteristic information of a first key link node preset in the service call link; the server is configured to process the received service request and acquire second security information of a processing link of the service request, where the second security information includes: link information of the processing link and/or characteristic information of a second key link node preset in the processing link; and determining whether the service request has risks according to the first safety information and the second safety information.
In a fifth aspect, an embodiment of the present specification provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor executes the steps of the risk detection method according to the first aspect.
In a sixth aspect, the present specification provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the steps of the risk detection method according to the first aspect.
The embodiment of the specification has the following beneficial effects:
the risk detection method provided in the embodiment of the present specification, which obtains first security information of a service invocation link that a client passes through from a service request initiation to a sending process, includes: the link information of the service call link and/or the characteristic information of a first key link node preset in the service call link; and after receiving the service request sent by the client at the server, acquiring second security information of a processing link of the service request in the server, wherein the second security information comprises: link information of the processing link and/or characteristic information of a second key link node preset in the processing link; and then determining whether the service request is at risk or not according to the first safety information and the second safety information. Risk detection is carried out through collecting and comprehensively analyzing the first safety information of the client and the second safety information of the server, full-link risk prevention and control of service requests are achieved, risks caused by linkage of the client and the server can be effectively detected, and more comprehensive risk prevention and control of the client such as a mobile APP and an IoT device are facilitated.
Drawings
Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:
fig. 1 is a schematic structural diagram of a risk detection system provided in a first aspect of an embodiment of the present disclosure;
fig. 2 is a schematic diagram of a system architecture provided in the first aspect of the embodiment of the present disclosure;
fig. 3 is a schematic diagram of an exemplary service invocation link provided in the first aspect of the embodiments of the present specification;
fig. 4 is a flowchart of a risk detection method provided in a second aspect of embodiments of the present description;
FIG. 5 is a flow chart of a risk detection method provided in a third aspect of embodiments of the present description;
fig. 6 is a block diagram of a risk detection apparatus provided in a fourth aspect of the embodiments of the present disclosure;
fig. 7 is a schematic structural diagram of an electronic device provided in a fifth aspect of an embodiment of the present specification.
Detailed Description
According to the risk detection method, the risk detection device, the risk detection system and the risk detection storage medium, first safety information of a service call link passing through a process from the initiation to the sending of a service request by a client is obtained; second safety information of the service request processing link in the server side is obtained; and then, determining whether the service request has risks according to the first security information and the second security information, so that full-link prevention and control of risks of the client can be realized through the unified security prevention and control link, and more comprehensive risk prevention and control can be performed on the client such as a mobile APP (application program), an IoT (Internet of things) device and the like.
Especially for some risks of linkage of the client and the server, for example, a crawler on the mobile APP side, which alone does not have obvious malicious behaviors on the APP but is simply an automatic operation; the linkage risk detection method is normal on the server side alone, but the client side and the server side can crawl a large amount of data together, and the linkage risk can be effectively prevented and controlled through the risk detection method provided by the embodiment of the specification.
In order to better understand the technical solutions, the technical solutions of the embodiments of the present specification are described in detail below with reference to the drawings and specific embodiments, and it should be understood that the specific features of the embodiments and embodiments of the present specification are detailed descriptions of the technical solutions of the embodiments of the present specification, and are not limitations of the technical solutions of the present specification, and the technical features of the embodiments and embodiments of the present specification may be combined with each other without conflict. In the embodiments of the present specification, the term "plurality" means "two or more", that is, includes two or more cases; the term "and/or" is merely an associative relationship that describes an associated object, meaning that three relationships may exist, e.g., a and/or B, may mean: a exists alone, A and B exist simultaneously, and B exists alone.
In a first aspect, an embodiment of the present specification provides a risk detection system, as shown in fig. 1, the system includes: a client 100 and a server 300. Among them, the client 100 (one is shown in fig. 1 for illustration only, without limiting the number of clients, and there may be multiple clients) may be connected to the server 300 (one is shown in fig. 1 for illustration only, without limiting the number of servers, and there may be multiple servers) through the network 200 to perform data communication or interaction. The client corresponds to a Server end and provides services such as transfer service, payment service or login service for the user. The user can initiate a service request through the client and send the service request to the server, and the server receives the service request, processes the service request and responds to the service request.
It should be noted that the client 100 may be a mobile APP or a browser installed on a user terminal, and the user terminal may be a Personal Computer (PC), a notebook Computer, a tablet Computer, a smart phone, an electronic reader, a vehicle-mounted device, a network television, a wearable device, and other intelligent devices with network functions. Alternatively, the client 100 may also be an IoT device side, etc.
In the risk detection system provided in the embodiment of the present specification, the client is configured to initiate a service request, collect first security information of a service invocation link that passes through from the initiation of the service request to the sending of the service request, and then send the service request and the first security information to the server.
The service request is determined according to a service scenario of an actual application, and may be, for example, a transfer request, a login request, a payment request, or the like. The service call link refers to a call link from the initiation to the sending of the service request at the client, and includes all link nodes through which the service request is sent from the initiation to the final sending. In this implementation, the link nodes refer to code nodes, such as passing interfaces or methods.
For example, the service request is initiated to be issued by a method a1 and a2 in class a (class), a method B1 and a method B3 in class B, a method C2 in class C, an interface d1, and so on. The service invocation link is: type a # method a1 → type a # method a2 → type B # method B1 → type B # method B3 → type C # method C2 → interface d1, and so on. Wherein, each method passing through is a link node.
Specifically, as shown in fig. 2, the client includes an end code and service logic, an end security profile, and an end security profile information reporting channel. The end code and the service logic are used for initiating a service request through the client logic and sending the service request to a service server which corresponds to the client and provides service for a user. The end safety section is a universal and unified safety control layer in the client code and is used for collecting first safety information of a service call link passing through the process from the initiation to the sending of the service request. And the terminal security section information reporting channel is used for reporting the first security information acquired at the client to the unified security management and control layer. It should be noted that the unified security management and control layer may be disposed in the service server, and at this time, the client data request channel may be multiplexed, and the collected first security information and the service request are sent to the service server together. Or, the unified security management and control layer may also be disposed in other servers except the service server, and accordingly, the end security section information reporting channel is an encryption channel for communication between the client and the security server. The safety server is a server specially provided with a uniform safety control layer.
In this embodiment, the first security information may include: the service calls the link information of the link; and/or the characteristic information of the first key link node preset in the service call link, which is determined according to the actual application scenario of the scheme.
In a specific implementation process, the link information of the service invocation link may include: all the link nodes through which the service request passes from the initiation to the sending may specifically include: an identification of each link node and a record of call behavior information. The identification of the link node may include: node names, such as url, class # method name, etc.; the attribute of the node, such as whether the node is credible, internal and external, and the like; the type of the node, such as URL, JAVA method, Native method, etc. The recording of call behavior information may include: the type of the calling action, such as intent jump, ordinary java calling and the like; invoking the parameters, including invoking the parameters supports parsing of the object type. Such as to enable the acquisition of the value of a variable in the object.
For example, in a certain service scenario, a service invocation link of a certain service request is shown in fig. 3, and includes node 1, node 2, node 3 and node 4. Wherein, the name of the node 1 is: www.xxx.com, where "xxx" is used to denote a domain name with attributes: external source, not trusted, type: a URL; the types of the calling actions are: JSAPI calling, calling parameters: { url:' file:// …/./sdcard/pic. The name of node 2 is: getmap, attributes are: internal code, trusted, type: JSAPI; the types of the calling actions are: internet jump, calling parameters: com.yy.image.process.activity. The name of node 3 is: com, yy, image, process, attributes are: internal code, trusted, type: a JAVA class function; the types of the calling actions are: interface calling, calling parameters: { url:' file:// …/./sdcard/pic. The name of the node 4 is: com, open, image, process, attributes are: three-way SDK, untrusted, type: a JAVA class function; the types of the calling actions are: and (5) calling an interface.
The first key link node is predetermined according to an actual application scenario, for example, if it is desired to protect privacy-related information of the user, the first key link node may include an interface for acquiring a location, an address book, and the like of the user. The characteristic information of the first key link node may include security environment information, parameter information, and the like of the link node, and specifically, the characteristic information needs to be determined according to an actual application scenario.
Further, the server is used for processing the received service request and collecting second safety information of a processing link of the service request; and determining whether the service request has risks according to the first safety information and the second safety information.
And after receiving the service request, the server processes the service request so as to respond to the service request. The service request processing link is a link which passes from the process of receiving the service request to the process of processing the service request, and comprises all link nodes which pass through the process of receiving the service request.
In this embodiment, the second security information may include: the service request processes the link information of the link; and/or the characteristic information of a second key link node preset in the service request processing link is determined according to the actual application scene of the scheme. In a specific implementation process, the link information of the service request processing link may include: the service request may specifically include, from the received all link nodes through which the processing is completed: an identification of each link node and a record of call behavior information.
Specifically, as shown in fig. 2, the server may include a cloud code and business logic, a cloud security section, and a cloud security section information reporting channel. The cloud code and the business logic may adopt a general server logic, and are configured to process the received business request and respond to the business request. The cloud security section is a universal and unified security management and control layer in the server code and is used for collecting second security information of a service request processing link passing through the process of receiving and processing the service request. And the cloud security tangent plane information reporting channel is used for reporting the acquired second security information to the unified security management and control layer.
The unified security management and control layer is used for determining whether the service request has risks or not according to first security information reported when the client sends the service request and second security information acquired by a cloud-end security section when the service server processes the service request.
In an alternative embodiment, the unified security management and control layer is disposed in a service server providing the service, belongs to a security service specifically disposed in the service server, and is logically decoupled from the service. And sending the second safety information collected by the cloud safety tangent plane to the unified safety control layer through a cloud safety tangent plane information reporting channel arranged in the service server.
Of course, in other embodiments of the present disclosure, the unified security management and control layer may be disposed in other servers besides the service server. At this time, an encryption channel for communication between the service server and the security server needs to be correspondingly set, so as to report the second security information to the security server and receive a decision instruction issued by the security server.
Specifically, the process of determining whether the service request is at risk according to the first security information and the second security information may include: and if the first safety information meets the first preset safety condition and the second safety information meets the second preset safety condition, judging that the service request has risks, otherwise, judging that the service request does not have risks. And the first preset safety condition and the second preset safety condition are both monitoring conditions for risk detection.
In this embodiment of the present description, specific contents of the first security information, the second security information, the first preset security condition, and the second preset security condition may be preset according to an object to be protected in an actual application scenario of the present solution.
For example, in an alternative embodiment, the first security information includes link information of the service invocation link, and the second security information includes link information of the service request processing link. And comprehensively analyzing the first safety information and the second safety information, if a malicious code node exists in the link information of the client service call link, and then detecting that a server sensitive resource is requested from the link information of the server service request processing link, namely judging that the first safety information meets a first preset safety condition and the second safety information meets a second preset safety condition, thereby intercepting the service request. It will be appreciated that the manner in which malicious code nodes are identified and whether sensitive resources are requested is varied, and may be identified, for example, by matching a pre-configured white list or black list, and will not be described in any greater detail herein.
In another optional embodiment, the first security information includes link information of the service invocation link, and the second security information includes feature information of a second key link node preset in the service request processing link. Taking the case that a scenario in which a user mobile phone needs to be protected from being stolen by trojan horse, the second key link node may include a sensitive interface predefined by the server, and the characteristic information may include a request parameter of the interface, at this time, link information of a service call link in the user client and the request parameter of the sensitive interface predefined in the server need to be analyzed. If the link of the client contains the node of the malicious program and the parameter inquired by the sensitive interface of the server is certain specific high-sensitive information, the first safety information is judged to meet the first preset safety condition, and the second safety information meets the second preset safety condition, so that the service request initiated by the client is determined to have risk and needs to be further intercepted.
For example, in an application scenario, a scenario that a trojan horse is installed on a mobile phone of a user to steal user funds and transfer the user funds to an attacker needs to be prevented and controlled. At this time, the client needs a hook server to request a sending interface, in the process of initiating a transfer request to the server, link information and sent parameters of the whole service call link are collected to be used as first safety information, the server needs a hook fund transfer transaction interface, and in the process of receiving and processing the transfer request, transfer information such as a payee, an amount and the like is collected to be used as second safety information. If the first safety information and the second safety information are comprehensively analyzed, a node containing a malicious program in a link of the client is detected, and meanwhile, the other side of the transfer of the server side is a stranger, namely, the receiver is detected not to be in a preset associated account list, the condition that the transfer request initiated by the client side has risk is judged, and the transfer request needs to be intercepted.
It can be understood that, in order to collect the first security information during the process of initiating the service request by the client and collect the second security information during the process of receiving and processing the service request by the server, it is necessary to perform hook on the call of the first key function in the client and perform hook on the call of the second key function in the server in advance. And correspondingly acquiring the first safety information and the second safety information respectively in a hook piling mode. Of course, in addition to the hook function, in other embodiments of the present disclosure, other piling manners may be adopted, and are not limited herein.
Specifically, a first key function of the client and a second key function of the server are predefined according to an object to be protected in an actual application scenario of the scheme. For example, if information related to privacy of a user is desired to be protected, the key function is an interface for acquiring a user location, an address book, and the like; if we want to protect the server interface from crawling, the key function is the function that initiates the server query.
Taking the case that a situation that a Trojan horse is installed on a mobile phone of a user to steal user sensitive information needs to be prevented and controlled, a hook server side is required by a client side to request a sending interface, and a hook sensitive information inquiry interface is required by a server side. Taking the situation that a Trojan horse is installed on a mobile phone of a user to steal user funds and transfer the funds to an attacker for prevention and control as an example, a client needs a hook server to request a sending interface, and a server needs a hook fund transfer transaction interface.
Further, after determining whether the service request is at risk according to the first security information and the second security information, the server may further be configured to: and if the service request is determined to have risks, intercepting the service request.
In this embodiment, after receiving the service request, the server may send the second security information acquired in the service request processing link to the unified security management and control layer in real time, where the unified security management and control layer analyzes the first security information and the second security information in real time, and when it is determined that the service request is at risk, if the server has not processed the service request, the server stops processing the service request, and does not respond to the service request, and returns error information, and if the server has processed the service request, the server does not respond to the service request, and returns error information.
Of course, in other embodiments of this specification, the unified security management and control layer may also analyze the first security information and the second security information after the service request is processed and all the second security information is acquired, if it is determined that the service request has a risk, the unified security management and control layer does not respond to the service request and returns error information, and if it is determined that the service request has no risk, the unified security management and control layer responds to the service request.
The risk detection system provided in the embodiment of the present specification determines whether a risk exists in a service request by comprehensively analyzing first security information of a client service call link and second security information of a server service request processing link, so as to implement full-link risk prevention and control on the service request, effectively detect a risk caused by linkage between the client and the server, and facilitate more comprehensive risk prevention and control on the client, such as a mobile APP and an IoT device.
In a second aspect, embodiments of the present specification provide a risk detection method, as shown in fig. 4, the method includes at least the following steps S401 to S403.
Step S401, a client initiates a service request, collects first safety information of a service call link passing through the process from the initiation to the sending of the service request, and sends the service request and the first safety information to a server.
Wherein the first security information includes: the link information of the service call link and/or the characteristic information of a first key link node preset in the service call link.
Step S402, the server processes the received service request and collects the second safety information of the processing link of the service request.
Wherein the second security information includes: link information of a processing link of the service request, and/or characteristic information of a second key link node preset in the processing link.
Step S403, the server determines whether the service request is risky according to the first security information and the second security information.
It should be noted that, in this embodiment of the present specification, specific implementation processes of step S401 to step S403 may refer to related descriptions in the system embodiment provided in the first aspect, and are not described herein again.
In an alternative embodiment, the first security information is collected by an end security section set in the client; the second safety information is collected by a cloud safety tangent plane arranged in the server. Specifically, reference may be made to corresponding descriptions in the foregoing system embodiments, which are not described herein again.
In an alternative embodiment, before performing step S401, the risk prevention and control method provided in this embodiment further includes: carrying out hook on the call of a first key function in the client to acquire first safety information; and carrying out hook on the call of a second key function in the server so as to acquire the second safety information. The server is a business server corresponding to the client. Specifically, reference may be made to corresponding descriptions in the foregoing system embodiments, which are not described herein again.
In an optional embodiment, after performing step S403, the risk detection method provided in this embodiment further includes: and if the server determines that the service request has risks, intercepting the service request. Specifically, reference may be made to corresponding descriptions in the foregoing system embodiments, which are not described herein again.
In a third aspect, embodiments of the present specification provide a risk detection method, as shown in fig. 5, the method includes at least the following steps S501 to S503.
Step S501, acquiring first safety information of a service call link which passes through a process from the initiation to the sending of the service request by the client.
The client collects first safety information of a service call link passing through the process from initiation to sending of a service request, and sends the collected first safety information to the target server while sending the service request to the server. In this embodiment, the target server may be a service server corresponding to the client and providing a corresponding service for the user, or may also be a security server configured in addition.
In the embodiment of the present specification, the service request is determined according to a service scenario of an actual application, and may be, for example, a transfer request, a login request, or a payment request. The service call link refers to a call link from the initiation to the sending of the service request at the client, and includes all link nodes through which the service request is sent from the initiation to the final sending. In this implementation, the link nodes are all code nodes, such as interfaces or methods that pass through from the initiation of the service request to the final sending. In this embodiment, the first security information may include: the service calls the link information of the link; and/or the characteristic information of the first key link node preset in the service call link, which is determined according to the actual application scenario of the scheme. Specifically, reference may be made to corresponding descriptions in the foregoing system embodiments, which are not described herein again.
Step S502, obtaining the second safety information of the processing link of the service request in the service terminal.
It can be understood that the server described in step S502 is a service server, corresponds to a client, and provides a service for a user. And after receiving the service request sent by the client, the service server processes the service request so as to respond to the service request. And the service server collects second safety information of a service request processing link in the process of receiving and processing the service request. The service request processing link is a link which passes from the process of receiving the service request to the process of processing the service request, and comprises all link nodes which pass through the process of receiving the service request.
In this embodiment, the second security information may include: the service request processes the link information of the link; and/or the characteristic information of a second key link node preset in the service request processing link is determined according to the actual application scene of the scheme. In a specific implementation process, the link information of the service request processing link may include: the service request may specifically include, from the received all link nodes through which the processing is completed: an identification of each link node and a record of call behavior information. Specifically, reference may be made to corresponding descriptions in the foregoing system embodiments, which are not described herein again.
Further, if the target server is the service server, the collected second security information is sent to a unified security management and control layer disposed in the service server, and the unified security management and control layer performs the following step S503 to perform comprehensive analysis on the first security information of the client and the second security information of the server. The unified security management and control layer belongs to security services specially arranged in the business server and is logically decoupled from the business services. If the target server is a security server configured additionally, the service server sends the collected second security information to the security server, and after receiving the first security information reported by the client and the second security information reported by the server, the security server executes the following step S503.
Step S503, determining whether the service request is risky according to the first security information and the second security information.
It should be noted that, in this embodiment of the present specification, specific implementation processes of step S501 to step S503 may refer to related descriptions in the system embodiment provided in the first aspect, and are not described herein again.
In an optional embodiment, the determining whether the service request is at risk according to the first security information and the second security information includes: and if the first safety information meets a first preset safety condition and the second safety information meets a second preset safety condition, judging that the service request has risks, wherein the first preset safety condition and the second preset safety condition are monitoring conditions for risk detection. Specifically, reference may be made to corresponding descriptions in the foregoing system embodiments, which are not described herein again.
In an alternative embodiment, the first security information is collected by an end security section set in the client; the second safety information is collected by a cloud safety tangent plane arranged in the server. Specifically, reference may be made to corresponding descriptions in the foregoing system embodiments, which are not described herein again.
In an optional embodiment, before performing step S501, the risk detection method provided in this embodiment further includes: carrying out hook on the call of a first key function in the client to acquire first safety information; and carrying out hook on the call of a second key function in the server so as to acquire the second safety information. Specifically, reference may be made to corresponding descriptions in the foregoing system embodiments, which are not described herein again.
In an optional embodiment, after performing step S503, the risk detection method provided in this embodiment further includes: and if the service request is determined to have risks, intercepting the service request. Specifically, reference may be made to corresponding descriptions in the foregoing system embodiments, which are not described herein again.
The risk detection method provided in the embodiments of the present description determines whether a risk exists in a service request by comprehensively analyzing first security information of a client service call link and second security information of a server service request processing link, so as to implement full-link risk prevention and control on the service request, effectively detect a risk caused by linkage between the client and the server, and facilitate more comprehensive risk prevention and control on the client, such as a mobile APP and an IoT device.
In a fourth aspect, based on the same inventive concept as the risk detection method in the foregoing embodiments, an embodiment of this specification further provides a risk detection apparatus, please refer to fig. 6, where the risk detection apparatus 60 includes:
a first obtaining module 610, configured to obtain first security information of a service invocation link that a client passes through from a service request initiation to a sending process, where the first security information includes: link information of the service call link and/or characteristic information of a first key link node preset in the service call link;
a second obtaining module 620, configured to obtain second security information of a processing link of the service request in a server, where the second security information includes: link information of the processing link and/or characteristic information of a second key link node preset in the processing link;
a detecting module 630, configured to determine whether the service request is risky according to the first security information and the second security information.
In an optional embodiment, the detecting module 630 is configured to determine that the service request has a risk if the first security information meets a first preset security condition and the second security information meets a second preset security condition, where the first preset security condition and the second preset security condition are both monitoring conditions for performing risk detection.
In an optional embodiment, the first security information is collected by a security-end section set in the client; the second safety information is acquired by a cloud safety section arranged in the server.
In an alternative embodiment, the risk detection device 60 further comprises: the configuration module is used for carrying out hook on the calling of a first key function in the client so as to acquire the first safety information; and carrying out hook on the call of a second key function in the server so as to acquire the second safety information.
In an alternative embodiment, the risk detection device 60 further comprises: the intercepting module 640 is configured to intercept the service request if it is determined that the service request has a risk.
The specific functions of the above devices, in which the specific functions of the respective modules have been described in detail in the embodiments of the system and method provided in this specification, will not be described in detail here, and the specific implementation process may refer to the above embodiments of the system and method.
In a fifth aspect, based on the same inventive concept as the risk detection method in the foregoing embodiments, an embodiment of the present specification further provides an electronic device, as shown in fig. 7, including a memory 704, a processor 702, and a computer program stored on the memory 704 and executable on the processor 702, where the processor 702, when executing the program, implements the steps of any embodiment of the risk detection method provided in the foregoing third aspect.
Where in fig. 7 a bus architecture (represented by bus 700) is shown, bus 700 may include any number of interconnected buses and bridges, and bus 700 links together various circuits including one or more processors, represented by processor 702, and memory, represented by memory 704. The bus 700 may also link together various other circuits such as peripherals, voltage regulators, power management circuits, and the like, which are well known in the art, and therefore, will not be described any further herein. A bus interface 705 provides an interface between the bus 700 and the receiver 701 and transmitter 703. The receiver 701 and the transmitter 703 may be the same element, i.e., a transceiver, providing a means for communicating with various other apparatus over a transmission medium. The processor 702 is responsible for managing the bus 700 and general processing, and the memory 704 may be used for storing data used by the processor 702 in performing operations.
It is to be understood that the structure shown in fig. 7 is merely an illustration, and that the electronic device provided by the embodiments of the present description may further include more or less components than those shown in fig. 7, or have a different configuration than that shown in fig. 7. The components shown in fig. 7 may be implemented in hardware, software, or a combination thereof.
In a sixth aspect, based on the same inventive concept as the risk detection method in the foregoing embodiments, the present specification further provides a computer-readable storage medium, on which a computer program is stored, which when executed by a processor implements the steps of any one of the embodiments of the risk detection method provided in the foregoing third aspect.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
The description has been presented with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the description. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all such alterations and modifications as fall within the scope of the invention.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.
Claims (14)
1. A method of risk detection, the method comprising:
acquiring first security information of a service call link passing through a client in a process from service request initiation to sending, wherein the first security information comprises: link information of the service call link and/or characteristic information of a first key link node preset in the service call link;
acquiring second security information of a processing link of the service request in a server, wherein the second security information comprises: link information of the processing link and/or characteristic information of a second key link node preset in the processing link;
and determining whether the service request has risks according to the first safety information and the second safety information.
2. The method of claim 1, the determining whether the service request is at risk according to the first security information and the second security information, comprising:
and if the first safety information meets a first preset safety condition and the second safety information meets a second preset safety condition, judging that the service request has a risk, wherein the first preset safety condition and the second preset safety condition are monitoring conditions for risk detection.
3. The method of claim 1, the first security information being collected by an end security profile set in the client; the second safety information is acquired by a cloud safety tangent plane arranged in the server.
4. The method of claim 1, wherein before the obtaining of the first security information of the service invocation link passed by the client from the initiation to the sending of the service request, the method further comprises:
carrying out hook on the call of a first key function in the client to acquire the first safety information;
and carrying out hook on the call of a second key function in the server so as to acquire the second safety information.
5. The method of claim 1, after determining whether the service request is at risk according to the first security information and the second security information, further comprising:
and if the service request is determined to have risks, intercepting the service request.
6. A method of risk detection, the method comprising:
a client initiates a service request, collects first security information of a service call link passing through the process from the initiation to the sending of the service request, and sends the service request and the first security information to a server, wherein the first security information comprises: link information of the service call link and/or characteristic information of a first key link node preset in the service call link;
the server processes the received service request and collects second safety information of a service request processing link, wherein the second safety information comprises: link information of the processing link and/or characteristic information of a second key link node preset in the processing link;
and the server determines whether the service request has risks according to the first safety information and the second safety information.
7. A risk detection device, the device comprising:
a first obtaining module, configured to obtain first security information of a service invocation link that a client passes through from a service request initiation to a sending process, where the first security information includes: link information of the service call link and/or characteristic information of a first key link node preset in the service call link;
a second obtaining module, configured to obtain second security information of a processing link of the service request in a server, where the second security information includes: link information of the processing link and/or characteristic information of a second key link node preset in the processing link;
and the detection module is used for determining whether the service request has risks according to the first safety information and the second safety information.
8. The apparatus of claim 7, the detection module to:
and if the first safety information meets a first preset safety condition and the second safety information meets a second preset safety condition, judging that the service request has a risk, wherein the first preset safety condition and the second preset safety condition are monitoring conditions for risk detection.
9. The apparatus of claim 7, the first security information is collected by an end security profile set in the client; the second safety information is acquired by a cloud safety tangent plane arranged in the server.
10. The apparatus of claim 7, further comprising:
the configuration module is used for carrying out hook on the calling of a first key function in the client so as to acquire the first safety information; and carrying out hook on the call of a second key function in the server so as to acquire the second safety information.
11. The apparatus of claim 7, further comprising:
and the interception module is used for intercepting the service request if the service request is determined to have risks.
12. A risk detection system, the system comprising: client and server, wherein:
the client is configured to initiate a service request, collect first security information of a service call link that passes through from the initiation of the service request to the sending of the service request, and send the service request and the first security information to a server, where the first security information includes: link information of the service call link and/or characteristic information of a first key link node preset in the service call link;
the server is used for processing the received service request and acquiring second safety information of a processing link of the service request; determining whether the service request is at risk according to the first security information and the second security information, wherein the second security information comprises: link information of the processing link, and/or characteristic information of a second key link node preset in the processing link.
13. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the steps of the method of any one of claims 1-5 when executing the program.
14. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010334181.7A CN111614624B (en) | 2020-04-24 | 2020-04-24 | Risk detection method, device, system and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010334181.7A CN111614624B (en) | 2020-04-24 | 2020-04-24 | Risk detection method, device, system and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111614624A true CN111614624A (en) | 2020-09-01 |
| CN111614624B CN111614624B (en) | 2022-09-13 |
Family
ID=72205058
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010334181.7A Active CN111614624B (en) | 2020-04-24 | 2020-04-24 | Risk detection method, device, system and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111614624B (en) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112463266A (en) * | 2020-12-11 | 2021-03-09 | 微医云(杭州)控股有限公司 | Execution policy generation method and device, electronic equipment and storage medium |
| CN113010892A (en) * | 2021-03-26 | 2021-06-22 | 支付宝(杭州)信息技术有限公司 | Method and device for detecting malicious behavior of small program |
| CN113221099A (en) * | 2021-05-06 | 2021-08-06 | 支付宝(杭州)信息技术有限公司 | Processing method and device for interface call request |
| CN113779578A (en) * | 2021-09-13 | 2021-12-10 | 支付宝(杭州)信息技术有限公司 | Intelligent confusion method and system for mobile terminal application |
| CN114995983A (en) * | 2022-07-11 | 2022-09-02 | 支付宝(杭州)信息技术有限公司 | Method and device for acquiring data flow link |
| CN115589307A (en) * | 2022-09-07 | 2023-01-10 | 支付宝(杭州)信息技术有限公司 | Risk monitoring method and device for distributed system |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180139332A1 (en) * | 2016-11-14 | 2018-05-17 | Alarm.Com Incorporated | Doorbell call center |
| CN108234653A (en) * | 2018-01-03 | 2018-06-29 | 马上消费金融股份有限公司 | A kind of method and device of processing business request |
| CN109003088A (en) * | 2018-06-21 | 2018-12-14 | 阿里巴巴集团控股有限公司 | A kind of business risk analysis method, device and equipment |
| CN109672545A (en) * | 2017-10-16 | 2019-04-23 | 中兴通讯股份有限公司 | A kind of method, apparatus, equipment and storage medium handling link detection message |
| CN110347501A (en) * | 2019-06-20 | 2019-10-18 | 北京大米科技有限公司 | A kind of service testing method, device, storage medium and electronic equipment |
-
2020
- 2020-04-24 CN CN202010334181.7A patent/CN111614624B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180139332A1 (en) * | 2016-11-14 | 2018-05-17 | Alarm.Com Incorporated | Doorbell call center |
| CN109672545A (en) * | 2017-10-16 | 2019-04-23 | 中兴通讯股份有限公司 | A kind of method, apparatus, equipment and storage medium handling link detection message |
| CN108234653A (en) * | 2018-01-03 | 2018-06-29 | 马上消费金融股份有限公司 | A kind of method and device of processing business request |
| CN109003088A (en) * | 2018-06-21 | 2018-12-14 | 阿里巴巴集团控股有限公司 | A kind of business risk analysis method, device and equipment |
| CN110347501A (en) * | 2019-06-20 | 2019-10-18 | 北京大米科技有限公司 | A kind of service testing method, device, storage medium and electronic equipment |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112463266A (en) * | 2020-12-11 | 2021-03-09 | 微医云(杭州)控股有限公司 | Execution policy generation method and device, electronic equipment and storage medium |
| CN113010892A (en) * | 2021-03-26 | 2021-06-22 | 支付宝(杭州)信息技术有限公司 | Method and device for detecting malicious behavior of small program |
| CN113221099A (en) * | 2021-05-06 | 2021-08-06 | 支付宝(杭州)信息技术有限公司 | Processing method and device for interface call request |
| WO2022233270A1 (en) * | 2021-05-06 | 2022-11-10 | 支付宝(杭州)信息技术有限公司 | Processing method and apparatus for interface calling request |
| CN113779578A (en) * | 2021-09-13 | 2021-12-10 | 支付宝(杭州)信息技术有限公司 | Intelligent confusion method and system for mobile terminal application |
| WO2023035751A1 (en) * | 2021-09-13 | 2023-03-16 | 支付宝(杭州)信息技术有限公司 | Intelligent confusion for mobile terminal application |
| CN113779578B (en) * | 2021-09-13 | 2024-01-19 | 支付宝(杭州)信息技术有限公司 | Intelligent confusion method and system for mobile terminal application |
| CN114995983A (en) * | 2022-07-11 | 2022-09-02 | 支付宝(杭州)信息技术有限公司 | Method and device for acquiring data flow link |
| CN115589307A (en) * | 2022-09-07 | 2023-01-10 | 支付宝(杭州)信息技术有限公司 | Risk monitoring method and device for distributed system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111614624B (en) | 2022-09-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111614624B (en) | Risk detection method, device, system and storage medium | |
| US11469976B2 (en) | System and method for cloud-based control-plane event monitor | |
| US11271955B2 (en) | Platform and method for retroactive reclassification employing a cybersecurity-based global data store | |
| US10666686B1 (en) | Virtualized exploit detection system | |
| CN113302609B (en) | Detecting inappropriate activity in the presence of unauthenticated API requests using artificial intelligence | |
| US20190207966A1 (en) | Platform and Method for Enhanced Cyber-Attack Detection and Response Employing a Global Data Store | |
| US9015845B2 (en) | Transit control for data | |
| US11240275B1 (en) | Platform and method for performing cybersecurity analyses employing an intelligence hub with a modular architecture | |
| CN111274583A (en) | Big data computer network safety protection device and control method thereof | |
| US9900335B2 (en) | Systems and methods for prioritizing indicators of compromise | |
| CN103384888A (en) | Systems and methods for malware detection and scanning | |
| KR20150006042A (en) | Systems and methods for providing mobile security based on dynamic attestation | |
| CN103493061A (en) | Methods and apparatus for dealing with malware | |
| US8661456B2 (en) | Extendable event processing through services | |
| Liu et al. | MR-Droid: A scalable and prioritized analysis of inter-app communication risks | |
| CN105631334A (en) | Application security detecting method and system | |
| US20210382986A1 (en) | Dynamic, Runtime Application Programming Interface Parameter Labeling, Flow Parameter Tracking and Security Policy Enforcement | |
| CN105631312A (en) | Method and system for processing rogue programs | |
| US20190199751A1 (en) | Shadow IT Discovery Using Traffic Signatures | |
| Park et al. | Performance evaluation of open-source endpoint detection and response combining google rapid response and osquery for threat detection | |
| CN111316272A (en) | Advanced cyber-security threat mitigation using behavioral and deep analytics | |
| US10628591B2 (en) | Method for fast and efficient discovery of data assets | |
| GB2542140B (en) | Controlling access to web resources | |
| US10938849B2 (en) | Auditing databases for security vulnerabilities | |
| CN113709136B (en) | Access request verification method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |