Application unauthorized vulnerability detection method, device and equipment and readable storage medium

Abstract

The invention provides an application unauthorized vulnerability detection method, device and equipment and a readable storage medium, and relates to the technical field of network security, and the method comprises the steps: obtaining request execution information returned according to at least one request message in an application operation process based on an interactive application security test technology; performing message arrangement on the request message according to the request execution information; replacing the user associated information in the arranged request message with target test information to obtain a new request message; replaying the new request message for the application, and obtaining feedback information of the application; and based on the feedback information, determining whether the application has an unauthorized vulnerability. According to the scheme, the request execution flow information generated in the application running process is collected, and the request of the application is rearranged, replaced and transformed into the new request message, so that the normal operation process of a user can be simulated, automatic unauthorized vulnerability detection is realized, the detection efficiency is improved, and the detection effect of the unauthorized vulnerability of the application is improved.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular to a method, device, equipment and readable storage medium for detecting application unauthorized vulnerabilities. Background Art

[0002] Unauthorized vulnerabilities are a common business logic vulnerability in applications. Business logic vulnerabilities have long been at the top of the vulnerability rankings due to their universality, unpredictability, irregularity, and destructiveness. Unauthorized vulnerabilities are highly concealed, have low repetitiveness, and are highly differentiated.

[0003] Currently, before an information system is put into production, the detection of application unauthorized vulnerabilities mainly relies on manual penetration.

[0004] However, the existing manual detection method has the problems of incomplete detection, low efficiency, and insufficient automation, resulting in poor detection effect of application unauthorized vulnerability. Summary of the invention

[0005] The present application provides an application unauthorized vulnerability detection method, device, equipment and readable storage medium, which are used to solve the problem that the existing application unauthorized vulnerability detection effect is poor.

[0006] In a first aspect, an embodiment of the present application provides a method for detecting an application unauthorized vulnerability, including:

[0007] Based on the interactive application security testing technology, obtaining the request execution information returned according to at least one request message during the application running process;

[0008] Arrange the request message according to the request execution information;

[0009] The user-related information in the arranged request message is replaced with the target test information to obtain a new request message;

[0010] Replaying the new request message to the application to obtain feedback information of the application;

[0011] Based on the feedback information, determine whether the application has an unauthorized vulnerability.

[0012] In a possible design of the first aspect, the message orchestration includes at least one of message cleaning, session inference, and request encapsulation.

[0013] In another possible design of the first aspect, performing message cleaning on the request message includes:

[0014] Filter out the request message that meets the set filtering condition in the at least one request message, where the set filtering condition includes one or more of the following: abnormal application response, failure to meet the set request type, and failure to meet the set request behavior requirement.

[0015] In another possible design of the first aspect, after performing message cleaning on the request message, the method further includes:

[0016] Filter out irrelevant information in each request message, wherein the irrelevant information includes at least one of static content and abnormal response information;

[0017] Concatenate the Uniform Resource Identifier, request header, request body, response status code, response header, and response body fields in each request message to obtain a string to be processed;

[0018] Based on the summary information of the string to be processed, obtaining a unique hash value of the string to be processed;

[0019] The unique hash value is stored in a cache database, and there is a corresponding relationship between the unique hash value and the application identifier;

[0020] Traversing and removing duplicates of all unique hash values ​​stored in the cache database;

[0021] The other information in each request message is stored in a relational database management system, and the relational database management system uses the unique hash value of the request message as an index field of the other information.

[0022] In yet another possible design of the first aspect, performing session inference on the request message includes:

[0023] Determining user information and user session in the request message based on request parameters in the request message;

[0024] Associate user information and session information of the same user.

[0025] In another possible design of the first aspect, replacing the user association information in the arranged request message with the target test information to obtain a new request message includes:

[0026] Obtain target user information and target session information provided in the target test environment, where the application permissions of the target user are equal to or lower than the application permissions of the user in the request message;

[0027] The session information and user information in the arranged request message are replaced with the target user information and the target session information to obtain the new request message.

[0028] In another possible design of the first aspect, the replaying the new request message for the application includes:

[0029] Determine whether there is a signature verification behavior in the request message;

[0030] If the signature verification behavior exists, when replaying the new request message, the signature verification result returned by the signature verification function of the application is modified to a valid value. The signature verification function is used to verify the validity of the signature of the request message. When the application verifies that the signature is an invalid value, it intercepts the request message.

[0031] In another possible design of the first aspect, determining whether the application has an unauthorized vulnerability based on the feedback information includes:

[0032] Acquire the application program interface in the request execution information, and determine the interface type of the application program interface, where the interface type includes a query type and an operation type;

[0033] When the interface type is a query type, determining whether a target field exists in the feedback information;

[0034] If the target field exists, determine whether there is an unauthorized access vulnerability based on the value of the target field, the field value of the original user of the request message, and the field value of the current user of the new request message;

[0035] If the target field does not exist, it is determined whether there is an unauthorized access vulnerability based on the request execution information and the feedback information.

[0036] In another possible design of the first aspect, determining whether the application has an unauthorized vulnerability based on the feedback information includes:

[0037] When the interface type is an operation type, obtaining at least one of an execution context, a key structured query statement, and a call chain in the request execution information;

[0038] Determining whether there is target information in the feedback information, the target information matching at least one of the execution context, the key structured query statement, and the call chain;

[0039] If the target information exists, it is determined that an unauthorized access vulnerability exists.

[0040] In another possible design of the first aspect, determining whether there is an unauthorized access vulnerability based on the request execution information and the feedback information includes:

[0041] When the interface type is a query type, obtaining a similarity between a first response message in the request execution information and a second response message in the feedback information;

[0042] If the application program interface is a public interface or the similarity is lower than a first similarity threshold, it is determined that there is no unauthorized vulnerability;

[0043] If the similarity is higher than the second similarity threshold, it is determined that an unauthorized access vulnerability exists.

[0044] In a second aspect, an embodiment of the present application provides an application unauthorized vulnerability detection device, comprising:

[0045] An information acquisition module, used to acquire request execution information returned according to at least one request message during the application running process based on the interactive application security testing technology;

[0046] A message arrangement module, used for performing message arrangement on the request message according to the request execution information;

[0047] An information adjustment module, used to replace the user-related information in the arranged request message with the target test information to obtain a new request message;

[0048] A message replay module, used to replay the new request message to the application and obtain feedback information of the application;

[0049] The vulnerability detection module is used to determine whether the application has an unauthorized vulnerability based on the feedback information.

[0050] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method described above.

[0051] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to implement the above-mentioned method when executed by a processor.

[0052] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0053] The application unauthorized access vulnerability detection method, apparatus, device and readable storage medium provided in the embodiments of the present application can simulate the normal operation process of the user by collecting and sorting the request execution flow information generated during the application operation, and then re-arranging and replacing the application request to transform it into a new request message, thereby improving the detection efficiency and the detection effect of the application unauthorized access vulnerability. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0055] Figure 1A schematic diagram of a scenario for automated unauthorized detection provided in an embodiment of the present application;

[0056] Figure 2 A flowchart of an application unauthorized vulnerability detection method provided in an embodiment of the present application;

[0057] Figure 3 A working principle diagram of the service request message encoding technology provided in the embodiment of the present application;

[0058] Figure 4 A flowchart of a method for processing a service request message provided by an embodiment of the present application;

[0059] Figure 5 A flow chart of conversation inference provided for an embodiment of the present application;

[0060] Figure 6 A schematic diagram of a request encapsulation process provided in an embodiment of the present application;

[0061] Figure 7 A flowchart of an unauthorized detection system provided in an embodiment of the present application;

[0062] Figure 8 The unauthorized vulnerability detection flow chart provided in the embodiment of the present application;

[0063] Fig. 9 A schematic diagram of the structure of an application unauthorized vulnerability detection device provided in an embodiment of the present application;

[0064] Fig.10 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0065] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0066] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0067] In the technical solution of this application, the collection, storage, use, processing, transmission, provision and disclosure of information such as financial data or user data involved shall comply with the provisions of relevant laws and regulations and shall not violate public order and good morals.

[0068] It should be noted that in the embodiments of the present application, certain software, components, models and other existing solutions in the industry may be mentioned, and they should be regarded as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0069] Unauthorized access vulnerabilities are a common business logic vulnerability in applications. Currently, unauthorized access detection methods still have many shortcomings, mainly manifested as follows: (1) Incomplete detection. During the detection process, security testers and functional testers are independent. On the one hand, the account permissions applied for by security testers may not cover all business functions; on the other hand, security testers may not have a comprehensive understanding of application functions, resulting in the omission of some functional points during the detection process. Therefore, the detection business request message triggered by the security personnel cannot cover all application programming interfaces (APIs), resulting in incomplete detection and missed detection. (2) High false positive and false negative rates. Currently, semi-automated unauthorized access detection mostly determines whether there is an unauthorized access vulnerability based on the similarity of the returned message. However, similar response messages do not mean that there is an unauthorized access vulnerability. For example, when querying the menu interface, the menus returned by users with the same permissions are the same, which will be mistakenly judged as unauthorized access vulnerabilities. For example, the response result of the operation type request only returns the status of success or failure. Similarly, a successful return does not mean that there is a vulnerability. Similarly, the fact that the returned messages are different or not very similar does not mean that there is no unauthorized access. For example, when deleting an address, user A triggers the deletion and returns True. When the detection message is resent using user B's credentials, it returns False. This may be because the data does not exist. In fact, the interface may still be unauthorized. For applications that use dynamic content or automatically generate content, the similarity matching method may not be able to accurately match because the content of the returned message is changing. (3) Low implementation efficiency. When using the replacement credential method to detect unauthorized access vulnerabilities, security testers need to manually configure user credentials each time. Because it relies on the configuration of security testers, security testers cannot test multiple applications concurrently in the face of high concurrency. In addition, the detection of vulnerabilities also requires manual verification. (4) Not suitable for encryption or anti-replay scenarios. More and more applications encrypt the return message because some parameter values ​​in the return message are dynamically changing, resulting in the returned ciphertext being different each time.

[0070] In response to the above problems, this application provides a technical solution for application unauthorized vulnerability detection to improve the comprehensiveness and implementation efficiency of unauthorized vulnerability detection before the application system is put into production. Specifically, it collects and sorts the request execution flow information generated during the operation of the application, and then re-arranges the request execution flow information, and then replaces the user information in the re-arranged request message, thereby realizing the transformation of the request message to simulate the normal operation process of the user. This can cover all application interfaces as much as possible, and can realize automatic unauthorized vulnerability detection.

[0071] Figure 1 A schematic diagram of a scenario for automatic unauthorized detection provided in an embodiment of the present application, such as Figure 1 As shown in the figure, in the functional testing phase before the application is put into production, the interactive application security testing (IAST) technology is used to automatically collect the application's API interface and the execution information of each request of the API interface and send it to the IAST unauthorized access detection system to realize automatic unauthorized access detection. The specific steps mainly include (1) the functional tester triggers the business request message, and the Java agent obtains the request information, execution context and response content of the corresponding message through the plug-in technology and sends it to the IAST unauthorized access detection system. Among them, the collected request information includes API interface, request parameters, identity credentials, etc. (2) The IAST unauthorized access detection system arranges the information sent by the Java agent according to the API interface. The message arrangement work mainly includes: message cleaning, session inference, request encapsulation, etc. (3) After the IAST unauthorized access detection system arranges the business request message to be detected, it automatically replaces the credentials in the request with the credentials of the user with equal authority or low authority, and then replays the request. (4) The IAST unauthorized access detection system obtains the execution context of the detection request reported by the Java agent and the response message of the application system. (5) The unauthorized access verification engine determines the unauthorized access vulnerability based on the execution context and response content.

[0072] The technical solution of the present application is described in detail below through specific embodiments. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0073] Figure 2 The flowchart of the application unauthorized vulnerability detection method provided in the embodiment of the present application mainly includes: service request message arrangement technology, detection module, unauthorized vulnerability verification method and result verification. Figure 2 As shown, the following steps are included:

[0074] Step S210: Based on the interactive application security testing technology, obtain the request execution information returned according to at least one request message during the application running process.

[0075] In this embodiment, IAST can fully perceive the API assets of the application, not only to achieve visual management of API assets, but also to classify, label, and score API assets, making it convenient for security testers to prioritize and evaluate API assets. In addition, IAST technology can also identify and collect encrypted requests and distributed microservice requests. Whether it is symmetric encryption or asymmetric encryption, whether it is a single application or a microservice architecture, it can obtain plaintext API and data information by plugging in encryption and decryption functions and microservice nodes, thereby improving the coverage of API detection. At the same time, IAST technology can also be combined with the collection of business request messages for functional testing to avoid one-sided cognitive defects of security testers, such as ignoring some edge scenarios or APIs with hidden functions, resulting in missed vulnerabilities. Finally, IAST technology can also realize full-link tracking of requests across services, and can clearly see the source, purpose, parameters, response and other information of each message request, to ensure the comprehensiveness of security testing to the greatest extent.

[0076] In this embodiment, the application running process may refer to the process of performing functional testing on the application during the functional testing phase. After the functional tester triggers the service request message, the application will respond to the service request message. In this request and response interaction process, the request execution information can be obtained through the IAST technology.

[0077] The request execution information can be obtained through the instrumentation technology, which can specifically include the request information of the service request message, the execution context and the response content of the application. Furthermore, the request information also includes the API interface, request parameters and identity credentials.

[0078] Among them, IAST technology can use the instrumentation technology to instrument the session functions of some web frameworks to obtain execution context information. At the same time, it can also identify login requests, extract user session credential information, confirm login and logout request interfaces and session parameters, and realize automatic login configuration information confirmation and extraction, effectively reducing labor costs. IAST technology can also collect the configuration information of the permission framework, obtain the existing permission list of the application, automatically obtain user accounts of different roles, and realize automated permission testing.

[0079] Step S220: Arrange the request message according to the request execution information.

[0080] In this embodiment, IAST technology can be used to collect and sort out the application request flow, re-arrange the business request messages processed by the application, and construct business request lines in chronological order. This can simulate the user's normal operating process and realize automated unauthorized vulnerability detection.

[0081] Exemplarily, in some embodiments, message orchestration mainly includes at least one of message cleaning, session inference, request encapsulation, and message replay.

[0082] For example, Figure 3 The working principle diagram of the service request message encoding technology provided in the embodiment of the present application is as follows: Figure 3 As shown in the figure, message cleaning includes filtering of abnormal response status, request type filtering and request behavior filtering. Session inference includes login request address inference, login configuration field inference, login session inference and login user association. Request encapsulation includes user-session association, user-request association, session pool creation and request encapsulation. Message replay includes building a traffic replay verification platform, building a verification strategy and collecting response information.

[0083] Among them, message cleaning is mainly used to filter out request messages that meet the set filtering conditions according to the set filtering conditions. Specifically, the set filtering conditions include one or more of the following: abnormal application response, failure to meet the set request type, and failure to meet the set request behavior requirements. By filtering out the request messages that meet the conditions, it is convenient to subsequently modify the messages that meet the conditions, thereby improving the message utilization rate and message modification efficiency.

[0084] Step S230: Replace the user-related information in the arranged request message with the target test information to obtain a new request message.

[0085] In this embodiment, after the IAST unauthorized access detection system arranges the service request message, it automatically replaces the user credentials in the service request message with user credentials of equal or lower authority, thereby achieving the final transformation of the service request message.

[0086] Exemplarily, during the replacement process, it is necessary to set permissions for user information, such as simply setting role weights for users based on their permissions, and then mapping the user list collected from each business request and test traffic, encapsulating the test traffic of users with high weights into other users with low weights that do not exist in the mapping list, or encapsulating the test traffic of users with the same weights into users with other weights that do not exist in the mapping list.

[0087] Step S240: replay the new request message to the application to obtain feedback information from the application.

[0088] Step S230: Based on the feedback information, determine whether the application has an unauthorized vulnerability.

[0089] In this embodiment, IAST technology is used to achieve all-round perception of the application's API assets and request behaviors through API interface mapping, tainted data flow tracking, request re-orchestration, permission framework configuration collection, function call sequence collection, key function trigger perception, and other means.

[0090] Among them, by comparing the feedback information with the request execution information returned by the original request message, the similarity can be obtained to determine whether there is an unauthorized access vulnerability. The higher the similarity, the more likely it is that there is an unauthorized access vulnerability.

[0091] In addition, in some implementations, by using IAST technology, not only can the response information be compared for similarity, but also the content, format, length, status code and other information of the response information can be compared to improve the accuracy and efficiency of detection, as well as improve the accuracy and provide capability support for multi-dimensional information visualization. Compared with the response information comparison model, the unauthorized detection based on IAST has higher comprehensiveness, automation and accuracy, and can also provide more information visualization and optimization support, providing security personnel with more powerful unauthorized vulnerability prevention capabilities.

[0092] The embodiment of the present application collects and sorts out the request execution flow information generated during the operation of the application, and then re-arranges and replaces the application's requests to transform them into new request messages. This can simulate the user's normal operating process, achieve automated unauthorized vulnerability detection, improve detection efficiency, and improve the detection effect of application unauthorized vulnerability.

[0093] Furthermore, in some embodiments, in actual scenarios, when collecting and sorting service request messages, it is considered that directly storing the service request messages without processing may cause a large amount of memory space to be occupied. Therefore, after filtering out some service request messages that meet the set filtering conditions, the following steps can be used to store the remaining service request messages for subsequent replay. Specifically, Figure 4 This is a flow chart of a method for processing a service request message according to an embodiment of the present application, such as Figure 4 As shown, it includes the following steps:

[0094] Step S410: Filter out irrelevant information in each request message;

[0095] Step S420: concatenate the Uniform Resource Identifier, request header, request body, response status code, response header, and response body fields in each request message to obtain a string to be processed;

[0096] Step S430: based on the summary information of the string to be processed, obtaining a unique hash value of the string to be processed;

[0097] Step S440: storing the unique hash value in the Remote Dictionary Server (Redis) cache database, wherein there is a corresponding relationship between the unique hash value and the application identifier;

[0098] Step S450: traverse and remove duplicates from all unique hash values ​​stored in the cache database;

[0099] Step S460: store other information in each request message in the relational database management system MySQL.

[0100] The irrelevant information includes at least one of static content and abnormal response information; the relational database management system uses the unique hash value of the request message as an index field for other information.

[0101] In this embodiment, the service request message is stored in the cache database in the form of a message digest. The data structure adopts the form of a KV key-value pair, and an algorithm (such as the SHA-256 algorithm) is used to generate a message digest instead of the original data. No matter how long the input data is, the resulting message digest is of fixed length, which is convenient for storage management. In addition, the original data of the non-repeated service request message is stored in the MySQL database to avoid repeated storage and occupying storage space.

[0102] Specifically, the process of business request message cleaning is as follows:

[0103] 1. Filter static content such as images, pages (including js / css / html), and some requests with abnormal response status codes. These contents usually do not involve business logic or are abnormal business requests, and do not require subsequent orchestration and replay testing. Filtering them can save network bandwidth and storage space.

[0104] 2. Concatenate the Uniform Resource Identifier (URI), request header, request body, response status code, response header, and response body fields of the business request message to obtain a string to be processed. Among them, some noise data in the request URI, request body, and response body can be filtered by adding configuration.

[0105] 3. Use the SHA-256 algorithm to digest the string and generate a unique hash value.

[0106] 4. The hash value generated by the business request message is stored in the Redis cache database as the V value of the KV key-value pair, and the universally unique identifier (UUID) of each application is used as the K value of the KV key-value pair.

[0107] 5. Use the method provided by the Redis cache database to traverse the V value of the KV key-value pair, and add each non-duplicate KV element to the collection, thereby obtaining a non-duplicate data set.

[0108] 6. The hash value generated by the business request message is used as the index field of the table, and the specific data of the business request message is divided into multiple columns of the MySQL table for data storage.

[0109] The embodiment of the present application can reduce the storage space required for the business request message by filtering, removing duplications, and establishing key-value pairs for the business request message. Finally, the hash value is used as the index field of the table to divide the specific data of the business request message into multiple columns of the MySQL table for data storage, which can facilitate the subsequent rapid retrieval and query of the desired business request message information when needed, so as to realize the transformation of the business request message and improve the automatic unauthorized vulnerability detection effect.

[0110] Based on the above embodiments, the conversation inference process is described in detail through some embodiments below.

[0111] Among them, session inference is mainly based on the request parameters in the request message, determining the user information and user session in the request message, and then associating the user information and session information of the same user, so as to facilitate the subsequent replacement of user association information.

[0112] The user-related information may refer to user information and session information associated with the user information.

[0113] In this embodiment, after the service request message passes through the above-mentioned message cleaning, the user's login status, session information and user identity can be inferred according to the request parameters in the service request message.

[0114] Among them, session inference mainly utilizes the features in the business request message, such as / login in the URI, set-cookie in the response header and other information for rule analysis, to achieve automatic login configuration identification, user session identification, and user information identification, thereby improving the efficiency of unauthorized detection.

[0115] Specifically, Figure 5 The conversation inference flow chart provided in the embodiment of the present application is as follows: Figure 5 As shown, it includes the steps of:

[0116] Step S510: Perform rule analysis based on request parameter characteristics to infer login, logout and session configuration information in the message request.

[0117] Among them, this information usually includes user name, password, token, session ID, session timeout, etc., which can be used to identify the user's identity and the validity of the session.

[0118] Step S520: reverse the request message to obtain the user name.

[0119] Among them, these user names are usually entered by users when registering or logging in, and can be used to distinguish different users and user groups, providing a basis for subsequent business request message processing.

[0120] Step S530: Based on the collected user session information, the message requests belonging to the same user are organized into a session in chronological order, and the sessions of different users are stored separately, so as to provide a data source for subsequent service request message replay and testing.

[0121] The embodiment of the present application realizes automatic login configuration information confirmation and extraction by performing login request identification, extracting session credential information, confirming login and logout request interface and session parameters, and effectively reduces labor costs. At the same time, by automatically obtaining user accounts of different roles, automatic unauthorized vulnerability detection can be realized.

[0122] Based on the above embodiments, the information replacement process is described in detail through some embodiments below.

[0123] In this embodiment, in order to detect unauthorized vulnerabilities, it is necessary to modify the user in the original request message, for example, replace it with another user with lower authority, and then replay the modified request message after the replacement is completed. During the replacement, the security tester needs to obtain the target user information and target session information from the target test environment, and then replace the session information and user information in the arranged request message with the target user information and target session information to obtain a new request message.

[0124] Among them, the application permissions of the target user are equal to or lower than the application permissions of the user in the request message. During the replacement process, it is necessary to set permissions for the user information obtained in the session inference phase, such as simply setting role weights for users from high to low permissions, and then mapping the user list collected from each request and test traffic, encapsulating the test traffic of users with high weights into other users with low weights that do not exist in the mapping list, or encapsulating the test traffic of users with the same weight into users with other weights that do not exist in the mapping list.

[0125] In this embodiment, in the process of replacing the information in the request message, it is necessary to further encapsulate the request to obtain a new request message that can be reused and replayed. Specifically, Figure 6 A schematic diagram of the request encapsulation process provided in the embodiment of the present application is shown in FIG. Figure 6 As shown, it includes the following steps:

[0126] Step S610: Based on the session inference, determine the association between the user and the session, that is, identify the sender of the message request according to the information in the message request, and provide a basis for subsequent request modification and conversion.

[0127] Step S620: Replace the session information in the message request based on the session mapping, that is, update the session ID, token, cookie, etc. in the message request according to the session information in the target test environment to ensure the validity and consistency of the request.

[0128] Step S630: Based on the user-request association, the user name in the message request is replaced, that is, the user name in the request is updated according to the user name in the target test environment to simulate different users and user groups, providing diversity and randomness for subsequent tests.

[0129] Step S640: Encapsulate the test request based on automatic session replacement. That is, according to the above three steps, replace the session information and user name in the original message request with the information in the target test environment, realize the transformation of the service request message, obtain a new request message, and then reuse and replay it.

[0130] The embodiment of the present application realizes the transformation of the request message by replacing the user information and session information, which is equivalent to simulating the normal interactive operation process between the user and the application. It can more comprehensively test the functional points of the application, determine whether there are unauthorized vulnerabilities, and solve the problem that the security tester manually triggers the detection of business request messages, which cannot cover all API interfaces, resulting in incomplete detection and missed detection.

[0131] In addition, in some embodiments, some applications may add a replay mechanism, and the same message after modification may not be able to be replayed directly (in the process of unauthorized detection, after the information replacement is completed, it is often intercepted by the application when passing through the signature verification function). This is mainly because the application side is configured with a signature verification function, and each request message sent to the application is also configured with a signature verification behavior to prompt the application side to perform signature verification through the signature verification function. Among them, the signature verification function is used to verify the digital signature. By receiving the request message as input, and then checking whether the signature in the request message is valid. If the signature is valid, the signature verification function returns a true value (True), otherwise it returns a false value (False). For such applications configured with a replay mechanism, it is necessary to forcibly modify the signature verification result returned by the application's signature verification function to a valid value so that the modified new request message can be replayed.

[0132] In this embodiment, the IAST technology can be used to embed the signature verification function, modify the return value of the signature verification function, and force the return of the true value (True). Specifically, by using the IAST tool, the signature verification function is dynamically analyzed to find out its location, parameters, return value and other information, and then a piece of code is inserted during its execution to modify its return value to a true value (True). In this way, no matter what kind of modification is made to the original request message, the signature will be considered correct, and the request will be accepted.

[0133] In addition, in some confidentiality scenarios, the interactive data between the application and the user will be encrypted. In this case, the encryption and decryption functions can be embedded through IAST technology, and the decryption process of the encrypted request message can be tracked using tainted data tracking and data flow analysis technology to obtain the original message information of the encrypted data. Subsequently, the key-value pairs of the data can be extracted according to the request format of the original message, and the application interface information and request data information in the encrypted message can be identified.

[0134] The embodiment of the present application can effectively deal with applications that have added an anti-replay mechanism by forcibly modifying the signature verification result returned by the application's signature verification function to a valid value, so as to achieve multiplexing and replay of request messages and improve the applicability of unauthorized vulnerability detection in complex scenarios.

[0135] The following describes in detail how to determine whether an application has an unauthorized vulnerability through some embodiments.

[0136] Figure 7 The flowchart of the unauthorized detection system provided in the embodiment of the present application is as follows: Figure 7 As shown, it mainly includes the following steps:

[0137] 1. Java agent configuration. Security testers or project team members can configure and download the Java agent on the IAST unauthorized access detection system and run it on the application to be tested.

[0138] 2. Functional testers conduct functional testing, triggering business request data packets, and Java agent collects information without awareness, including API asset mapping, business request message parsing, and execution context awareness.

[0139] 3. The unauthorized test module performs unauthorized test without any perception, arranges messages and replays them.

[0140] 4. The unauthorized verification module tests the API interface to make an unauthorized judgment and output the result.

[0141] 5. The safety tester verifies the test results and confirms the parts that need manual re-verification.

[0142] Among them, a fusion verification method can be used to detect unauthorized vulnerabilities. In addition to comparing the similarity of the returned messages, verification of unauthorized vulnerabilities also adds authentication function execution audit, field list identification, and behavior identification comparison. For example, Figure 8 The unauthorized vulnerability detection flow chart provided in the embodiment of the present application is as follows: Figure 8 As shown, first obtain the application interface to be verified. When mapping API assets, the IAST unauthorized access detection system will monitor the execution of the request message that needs to be unauthorized based on the authentication function audit rules, and audit whether the corresponding API interface calls the authentication function. The authentication function can be configured by the security tester on the IAST unauthorized access detection system. If not configured, the Java agent probe will identify the authentication function information based on the comments, function execution return results, etc. during the application operation. After completing the authentication function call determination, the interface type of the application interface will be further determined.

[0143] Among them, when the interface type is a query type, determine whether there is a target field (i.e., review field) in the feedback information; if there is a target field, determine whether there is an unauthorized access vulnerability based on the value of the target field, the field value of the original user of the request message, and the field value of the current user of the new request message.

[0144] Among them, the judgment of the target field is mainly to identify whether the message in the feedback information contains the sensitive field name. Further, if the target field does not exist, it will go to the behavior identification step to determine whether there is an unauthorized vulnerability based on the request execution information and the feedback information.

[0145] When configuring the review field list, the field design and naming of the same application are similar or even consistent across different interfaces. This configuration mainly configures some sensitive fields of the user, such as ID card field, mobile phone number field, home address field, etc. When the security tester does not perform this configuration, the IAST unauthorized access detection system will infer the corresponding fields based on the business process of the application login.

[0146] In addition, in some implementations, when the interface type is an operation type, the process proceeds to the behavior identification step. The behavior identification process mainly obtains at least one of the execution context, key structured query statements, and call chains in the request execution information; then determines whether there is target information matching at least one of the execution context, key structured query statements, and call chains in the feedback information. If there is target information, it is determined that there is an unauthorized vulnerability.

[0147] Among them, when the API interface is of operation type, the execution context, key structured query language (SQL) and call chain of the original message are identified and judged. If the key SQL statements are consistent, it can be judged that there is an unauthorized use.

[0148] Finally, in some other implementations, if the API interface is a query type and there is no target field, if the above target information exists, then it is necessary to determine the similarity of the response message or whether it is a public interface. A first similarity threshold and a second similarity threshold can be set. If the application program interface is a public interface or the similarity is lower than the first similarity threshold (the value is relatively small), it is determined that there is no unauthorized vulnerability; if the similarity is higher than the second similarity threshold (the value is relatively large, at least greater than the first similarity threshold), it is determined that there is an unauthorized vulnerability.

[0149] For example, when the API is a query type and there is no review field list in the feedback message, after excluding non-public interfaces, a comprehensive judgment can be made based on the consistency of key SQL statements and the similarity of the returned messages. The similarity includes the response status code. If the status code is inconsistent, there is no unauthorized vulnerability.

[0150] Exemplarily, in addition to setting the above-mentioned first similarity threshold and second similarity threshold, multiple similarity thresholds can also be set to perform graded judgment on unauthorized behavior, such as setting similarity threshold A, similarity threshold B and similarity threshold C. If the similarity is lower than similarity threshold A, it is determined that there is no unauthorized vulnerability, and if the phase velocity is higher than similarity threshold B and lower than similarity threshold C, it is determined that there is a suspicion of unauthorized vulnerability and further verification is required. If the phase velocity is higher than similarity threshold C, it is determined that there is an unauthorized vulnerability.

[0151] The embodiment of the present application detects unauthorized access vulnerabilities by adopting a fusion verification method. In addition to comparing the similarity of returned messages, the verification of unauthorized access vulnerabilities also adds authentication function execution auditing, field list identification, and behavior identification comparison, which can improve the accuracy of unauthorized access vulnerability detection and solve the problem of high false alarm rate and missed alarm rate in current semi-automatic unauthorized access detection.

[0152] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

[0153] Fig. 9 A schematic diagram of the structure of the application unauthorized vulnerability detection device provided in the embodiment of the present application is shown in FIG. Fig. 9 As shown, the application unauthorized vulnerability detection device 900 includes an information acquisition module 910 , a message arrangement module 920 , an information adjustment module 930 , a message replay module 940 and a vulnerability detection module 950 .

[0154] Among them, the information acquisition module 910 is used to obtain the request execution information returned according to at least one request message during the operation of the application based on the interactive application security testing technology. The message arrangement module 920 is used to arrange the request message according to the request execution information. The information adjustment module 930 is used to replace the user association information in the arranged request message with the target test information to obtain a new request message. The message replay module 940 is used to replay the new request message to the application to obtain feedback information of the application. The vulnerability detection module 950 is used to determine whether the application has an unauthorized vulnerability based on the feedback information.

[0155] Optionally, the message orchestration includes at least one of message cleaning, session inference, and request encapsulation.

[0156] Optionally, it also includes a message cleaning module, which is used to filter out request messages that meet set filtering conditions in at least one request message, and the set filtering conditions include one or more of the following: the existence of an abnormal application response, failure to meet a set request type, and failure to meet a set request behavior requirement.

[0157] Optionally, a storage module is also included, which is used to filter out irrelevant information in each request message; concatenate the uniform resource identifier, request header, request body, response status code, response header, and response body fields in each request message to obtain a string to be processed; based on the summary information of the string to be processed, obtain a unique hash value of the string to be processed; store the unique hash value in a cache database, and there is a corresponding relationship between the unique hash value and the application identifier; traverse and deduplicate all unique hash values ​​stored in the cache database; and store other information in each request message in a relational database management system.

[0158] The irrelevant information includes at least one of static content and abnormal response information. The relational database management system uses the unique hash value of the request message as the index field of other information.

[0159] Optionally, it also includes a session inference module, which is used to determine the user information and user session in the request message based on the request parameters in the request message; and associate the user information and session information of the same user.

[0160] Optionally, the information adjustment module can be specifically used to: obtain target user information and target session information provided in the target test environment; replace the session information and user information in the arranged request message with the target user information and target session information to obtain a new request message.

[0161] The application permission of the target user is equal to or lower than the application permission of the user in the request message.

[0162] Optionally, the message replay module can be specifically used to determine whether there is a signature verification behavior in the request message; if there is a signature verification behavior, then when replaying a new request message, the signature verification result returned by the application's signature verification function is modified to a valid value. The signature verification function is used to verify the validity of the signature of the request message. When the application verifies that the signature is an invalid value, it intercepts the request message.

[0163] Optionally, the vulnerability detection module can be specifically used to: obtain the application interface in the request execution information and determine the interface type of the application interface; when the interface type is a query type, determine whether there is a target field in the feedback information; if there is a target field, determine whether there is an unauthorized vulnerability based on the value of the target field, the field value of the original user of the request message, and the field value of the current user of the new request message; if there is no target field, determine whether there is an unauthorized vulnerability based on the request execution information and the feedback information. Among them, the interface type includes the query type and the operation type.

[0164] Optionally, the vulnerability detection module can be specifically used to: when the interface type is an operation type, obtain at least one of the execution context, key structured query statements, and call chains in the request execution information; determine whether there is target information in the feedback information; if there is target information, determine that there is an unauthorized vulnerability. The target information matches at least one of the execution context, key structured query statements, and call chains.

[0165] Optionally, the vulnerability detection module can be specifically used for: when the interface type is a query type, obtaining the similarity between the first response message in the request execution information and the second response message in the feedback information; if the application interface is a public interface or the similarity is lower than a first similarity threshold, determining that there is no unauthorized vulnerability; if the similarity is higher than a second similarity threshold, determining that there is an unauthorized vulnerability.

[0166] The device provided in the embodiment of the present application can be used to execute the method in the above embodiment. Its implementation principle and technical effect are similar and will not be repeated here.

[0167] It should be noted that it should be understood that the division of the various modules of the above device is only a division of logical functions. In actual implementation, they can be fully or partially integrated into one physical entity, or they can be physically separated. And these modules can all be implemented in the form of software called by processing elements; they can also be all implemented in the form of hardware; some modules can also be implemented in the form of software called by processing elements, and some modules can be implemented in the form of hardware. For example, the information acquisition module can be a separately established processing element, or it can be integrated in a chip of the above device. In addition, it can also be stored in the memory of the above device in the form of program code, and called and executed by a processing element of the above device. The implementation of other modules is similar. In addition, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each module above can be completed by an integrated logic circuit of hardware in the processor element or instructions in the form of software.

[0168] Fig.10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Fig.10 As shown, the electronic device 1000 includes: at least one processor 1001, a memory 1002, a bus 1003 and a communication interface 1004. Among them: the processor, the communication interface and the memory communicate with each other through the bus. The communication interface is used to communicate with other devices. The communication interface includes a communication interface for data transmission and a display interface or an operation interface for human-computer interaction.

[0169] The processor is used to execute the computer-executable instructions stored in the memory, and specifically can execute the relevant steps in the method described in the above embodiment.

[0170] The processor may be a central processing unit, or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement an embodiment of the present invention. The one or more processors included in the review device may be processors of the same type, such as one or more CPUs; or they may be processors of different types, such as one or more CPUs and one or more ASICs. The memory is used to store computer execution instructions. The memory may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk memory.

[0171] This embodiment also provides a computer-readable storage medium, in which computer instructions are stored. When at least one processor of an electronic device executes the computer instructions, the electronic device executes the methods provided in the above-mentioned various implementation modes.

[0172] This embodiment also provides a computer program product, which includes computer instructions stored in a readable storage medium. At least one processor of the electronic device can read the computer instructions from the readable storage medium, and at least one processor executes the computer instructions so that the electronic device implements the methods provided in the above various embodiments.

[0173] In the present application, "at least one" means one or more, and "plurality" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship; in the formula, the character " / " indicates that the previous and next associated objects are in a "division" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple.

[0174] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0175] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for detecting application unauthorized vulnerabilities, characterized in that: include: Based on the interactive application security testing technology, obtaining the request execution information returned according to at least one request message during the application running process; Arrange the request message according to the request execution information; The user-related information in the arranged request message is replaced with the target test information to obtain a new request message; Replaying the new request message to the application to obtain feedback information of the application; Based on the feedback information, determine whether the application has an unauthorized vulnerability.

2. The method according to claim 1, characterized in that The message arrangement includes at least one of message cleaning, session inference, and request encapsulation.

3. The method according to claim 2, characterized in that The request message is cleaned, including: Filter out the request message that meets the set filtering condition in the at least one request message, where the set filtering condition includes one or more of the following: abnormal application response, failure to meet the set request type, and failure to meet the set request behavior requirement.

4. The method according to claim 3, characterized in that After the request message is cleaned, the method further includes: Filter out irrelevant information in each request message, wherein the irrelevant information includes at least one of static content and abnormal response information; Concatenate the Uniform Resource Identifier, request header, request body, response status code, response header, and response body fields in each request message to obtain a string to be processed; Based on the summary information of the string to be processed, obtaining a unique hash value of the string to be processed; The unique hash value is stored in a cache database, and there is a corresponding relationship between the unique hash value and the application identifier; Traversing and removing duplicates of all unique hash values ​​stored in the cache database; The other information in each request message is stored in a relational database management system, and the relational database management system uses the unique hash value of the request message as an index field of the other information.

5. The method according to claim 2, characterized in that: Performing session inference on the request message includes: Determining user information and user session in the request message based on request parameters in the request message; Associate user information and session information of the same user.

6. The method according to claim 1, characterized in that The step of replacing the user association information in the arranged request message with the target test information to obtain a new request message includes: Obtain target user information and target session information provided in the target test environment, where the application permissions of the target user are equal to or lower than the application permissions of the user in the request message; The session information and user information in the arranged request message are replaced with the target user information and the target session information to obtain the new request message.

7. The method according to claim 1, characterized in that The application replaying the new request message includes: Determine whether there is a signature verification behavior in the request message; If the signature verification behavior exists, when replaying the new request message, the signature verification result returned by the signature verification function of the application is modified to a valid value. The signature verification function is used to verify the validity of the signature of the request message. When the application verifies that the signature is an invalid value, it intercepts the request message.

8. The method according to claim 1, characterized in that: The determining, based on the feedback information, whether the application has an unauthorized vulnerability includes: Acquire the application program interface in the request execution information, and determine the interface type of the application program interface, where the interface type includes a query type and an operation type; When the interface type is a query type, determining whether a target field exists in the feedback information; If the target field exists, determine whether there is an unauthorized access vulnerability based on the value of the target field, the field value of the original user of the request message, and the field value of the current user of the new request message; If the target field does not exist, it is determined whether there is an unauthorized access vulnerability based on the request execution information and the feedback information.

9. The method according to claim 8, characterized in that The determining, based on the feedback information, whether the application has an unauthorized vulnerability includes: When the interface type is an operation type, obtaining at least one of an execution context, a key structured query statement, and a call chain in the request execution information; Determining whether there is target information in the feedback information, the target information matching at least one of the execution context, the key structured query statement, and the call chain; If the target information exists, it is determined that an unauthorized access vulnerability exists.

10. The method according to claim 8, characterized in that The determining whether there is an unauthorized vulnerability based on the request execution information and the feedback information includes: When the interface type is a query type, obtaining a similarity between a first response message in the request execution information and a second response message in the feedback information; If the application program interface is a public interface or the similarity is lower than a first similarity threshold, it is determined that there is no unauthorized vulnerability; If the similarity is higher than the second similarity threshold, it is determined that an unauthorized access vulnerability exists.

11. An application unauthorized vulnerability detection device, characterized in that: include: An information acquisition module, used to acquire request execution information returned according to at least one request message during the application running process based on the interactive application security testing technology; A message arrangement module, used for performing message arrangement on the request message according to the request execution information; An information adjustment module, used to replace the user-related information in the arranged request message with the target test information to obtain a new request message; A message replay module, used to replay the new request message to the application and obtain feedback information of the application; The vulnerability detection module is used to determine whether the application has an unauthorized vulnerability based on the feedback information.

12. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 10 when executed by a processor.

14. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 10 when being executed by a processor.

Images