Risk interface identification method and device of application system and computing equipment

Abstract

The embodiment of the invention provides a risk interface identification method and device for an application system and computing equipment, and the method comprises the steps: determining front risk information, and obtaining a business scene log corresponding to the front risk information from business logs of the application system; generating a service search index according to the service scene log; acquiring a traffic access log of the application system; and querying the service search index in the traffic access log, and determining a target risk interface. By associating the traffic access log in the operation process of the application system with the service scene log, comprehensive risk identification and traceability investigation can be performed on the interface in the application system based on the dynamic operation condition of the application system, and each target risk interface corresponding to the pre-risk information in the application system can be inquired based on the multi-dimensional log data association. And the accuracy and comprehensiveness of risk interface identification are improved.

Description

Technical Field

[0001] The embodiments of the present specification relate to the field of computer technology, and more particularly to a method, apparatus, and computing device for identifying risk interfaces of an application system. Background Art

[0002] With the rapid development of computer technology and Internet technology, online business activities are becoming more and more frequent. Various application systems can implement corresponding business processes by calling interfaces. With the explosive growth in the number of interfaces, interfaces for various new business capabilities are also constantly emerging. Various interfaces in application systems also face many security issues, increasing network security risks.

[0003] In the prior art, based on the functional description of each interface in the application system and with the help of expert experience, it can be judged whether the corresponding interface has a certain type of risk problem. However, since different interfaces may have the same text description, but not necessarily the same functions, and the static interface description does not represent the actual situation during its operation, the accuracy of risk interface identification is low; in addition, not every interface has a functional description, so it is difficult to achieve comprehensive risk identification and traceability, resulting in poor comprehensiveness of risk interface identification. Therefore, there is an urgent need for a more accurate and comprehensive risk interface identification solution for application systems. Summary of the invention

[0004] In view of this, an embodiment of this specification provides a method for identifying a risk interface of an application system. One or more embodiments of this specification also relate to a risk interface identification device of an application system, a computing device, a computer-readable storage medium, and a computer program product to solve the technical defects existing in the prior art.

[0005] According to a first aspect of an embodiment of this specification, a method for identifying a risk interface of an application system is provided, comprising: Determine the pre-risk information, and obtain the business scenario log corresponding to the pre-risk information in the business log of the application system; Generate a business search index according to the business scenario log; Obtaining traffic access logs of the application system; The business search index is queried in the traffic access log to determine the target risk interface.

[0006] According to a second aspect of an embodiment of this specification, there is provided a risk interface identification device for an application system, comprising: A first determination module is configured to determine pre-risk information and obtain a business scenario log corresponding to the pre-risk information from a business log of the application system; A generating module, configured to generate a business search index according to the business scenario log; An acquisition module is configured to acquire the traffic access log of the application system; The second determination module is configured to query the business search index in the traffic access log to determine the target risk interface.

[0007] According to a third aspect of an embodiment of this specification, a computing device is provided, including: Memory and processor; The memory is used to store computer executable instructions, and the processor is used to execute the computer executable instructions. When the computer executable instructions are executed by the processor, the steps of the risk interface identification method of the above-mentioned application system are implemented.

[0008] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided, which stores computer-executable instructions, and when the instructions are executed by a processor, the steps of the risk interface identification method of the above-mentioned application system are implemented.

[0009] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instruction, which, when executed by a processor, implements the steps of the risk interface identification method of the above-mentioned application system.

[0010] In an embodiment of the present specification, a method for identifying a risk interface of an application system is provided, which determines pre-risk information, obtains a business scenario log corresponding to the pre-risk information in a business log of the application system; generates a business search index based on the business scenario log; obtains a traffic access log of the application system; and queries the business search index in the traffic access log to determine a target risk interface.

[0011] One embodiment of the present specification realizes that, according to the pre-risk information, the corresponding business scenario log is obtained in the business log of the application system, the corresponding business search index is generated based on the business scenario log, and the business search index is queried in the traffic access log of the application system to determine the target risk interface corresponding to the pre-risk information. Since the traffic access behavior will eventually be reflected in the business scenario log, by querying the business search index of the traffic access log, the interfaces of each similar function can be accurately found. By associating the traffic access log of the application system operation process with the business scenario log, the interface in the application system can be comprehensively identified and traced based on the dynamic operation of the application system. Based on the multi-dimensional log data association, the target risk interfaces corresponding to the pre-risk information in the application system are queried, which improves the accuracy and comprehensiveness of risk interface identification. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 It is a flow chart of a risk interface identification method of an application system provided by an embodiment of this specification; Figure 2 It is a schematic diagram of a risk interface identification process of an application system provided by an embodiment of this specification; Figure 3 It is a process flow chart of a risk interface identification method of an application system provided by an embodiment of this specification; Figure 4 It is a structural diagram of a risk interface identification device of an application system provided by an embodiment of this specification; Figure 5 It is a structural block diagram of a computing device provided by an embodiment of this specification. DETAILED DESCRIPTION

[0013] Many specific details are described in the following description to facilitate a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the connotation of this specification, so this specification is not limited to the specific implementation disclosed below.

[0014] The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms of "a", "said" and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0015] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0016] In addition, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0017] First, the terms involved in one or more embodiments of this specification are explained.

[0018] Application Programming Interface (API): The main purpose of an API is to provide applications and developers with the ability to access a set of routines without having to access the source code or understand the details of the internal working mechanism. It is a way for software to communicate with each other. It defines the standards for how different software components interact, including the format of requests and responses, the way of calling, and the structure of data. API enables developers to use a set of simple rules to call the functions of another program without in-depth understanding of the underlying implementation details, thereby achieving modular programming and integration between systems. The software that provides the functions defined by the API is called the implementation of this API. API is an interface, so it is an abstraction.

[0019] As the scale of software becomes larger and larger, it is necessary to divide complex systems into small components. The design of programming interfaces is very important. In the practice of programming, the design of programming interfaces must first make the responsibilities of the system reasonably divided. Good interface design can reduce the mutual dependence of various parts of the system, improve the cohesion of the components, and reduce the degree of coupling between the components, thereby improving the maintainability and scalability of the system.

[0020] In this specification, a method for identifying a risk interface of an application system is provided. This specification also relates to a risk interface identification device of an application system, a computing device, and a computer-readable storage medium, which are described in detail one by one in the following embodiments.

[0021] See also Figure 1 , Figure 1 A flow chart of a risk interface identification method for an application system provided according to an embodiment of the present specification is shown, which specifically includes the following steps.

[0022] Step 102: Determine the pre-risk information, and obtain the business scenario log corresponding to the pre-risk information in the business log of the application system.

[0023] Among them, the pre-risk information refers to the risk information that has been determined and may exist in the business system, which is used to indicate the affected business scenarios. For example, the pre-risk information can be an interface with potential risks, or an interface that has been actually attacked, or a business scenario marked as high-risk.

[0024] It should be noted that the pre-risk information is a priori pre-information, which is the risk information currently determined. Subsequently, based on the pre-risk information, various interfaces in the application system with similar risks can be identified.

[0025] In actual implementation, the pre-risk information can be determined based on the set risk screening rules, wherein the set risk screening rules can refer to pre-defined rules that require comprehensive risk screening. For example, assuming that the set risk screening rules are that if a certain interface is marked as a Class A risk, a comprehensive screening is required. At this time, the interface marked as Class A risk can be determined as the pre-risk information; or, assuming that the set risk screening rules are that if a certain business scenario is marked as a high-risk scenario, the risk interface of the high-risk scenario needs to be regularly screened, so the business scenario A marked as a high-risk scenario can be determined as the pre-risk information, and the risk interface identification is performed every time the scheduled time comes.

[0026] Specifically, the pre-risk information can indicate the affected target business scenarios, that is, the pre-risk information can indicate the target business scenarios that need to be checked for risk interfaces. Therefore, the corresponding business scenario logs can be obtained from various business logs of the application system based on the pre-risk information. The business scenario log refers to a log file that records detailed information during the business operation process. These logs usually contain business-related activity records, such as user operations, system responses, transaction details, and other key business events. Subsequently, risk interface identification can be performed based on the business scenario log.

[0027] In an optional implementation of this embodiment, determining the pre-risk information includes: Obtaining an interface with a risk mark in the application system, and using the interface with the risk mark as the pre-risk information; and / or, The security log of the application system is obtained, and the attacked interface is determined based on the security log, and the attacked interface is used as the pre-risk information.

[0028] The interface may refer to an application program interface (API). The application system implements corresponding business processing flows by calling various API interfaces, and the calling conditions of various APIs may be recorded in the business scenario log.

[0029] In one implementation, interfaces with risk identification in the application system can be obtained, and interfaces with risk identification can be used as pre-risk information. In actual implementation, interfaces with potential risks can be marked with risk identification in the application system. The interface with potential risk can be an interface monitored by other third-party platforms and may have a certain type of risk in the application system, or it can also be an interface that is judged to have a certain type of risk problem based on the functional description of each interface in the application system and combined with expert experience, or it can also be an interface that may have a certain type of risk monitored in the application system, and of course it can also be a risk interface identified in the previous round using the risk interface identification method provided in the embodiments of this specification.

[0030] Specifically, risk assessment rules can be defined according to security requirements. For example, more than three consecutive login failures are considered risky behaviors. When log records that meet the risk rules are detected, the interface is marked as risky. The interfaces marked as risky and their related information are summarized into a risk report. Interfaces with risk markers are identified from the security log of the application system and processed as pre-risk information.

[0031] In another implementation, if an interface has been attacked, it means that it may be at risk, so the security log of the application system can be obtained, and the attacked interface can be determined based on the security log, and the attacked interface can be used as the pre-risk information. In actual implementation, each component of the application system (such as Web server, database server, API gateway, etc.) is configured with a detailed security log recording function to record the security information of the request, including but not limited to the request method, URL, request header, request body, response status code, response time, client IP address, etc. The log aggregation tool can be used to centralize the security logs scattered in different components and send them to a unified log storage system; the log analysis tool is used to parse the security log data and extract the key fields. Based on the extracted key fields, anomaly detection algorithms (such as baseline detection, statistical anomaly detection, machine learning models, etc.) are used to identify abnormal request patterns, such as abnormal request frequency, requests at abnormal times, requests from known malicious IP addresses, etc., and a set of rule engines are established to define a series of security rules (such as multiple consecutive failed login attempts, a large number of identical requests in a short period of time, etc.). When requests that meet these rules are detected, these requests are marked as potential attacks, and the corresponding interfaces are the attacked interfaces. Through the above steps and corresponding technical tools, the attacked interfaces can be effectively identified from the security log of the application system, and used as pre-risk information for subsequent risk interface identification.

[0032] In the embodiments of this specification, the application system can specially mark interfaces that may have certain types of risks to distinguish between interfaces that work normally and abnormal interfaces that may have risks, that is, interfaces with risk marks are interfaces that may have risks; in addition, interfaces that have been attacked are likely to have certain risks. Therefore, interfaces with risk marks in the application system can be obtained, and the interfaces with risk marks can be used as pre-risk information; and / or, interfaces that have been attacked can be used as pre-risk information, and interfaces with the same types of risks as the interfaces with risk marks and / or the interfaces that have been attacked can be subsequently checked. In this way, the pre-risk information can be determined in a variety of ways, with relatively comprehensive coverage, and risk interfaces of the same type can be identified in a timely manner.

[0033] Of course, in actual implementation, the pre-risk information may include not only the interfaces with risk identification and / or the interfaces that have been attacked, but also high-risk or set business scenario identification, etc., and the embodiments of this specification do not limit this.

[0034] In an optional implementation of this embodiment, the pre-risk information is a potential risk interface determined to have a risk; and obtaining a business scenario log corresponding to the pre-risk information in a business log of the application system includes: Obtaining the interface identifier of the potential risk interface; Querying the asset ownership of the potential risk interface according to the interface identifier, wherein the asset ownership is used to indicate the target business scenario to which the potential risk interface belongs; According to the asset attribution, the business scenario log of the attributable target business scenario is obtained from the business log of the application system.

[0035] An interface identifier is a specific information used to uniquely identify an interface in a computer system, network application, or software architecture. Interface identifiers can help developers, maintenance personnel, and security experts quickly locate and manage specific interfaces, which is especially important in large systems with a large number of interfaces and high complexity.

[0036] Common forms of interface identification include URL path, port number, method name, interface name, Universally Unique Identifier (UUID) or Globally Unique Identifier (GUID), label or comment, version number, etc. Among them, in Web applications, API interfaces are usually identified by URL path, for example, " / v1 / users" in https: / / api.example.com / v1 / users is an interface identifier. In TCP / IP networks, port numbers can be used as one of the identifiers of interfaces. For example, HTTP services use port 80 by default, and HTTPS services use port 443 by default. In object-oriented programming, the method name of a class can also be used as an interface identifier. In some frameworks or libraries, the interface name can also be directly defined as an identifier. For example, in the .NET framework, an interface named IUserService can be defined. Universally Unique Identifier (UUID) or Globally Unique Identifier (GUID) can also be used as an interface identifier, especially in distributed systems. In some frameworks or tools, you can add an identifier to the interface through labels or comments to facilitate subsequent search and management. In API version management, the version number is also an important identifier. For example, / v1 / and / v2 / represent two different versions of API interfaces.

[0037] The interface asset ownership can indicate which business system and business scenario the interface belongs to. By querying the asset ownership of a potential risk interface through the interface identifier, you can determine which business system and business scenario the potential risk interface belongs to. This is usually used in interface management and maintenance work to help the team quickly locate the person in charge of the interface, the system to which it belongs, and the application scenario.

[0038] It should be noted that if the prior risk information is a potential risk interface that has been determined to be at risk, then the interface identifier of the potential risk interface can be obtained, and the asset ownership of the potential risk interface can be queried based on the interface identifier. Based on the asset ownership, the target business scenario to which the potential risk interface belongs can be indicated, thereby obtaining the business scenario log of the target business scenario from various business logs of the application system.

[0039] In actual implementation, the server or storage can record the asset details of the application system, including various software components including interfaces, record the interface identifier, interface description, business system, business scenario and other key information of each interface, and support searching by interface identifier. Specifically, a database table containing fields such as interface identifier, system name, business scenario, etc. can be designed, and a relational database (such as MySQL, PostgreSQL) or NoSQL database (such as MongoDB) can be used to store this information. After obtaining the interface identifier of the potential risk interface, the matching business system, business scenario and other information can be searched in the recorded asset details to determine the target business scenario to which the interface identifier belongs. Specifically, the search function of the interface identifier can be implemented using SQL query statements or NoSQL query languages.

[0040] For example, assuming that the interface identifier of the potential risk interface to be queried is " / api / v1 / user / login", search for records matching " / api / v1 / user / login" in the recorded asset details, and obtain that the system to which it belongs is the user management system, and the business scenario is user login verification. Then, it can be determined that the target business scenario to which the potential risk interface belongs is the user login verification scenario under the user management system, and the business scenario log corresponding to the user login verification scenario can be obtained.

[0041] In actual applications, by querying the asset ownership of the potential risk interface, you can know the target business scenario to which the potential risk interface belongs, and then you can obtain the business scenario log of the target business scenario from various business logs of the application system. Specifically, you can configure a log collection tool (such as Filebeat) on the application system. The log collection tool can monitor activities and events related to the business process and collect business scenario logs under the corresponding target business scenario.

[0042] In the embodiments of the present specification, the same business scenario has different interface entries, and these interfaces may have similar risks. Therefore, when the prior risk information is a potential risk interface with risks, the affected business scenario and / or business system can be determined based on the interface identifier of the potential risk interface, and then the target business scenario to which the potential risk interface belongs can be determined. Then, the corresponding business scenario log can be collected to facilitate the subsequent search for the different interfaces under the target business scenario based on the business scenario log, thereby achieving comprehensive and accurate risk interface identification.

[0043] Step 104: Generate a business search index according to the business scenario log.

[0044] Among them, search index is a data structure and technology used to improve the efficiency of information retrieval. It is widely used in various scenarios, such as search engines, database systems, content management systems, etc. Search index pre-processes and organizes data so that the required information can be quickly located when querying. Search index is a special database structure that contains index entries pointing to one or more data records. The index entries are organized according to certain rules so that relevant data can be quickly located when searching. Search index is usually used to support fast full-text search, keyword search, classification search and other functions.

[0045] A business search index refers to a data index defined to support search functions in specific business scenarios. This index is usually used to speed up data queries related to the target business scenario and improve the accuracy and relevance of the search.

[0046] It should be noted that after obtaining the business scenario log, the business scenario log records the business activities and business events related to the target business scenario, and each business activity and business event is implemented through the corresponding interface, so the business scenario log records each interface related to the target business scenario. A business search index can be generated based on the business scenario log, so that subsequent searches and investigations can be performed in other related logs based on the business search index to identify risk interfaces of the same type.

[0047] In an optional implementation of this embodiment, generating a business search index according to the business scenario log includes: Parsing the business scenario log to obtain key business information in the business scenario log; The business search index is generated based on the business key information.

[0048] Among them, the business-critical information is the information of the key fields corresponding to the target business scenario in the business scenario log, and the business-critical information is the information that appears in both the business scenario log and the traffic access log.

[0049] In actual implementation, parsing rules can be defined according to the target business scenario, such as extracting key business information such as business serial number, business ID, operation type, user ID, etc. in the log; then, a script can be written based on the set plug-in or programming language to extract the required fields defined by the parsing rules from the business scenario log, and the extracted fields can be used as the key business information.

[0050] In addition, the index tool can also define index mapping based on the target business scenario, specify the field type and storage method of the business search index, import the acquired business key information into the index tool, and the index tool can automatically generate the business search index based on the imported business key information, and use the API provided by the index tool to build and manage the index. The index tool can be any tool that can implement index building and management, such as Elasticsearch.

[0051] In the embodiments of this specification, key information can be extracted from the business scenario log, and then this information can be used to build an efficient index to support subsequent fast and accurate searches, thereby significantly improving the interface query efficiency for similar risks and quickly and comprehensively troubleshooting risk interfaces.

[0052] In an optional implementation of this embodiment, the key information includes a business serial number; and the parsing of the business scenario log to obtain the business key information in the business scenario log includes: Determine a set log format for the business scenario log; The business scenario log is parsed according to the set log format, and the business serial number is extracted from the business scenario log according to the set storage position of the business serial number defined in the set log format.

[0053] Among them, the business transaction ID (Business Transaction ID or Business Sequence Number) is a number used to uniquely identify a business operation during the business processing process. It plays an important role in various business scenarios, especially in the fields of financial transactions, e-commerce, logistics management, etc. The business serial number usually contains enough information to ensure that each business operation can be uniquely identified in the huge transaction data. The business serial number can ensure that each business operation is unique, avoid duplication or omission, and facilitate tracing the entire process of business operations and finding the cause when problems occur; and it can also be used to monitor system performance and business processes, and analyze business operation patterns. In addition, the business serial number is generally recorded in the business scenario log to facilitate the analysis of the corresponding business operation and problem location.

[0054] Log format refers to the standard structure for recording event information generated during the operation of an application system, application, or other component. Different application systems and different applications may have different log formats, but most logs will contain some basic elements, such as timestamp, event level, message content, business serial number, business information, etc. Understanding the log format is crucial for log parsing, storage, and analysis. Common log formats can include plain text format, structured log format, custom format, etc.

[0055] It should be noted that different logs can be defined with different log formats. Therefore, the set log format of the business scenario log can be determined, and then the business scenario log can be parsed according to the set log format. The set log format defines a set storage location for the business serial number, and the business serial number in the business scenario log is read from the set storage location. The business serial number is used as the key business information to generate a business search index. In other words, the risk interface can be laterally checked based on the business serial number to check for interfaces with similar risk problems.

[0056] In actual implementation, you can first use the log collection tool to collect the business scenario log of the target business scenario; then, use the log parsing tool to define the parsing rules and write the parsing script to parse the business scenario log according to the set log format of the business scenario log to obtain the specific content of the log; then, you can use a plug-in or programming language to define a field extraction tool to extract the business serial number field from the defined set storage location.

[0057] In the embodiments of the present specification, the business serial number can uniquely identify a business operation. A business operation can be implemented by multiple interfaces with the same or different functions. These multiple interfaces with the same or different functions may have the same type of risks. Therefore, the business serial number can facilitate subsequent investigation of interfaces with the same type of risks and realize horizontal investigation. By parsing the business scenario log corresponding to the previous risk information, the business serial number can be obtained. The business serial number can be used as a search index for query to determine the various interfaces under the search index, thereby realizing comprehensive and accurate identification of interfaces with the same type of risks.

[0058] Step 106: Obtain the traffic access log of the application system.

[0059] Among them, traffic access logs (Access Logs) are log files that record the details of each visit to a website, system or service. These logs contain detailed information about client requests, including but not limited to access time, client IP address, requested URL, HTTP method, HTTP status code, response size, and user agent. Traffic access logs are of great significance for monitoring system performance, detecting security threats, and optimizing user experience.

[0060] Traffic access logs can be in a variety of formats, such as Common Log Format (CLF) and Extended Log Format (ELF). ELF is also called Combined Log Format. CLF is a simple text format that records the most basic access information, such as the client's IP address or host name, the time of the request (usually local time), the request line (including the request method, the requested resource path and HTTP version), the HTTP status code, the number of bytes sent to the client, etc. ELF or Combined Log Format adds referrer and user agent information to CLF. In addition to the fields in CLF, each line of log can also include the URL of the page that initiated the request, the user agent string, that is, the client browser identifier, etc.

[0061] In actual implementation, you can use log collection tools (such as Filebeat, Logstash) to collect traffic access logs from the Web server or other application servers of the application system.

[0062] It should be noted that each traffic access behavior in the traffic access log will access the corresponding target business scenario and be reflected in the business scenario log of the target business scenario. Therefore, the traffic access log of the application system can be obtained to associate the traffic access log and the business scenario log to achieve comprehensive and accurate identification of similar risk interfaces.

[0063] Step 108: Query the business search index in the traffic access log to determine the target risk interface.

[0064] Among them, the target risk interface is an interface that has the same type of risk issues as the previous risk information.

[0065] It should be noted that the business search index is generated based on the business scenario log of the target business scenario, so the business search index can be queried in the traffic access log, and the target risk interface can be determined based on each interface obtained by the query.

[0066] In actual implementation, you can use a log parsing tool to define parsing rules and write parsing scripts to parse the traffic access log according to the set log format of the traffic access log to obtain specific access content, and query the business search index in the specific access content to obtain the corresponding interfaces. The interfaces obtained by the query are interfaces corresponding to the target business scenario. The target business scenario is determined based on the prior risk information. Therefore, the interfaces obtained by the query may have the same type of risk issues as the prior risk information. The query results based on the business search index in the traffic access log can determine the target risk interface, and implement interface troubleshooting for similar risk issues.

[0067] In an optional implementation of this embodiment, the querying the service search index in the traffic access log to determine the target risk interface includes: Querying the business search index in the request data and response data of the traffic access log to obtain at least one candidate risk interface; Perform risk verification on the at least one candidate risk interface to determine the target risk interface.

[0068] Among them, request data and response data are HTTP request and response data, which are the basic components of Web communication. They define the interaction between the client (usually a browser) and the server. HTTP request data contains the information sent by the client to the server, mainly including the request line, request header, request body and other parts. HTTP response data contains the server's response to the client's request, mainly including the status line, response header, response body and other parts.

[0069] In specific implementation, in order to facilitate tracking of the business scenarios corresponding to access behaviors, business-critical information such as business serial numbers can be stored in the request header or request body, so as to facilitate tracking of specific business operations throughout the request-response cycle. In other words, the request data and response data in the traffic access log contain corresponding business-critical information (such as business serial numbers), and the corresponding request interface or response interface can be queried in the request data and response data of the traffic access log based on the business search index.

[0070] In actual implementation, the traffic access log may include request data and response data, which may indicate HTTP request and response behaviors. Each request and response behavior may access the corresponding business system or business scenario, which is reflected in the corresponding business scenario log. The business search index is generated based on the business scenario log, so the business search index can be queried in the request data and response data of the traffic access log. The request interface or response interface corresponding to the business search index will access the corresponding target business scenario, so the request interface or response interface may have the same type of risk issues as the pre-risk information, so the various interfaces obtained by the query can be used as candidate risk interfaces.

[0071] It should be noted that after obtaining at least one candidate risk interface, each candidate risk interface can be directly used as the target risk interface finally identified and having the same type of risk problem as the prior risk information; or, risk verification can be performed on at least one candidate risk interface to further determine the target risk interface having the same type of risk problem as the prior risk information.

[0072] In the embodiments of this specification, under normal circumstances, the same business scenario has different interface entrances, and these interfaces may have the same type of risks. The traffic access behaviors will eventually access the corresponding target business scenario. Therefore, based on the pre-risk information, for example, a certain interface has potential risks or has been actually attacked, the affected target business scenario can be determined, and then the corresponding business scenario log is collected, the serial number or other business-critical information of the target business scenario log is determined as the business search index, the traffic access log is collected, and the business search index is searched in the request data and response data of the traffic access log. Based on the API interface corresponding to the found business search index, the target risk interface with the same type of risk problem as the pre-risk information is determined. In this way, based on the business scenario log of the application system, the traffic access log during the operation of the application system is associated, and the interface is comprehensively identified and traced, and the risk interface is comprehensively and accurately identified based on the multi-dimensional log data association.

[0073] In an optional implementation of this embodiment, the performing risk verification on the at least one candidate risk interface to determine the target risk interface includes: Pushing the at least one candidate risk interface to a verification personnel; receiving a verification result fed back by the verification personnel for the at least one candidate risk interface; The candidate risk interface among the at least one candidate risk interface, for which the verification result indicates that there is a risk, is used as the target risk interface.

[0074] The verification personnel are the staff responsible for verifying whether there are any risk issues in the interface. Different verification personnel can be pre-configured for different types of risks.

[0075] It should be noted that since a business scenario needs to be implemented based on multiple interfaces with the same or different functions, the request interface and access interface queried in the request data and response data of the traffic access log based on the business search index may have the same type of risk issues as the previous risk information, but may also not contain any risks.

[0076] Therefore, in actual implementation, after querying at least one candidate risk interface, at least one candidate risk interface can be pushed to the verification personnel, who will further determine whether each candidate risk interface is determined to have risks in combination with other monitoring rules and prior experience, and feedback the corresponding verification results for each candidate risk interface. Among them, the verification result is used to indicate whether the corresponding candidate risk interface has risk problems after verification, such as the verification result can include risk and no risk, or can also be passed and failed verification, passing the verification means that the corresponding candidate risk interface has risk problems, and failing the verification means that the corresponding candidate risk interface does not have risk problems.

[0077] Specifically, the risk type of the pre-risk information can be determined, and the corresponding verification personnel can be determined according to the risk type, and at least one candidate risk interface can be pushed to the verification personnel. In an optional implementation, the at least one candidate risk interface can be pushed to the verification personnel's system account to generate a verification task; in another implementation, the at least one candidate risk interface can also be pushed to the verification personnel's user terminal via email, Bluetooth or other data synchronization methods.

[0078] It should be noted that the verification personnel can perform risk verification on each candidate risk interface, and feedback the corresponding verification results, and use the candidate risk interface whose verification results indicate that there is a risk as the target risk interface finally identified.

[0079] In the embodiments of this specification, based on the business scenario log of the application system and the traffic access log during the operation of the application system, the interface is comprehensively identified and traced back to the source, and after at least one candidate risk interface is identified, each candidate risk interface can be further pushed to the corresponding risk verification personnel, and the risk verification personnel will further determine whether there is a risk. Based on the business scenario log of the application system and the traffic access log during operation, the candidate risk interface queried is used as the basis for comprehensive risk identification and traceability, and then manually confirmed whether there is indeed a risk problem, which further ensures the accuracy of risk interface identification.

[0080] In an optional implementation of this embodiment, after querying the service search index in the traffic access log and determining the target risk interface, the method further includes: Determining the target risk type indicated by the pre-risk information; The target risk interface is marked as the target risk type.

[0081] In actual implementation, the target risk interface is determined by querying the traffic access log of the application system based on the business scenario log corresponding to the prior risk information. Therefore, the target risk interface may have the same type of risk issues as the prior risk information. Therefore, the target risk type indicated by the prior risk information can be determined, and then the target risk interface can be marked as the target risk type.

[0082] It should be noted that the identified target risk tag can be marked with the same risk tag as the previous risk information, and the same risk tag can be assigned to the newly identified risk interface based on the known risk information (previous risk information), so as to achieve horizontal troubleshooting of risk issues and classify the same type of risk interfaces together, which is convenient for subsequent unified monitoring and management of similar risk issues, thereby better preventing potential risks and improving the overall security of the system.

[0083] For example, Figure 2 is a schematic diagram of a risk interface identification process of an application system provided by an embodiment of this specification, such as Figure 2 As shown, users can access the corresponding application system based on their own terminal devices. The application system is configured with multiple API interfaces, which can implement business operations in different business scenarios. Determine the pre-risk information (such as potential risk interfaces that may have risks, or interfaces that have been actually attacked), determine the target business scenario to which it belongs based on the pre-risk information, collect the business scenario log of the target business scenario, and extract the business serial number from the business scenario log as the business search index. Obtain the HTTP traffic access log of the application system operation process, query the business serial number in the HTTP request data and response data in the HTTP traffic access log, and if the corresponding request interface or response interface is queried, push the interfaces obtained from the query to the verification personnel. Based on the verification results fed back by the verification personnel, the candidate risk interface indicating the risk is used as the final identified target risk interface, and mark the target risk interface with the same type of risk mark as the pre-risk information.

[0084] In the embodiments of this specification, a method for identifying risk interfaces of an application system is provided. Under normal circumstances, the same business scenario has different interface entrances, and these interfaces may have the same type of risks. Each traffic access behavior will eventually access the corresponding target business scenario. Therefore, according to the pre-risk information, the corresponding business scenario log can be obtained from various business logs of the application system, and the corresponding business search index can be generated based on the business scenario log. The business search index is queried in the traffic access log of the application system to determine the target risk interface corresponding to the pre-risk information. Since the traffic access behavior will eventually be reflected in the business scenario log, by querying the business search index of the traffic access log, the interfaces of each similar function can be accurately found. By associating the business scenario log with the traffic access log, the interfaces in the application system can be comprehensively identified and traced based on the dynamic operation of the application system. Based on the multi-dimensional log data association, the target risk interfaces corresponding to the pre-risk information in the application system can be horizontally checked, which improves the accuracy and comprehensiveness of risk interface identification.

[0085] The following combination Figure 3 Taking the application of the risk interface identification method of the application system provided in this specification in the scenario of MyBank as an example, the risk interface identification method of the application system is further explained. Figure 3 A process flow chart of a risk interface identification method for an application system provided in an embodiment of the present specification is shown, which specifically includes the following steps.

[0086] Step 302: The user accesses the MyBank application based on the terminal device he holds. The MyBank application is configured with multiple API interfaces, and the multiple API interfaces can implement business operations in different business scenarios.

[0087] Step 304: Obtain interfaces with risk identification in the MYbank application, and use the interfaces with risk identification as pre-risk information; and / or, obtain the security log of the MYbank application, determine the interfaces that have actually been attacked based on the security log, and use the interfaces that have actually been attacked as pre-risk information.

[0088] Step 306: query the target business scenario to which the interface identifier of the pre-risk information belongs, collect the business scenario log of the target business scenario, and extract the business serial number from the business scenario log as the business search index.

[0089] Step 308: Obtain the HTTP traffic access log during the operation of the MyBank application.

[0090] Step 310: Query the service serial number in the HTTP request data and response data in the HTTP traffic access log.

[0091] Step 312: If the corresponding request interface or response interface is found, each interface obtained by the search is pushed to the verification personnel.

[0092] Step 314: Based on the verification results fed back by the verification personnel, the candidate risk interface indicating the existence of risks is used as the target risk interface identified in the MyBank application, and the target risk interface is marked with a risk tag of the same type as the previous risk information.

[0093] The embodiments of this specification provide a method for identifying risk interfaces of an application system. Since the traffic access behavior in the MYbank application will eventually be reflected in the corresponding business scenario log, by querying the business serial number of the traffic access log of the MYbank application, the interfaces of the same functions can be accurately found. By associating the traffic access log of the MYbank application operation process with the business scenario log, the interfaces in the MYbank application can be comprehensively identified and traced based on the dynamic operation of the MYbank application. Based on the multi-dimensional log data association, the target risk interfaces in the MYbank application corresponding to the pre-risk information can be horizontally checked, thereby improving the accuracy and comprehensiveness of risk interface identification.

[0094] Corresponding to the above method embodiment, this specification also provides a risk interface identification device embodiment of the application system, Figure 4 FIG. 1 is a schematic diagram showing a structure of a risk interface identification device of an application system provided by an embodiment of the present specification. Figure 4 As shown, the device comprises: The first determination module 402 is configured to determine the pre-risk information and obtain the business scenario log corresponding to the pre-risk information in the business log of the application system; A generating module 404 is configured to generate a business search index according to the business scenario log; The acquisition module 406 is configured to acquire the traffic access log of the application system; The second determination module 408 is configured to query the service search index in the traffic access log to determine a target risk interface.

[0095] Optionally, the first determining module 402 is configured to: Obtaining an interface with a risk mark in the application system, and using the interface with the risk mark as the pre-risk information; and / or, The security log of the application system is obtained, and the attacked interface is determined based on the security log, and the attacked interface is used as the pre-risk information.

[0096] Optionally, the pre-risk information is a potential risk interface determined to have a risk; the first determination module 402 is configured to: Obtaining the interface identifier of the potential risk interface; Querying the asset ownership of the potential risk interface according to the interface identifier, wherein the asset ownership is used to indicate the target business scenario to which the potential risk interface belongs; According to the asset attribution, the business scenario log of the attributable target business scenario is obtained from the business log of the application system.

[0097] Optionally, the generating module 404 is further configured to: Parsing the business scenario log to obtain key business information in the business scenario log; The business search index is generated based on the business key information.

[0098] Optionally, the key information includes a business serial number; the generating module 404 is further configured to: Determine a set log format for the business scenario log; The business scenario log is parsed according to the set log format, and the business serial number is extracted from the business scenario log according to the set storage position of the business serial number defined in the set log format.

[0099] Optionally, the second determining module 408 is configured to: Querying the business search index in the request data and response data of the traffic access log to obtain at least one candidate risk interface; Perform risk verification on the at least one candidate risk interface to determine the target risk interface.

[0100] Optionally, the second determining module 408 is configured to: Pushing the at least one candidate risk interface to a verification personnel; receiving a verification result fed back by the verification personnel for the at least one candidate risk interface; The candidate risk interface among the at least one candidate risk interface, for which the verification result indicates that there is a risk, is used as the target risk interface.

[0101] Optionally, the device further includes a marking module configured to: Determining the target risk type indicated by the pre-risk information; The target risk interface is marked as the target risk type.

[0102] The embodiment of this specification provides a risk interface identification device for an application system, including a first determination module, a generation module, an acquisition module, and a second determination module. Through the interaction of the modules in the risk interface identification device of the application system, the corresponding business scenario logs can be obtained from various business logs of the application system according to the pre-risk information, and the corresponding business search index can be generated based on the business scenario log. The business search index is queried in the traffic access log of the application system to determine the target risk interface corresponding to the pre-risk information. Since the traffic access behavior will eventually be reflected in the business scenario log, by querying the business search index of the traffic access log, the interface of each similar function can be accurately found. By associating the traffic access log of the application system operation process with the business scenario log, the interface in the application system can be comprehensively identified and traced based on the dynamic operation of the application system. Based on the multi-dimensional log data association, the target risk interfaces corresponding to the pre-risk information in the application system can be queried, thereby improving the accuracy and comprehensiveness of risk interface identification.

[0103] The above is a schematic scheme of a risk interface identification device for an application system of this embodiment. It should be noted that the technical scheme of the risk interface identification device for the application system and the technical scheme of the risk interface identification method for the above-mentioned application system belong to the same concept, and the details not described in detail in the technical scheme of the risk interface identification device for the application system can be found in the description of the technical scheme of the risk interface identification method for the above-mentioned application system.

[0104] Figure 5 The block diagram of a computing device according to an embodiment of the present specification is shown. The components of the computing device 500 include but are not limited to a memory 510 and a processor 520. The processor 520 is connected to the memory 510 via a bus 530, and the database 550 is used to store data.

[0105] The computing device 500 also includes an access device 540 that enables the computing device 500 to communicate via one or more networks 560. Examples of these networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or a combination of communication networks such as the Internet. The access device 540 may include one or more of any type of network interface (e.g., a network interface card (NIC)) that is wired or wireless, such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a world-wide interoperability for microwave access (Wi-MAX) interface, an Ethernet interface, a universal serial bus (USB) interface, a cellular network interface, a Bluetooth interface, and a near field communication (NFC).

[0106] In one embodiment of the present specification, the above components of the computing device 500 and Figure 5 Other components not shown in the figure may also be connected to each other, for example, via a bus. It should be understood that Figure 5 The computing device structure block diagram shown is only for the purpose of illustration, and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0107] The computing device 500 may be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook, etc.), a mobile phone (e.g., a smart phone), a wearable computing device (e.g., a smart watch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or a personal computer (PC). The computing device 500 may also be a mobile or stationary server.

[0108] The processor 520 is used to execute the following computer executable instructions, which, when executed by the processor, implement the steps of the risk interface identification method of the above-mentioned application system.

[0109] The above is a schematic scheme of a computing device of this embodiment. It should be noted that the technical scheme of the computing device and the technical scheme of the risk interface identification method of the above-mentioned application system belong to the same concept. For details not described in detail in the technical scheme of the computing device, please refer to the description of the technical scheme of the risk interface identification method of the above-mentioned application system.

[0110] An embodiment of the present specification also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the steps of the risk interface identification method of the above-mentioned application system.

[0111] The above is a schematic scheme of a computer-readable storage medium of this embodiment. It should be noted that the technical scheme of the storage medium and the technical scheme of the risk interface identification method of the above-mentioned application system belong to the same concept, and the details not described in detail in the technical scheme of the storage medium can be referred to the description of the technical scheme of the risk interface identification method of the above-mentioned application system.

[0112] An embodiment of the present specification also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the risk interface identification method of the above-mentioned application system.

[0113] The above is a schematic scheme of a computer program product of this embodiment. It should be noted that the technical scheme of the computer program product and the technical scheme of the risk interface identification method of the above-mentioned application system belong to the same concept. For details not described in detail in the technical scheme of the computer program product, please refer to the description of the technical scheme of the risk interface identification method of the above-mentioned application system.

[0114] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0115] The computer instructions include computer program codes, which may be in source code form, object code form, executable files or some intermediate forms, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content contained in the computer-readable medium may be appropriately increased or decreased according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0116] It should be noted that, for the above-mentioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of this specification are not limited by the order of the actions described, because according to the embodiments of this specification, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the embodiments of this specification.

[0117] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0118] The preferred embodiments of this specification disclosed above are only used to help explain this specification. The optional embodiments do not describe all the details in detail, nor do they limit the invention to only the specific implementation methods described. Obviously, many modifications and changes can be made according to the content of the embodiments of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the embodiments of this specification, so that technicians in the relevant technical field can well understand and use this specification. This specification is only limited by the claims and their full scope and equivalents.

Claims

1. A method for identifying a risk interface of an application system, comprising: Determine the pre-risk information, and obtain the business scenario log corresponding to the pre-risk information in the business log of the application system; Generate a business search index according to the business scenario log; Obtaining traffic access logs of the application system; The business search index is queried in the traffic access log to determine the target risk interface.

2. According to the risk interface identification method of the application system of claim 1, the determining of the pre-risk information comprises: Acquire an interface with a risk identifier in the application system, and use the interface with the risk identifier as the pre-risk information; and / or, The security log of the application system is obtained, and the attacked interface is determined based on the security log, and the attacked interface is used as the pre-risk information.

3. According to the risk interface identification method of the application system of claim 1, the pre-risk information is the potential risk interface determined to have risks; The obtaining the business scenario log corresponding to the pre-risk information in the business log of the application system includes: Obtaining the interface identifier of the potential risk interface; Querying the asset ownership of the potential risk interface according to the interface identifier, wherein the asset ownership is used to indicate the target business scenario to which the potential risk interface belongs; According to the asset attribution, the business scenario log of the attributable target business scenario is obtained from the business log of the application system.

4. According to the risk interface identification method of the application system of claim 1, the generating of the business search index according to the business scenario log comprises: Parsing the business scenario log to obtain key business information in the business scenario log; The business search index is generated based on the business key information.

5. According to the risk interface identification method of the application system of claim 4, the key information includes a business serial number; the parsing of the business scenario log to obtain the business key information in the business scenario log includes: Determine a set log format for the business scenario log; The business scenario log is parsed according to the set log format, and the business serial number is extracted from the business scenario log according to the set storage position of the business serial number defined in the set log format.

6. The method for identifying risk interfaces of an application system according to claim 1, wherein the step of querying the service search index in the traffic access log to determine the target risk interface comprises: Querying the business search index in the request data and response data of the traffic access log to obtain at least one candidate risk interface; Perform risk verification on the at least one candidate risk interface to determine the target risk interface.

7. The method for identifying a risk interface of an application system according to claim 6, wherein the step of performing risk verification on the at least one candidate risk interface to determine the target risk interface comprises: Pushing the at least one candidate risk interface to a verification personnel; Receiving a verification result fed back by the verification personnel for the at least one candidate risk interface; The candidate risk interface among the at least one candidate risk interface, for which the verification result indicates that there is a risk, is used as the target risk interface.

8. The method for identifying risk interfaces of an application system according to claim 1, after querying the service search index in the traffic access log and determining the target risk interface, further comprising: Determining the target risk type indicated by the pre-risk information; The target risk interface is marked as the target risk type.

9. A risk interface identification device for an application system, comprising: A first determination module is configured to determine pre-risk information and obtain a business scenario log corresponding to the pre-risk information from a business log of the application system; A generating module, configured to generate a business search index according to the business scenario log; An acquisition module is configured to acquire the traffic access log of the application system; The second determination module is configured to query the business search index in the traffic access log to determine the target risk interface.

10. A computing device comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions. When the computer program / instructions are executed by the processor, the steps of the risk interface identification method of the application system described in any one of claims 1-8 are implemented.

11. A computer-readable storage medium storing a computer program / instruction, which, when executed by a processor, implements the steps of the risk interface identification method of the application system described in any one of claims 1 to 8.

12. A computer program product, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the risk interface identification method of the application system described in any one of claims 1 to 8.

Images