Abuse detection method, device and equipment and readable storage medium

Abstract

The application provides an application privilege violation detection method and device, equipment and a readable storage medium, relates to the technical field of network security, and the method comprises the following steps: based on interactive application security testing technology, obtaining request execution information returned according to at least one request message in an application running process; arranging the request message according to the request execution information; replacing user-associated information in the arranged request message with target test information to obtain a new request message; replaying the new request message to the application to obtain feedback information of the application; and determining whether the application has a privilege violation based on the feedback information. The scheme can collect request execution flow information generated in the application running process, re-arrange the request of the application, replace and transform into a new request message, simulate the normal operation process of the user, realize automatic privilege violation detection, improve the detection efficiency, and improve the detection effect of the application privilege violation.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security, and in particular to an application privilege escalation vulnerability detection method and device, equipment and a readable storage medium. BACKGROUND

[0002] Privilege escalation vulnerability is a common business logic vulnerability in an application. Business logic vulnerability ranks first in the vulnerability list due to its universality, unpredictability, irregularity and destructiveness. Privilege escalation vulnerability has the characteristics of strong concealment, low repeatability and large differentiation.

[0003] At present, detection of application privilege escalation vulnerability before the information system is put into production 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 application privilege escalation vulnerability detection effect. SUMMARY

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

[0006] In a first aspect, an application privilege escalation vulnerability detection method is provided, comprising:

[0007] Based on interactive application security testing technology, request execution information returned according to at least one request message in an application running process is acquired;

[0008] According to the request execution information, the request message is arranged;

[0009] User association information in the arranged request message is replaced by target test information to obtain a new request message;

[0010] The new request message is replayed to the application to acquire feedback information of the application;

[0011] Based on the feedback information, it is determined whether the application has privilege escalation vulnerability.

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

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

[0014] The request message in the at least one request message that meets a set filtering condition is filtered, and the set filtering condition includes one or more of the following: existence of application abnormal response, non-compliance with a set request type, non-compliance with a set request behavior requirement.

[0015] In a further possible design of the first aspect, after the packet cleaning on the request packet, the method further includes:

[0016] filtering irrelevant information in each request packet, the irrelevant information including at least one of static content, abnormal response information;

[0017] concatenating a uniform resource identifier, a request header, a request body, a response status code, a response header, and a response body field in each request packet to obtain a to-be-processed string;

[0018] obtaining a unique hash value of the to-be-processed string based on digest information of the to-be-processed string;

[0019] storing the unique hash value into a cache database, the unique hash value and an application identifier having a corresponding relationship;

[0020] iterating and deduplicating all unique hash values stored in the cache database;

[0021] storing other information in each request packet into a relational database management system, the relational database management system taking the unique hash value of the request packet as an index field of the other information.

[0022] In a further possible design of the first aspect, the session inference on the request packet includes:

[0023] determining user information and a user session in the request packet based on a request parameter in the request packet;

[0024] associating the user information and the session information of a same user.

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

[0026] obtaining target user information and target session information provided in a target test environment, an application permission of the target user being equal to or lower than an application permission of a user in the request packet;

[0027] replacing the session information and the user information in the arranged request packet with the target user information and the target session information to obtain the new request packet.

[0028] In a further possible design of the first aspect, the replaying the new request packet on an application includes:

[0029] determining whether there is a signature verification behavior in the request packet;

[0030] If the signature verification behavior exists, a signature verification result returned by a signature verification function of the application is modified to a valid value when the new request message is replayed, the signature verification function is used to verify the signature validity of the request message, and the application intercepts the request message when the signature is verified as an invalid value.

[0031] In a further possible design of the first aspect, the determining whether the application has the privilege-escalation vulnerability based on the feedback information comprises:

[0032] An application program interface in the request execution information is acquired, and an interface type of the application program interface is determined, the interface type comprising a query type and an operation type;

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

[0034] If the target field exists, it is determined whether the privilege-escalation vulnerability exists according to a value of the target field, a field value of an original user of the request message, and a field value of a current user of the new request message;

[0035] If the target field does not exist, it is determined whether the privilege-escalation vulnerability exists based on the request execution information and the feedback information.

[0036] In a further possible design of the first aspect, the determining whether the application has the privilege-escalation vulnerability based on the feedback information comprises:

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

[0038] It is determined whether target information exists in the feedback information, the target information matching the 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 the privilege-escalation vulnerability exists.

[0040] In a further possible design of the first aspect, the determining whether the privilege-escalation vulnerability exists based on the request execution information and the feedback information comprises:

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

[0042] If the application program interface is a public interface or the similarity is lower than a first similarity threshold, it is determined that the privilege-escalation vulnerability does not exist;

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

[0044] In a second aspect, the embodiments of the present application provide an application overreach vulnerability detection device, comprising:

[0045] An information acquisition module is configured to acquire request execution information returned according to at least one request message during application running based on an interactive application security testing technology.

[0046] A message arrangement module is configured to arrange a message of the request message based on the request execution information.

[0047] An information adjustment module is configured to replace user-associated information in the arranged request message with target test information to obtain a new request message.

[0048] A message replay module is configured to replay the new request message to the application to acquire feedback information of the application.

[0049] A vulnerability detection module is configured to determine whether the application has an overreach vulnerability based on the feedback information.

[0050] In a third aspect, the embodiments of the present application provide an electronic device, comprising a processor and a memory connected with the processor in communication; the memory stores computer execution instructions; and the processor executes the computer execution instructions stored in the memory to implement the method described above.

[0051] In a fourth aspect, the embodiments of the present application provide a computer readable storage medium, wherein the computer readable storage medium stores computer execution instructions; and the computer execution instructions are executed by a processor to implement the method described above.

[0052] In a fifth aspect, the embodiments of the present application provide a computer program product, comprising a computer program, which, when executed by a processor, implements the method described above.

[0053] The application overreach vulnerability detection method, device, equipment and readable storage medium provided by the embodiments of the present application can collect and sort request execution flow information generated during application running, then replace and transform the request of the application into a new request message, simulate normal operation flow of a user, implement automatic overreach vulnerability detection, improve detection efficiency, and improve detection effect of application overreach vulnerability. BRIEF DESCRIPTION OF DRAWINGS

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

[0055] Figure 1A scene schematic diagram of automatic unauthorized detection provided by an embodiment of the present application is provided.

[0056] Figure 2 A flow schematic diagram of an application unauthorized vulnerability detection method provided by an embodiment of the present application is provided.

[0057] Figure 3 A working principle diagram of a service request message coding technology provided by an embodiment of the present application is provided.

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

[0059] Figure 5 A session inference flowchart provided by an embodiment of the present application is provided.

[0060] Figure 6 A request encapsulation flow schematic diagram provided by an embodiment of the present application is provided.

[0061] Figure 7 A flowchart of an unauthorized detection system provided by an embodiment of the present application is provided.

[0062] Figure 8 A flowchart of an unauthorized vulnerability detection provided by an embodiment of the present application is provided.

[0063] Figure 9 A structural schematic diagram of an application unauthorized vulnerability detection device provided by an embodiment of the present application is provided.

[0064] Figure 10 A structural schematic diagram of an electronic device provided by an embodiment of the present application is provided.

[0065] Through the above-mentioned drawings, the specific embodiments of the present application have been shown, and more detailed descriptions will be given hereinafter. These drawings and textual descriptions are not intended to limit the scope of the concept of the present application by any means, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0066] The exemplary embodiments will be described in detail herein with reference to the attached drawings. In the following description, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments are not representative of all embodiments consistent with the present application. Rather, 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 solutions of the present application, the collection, storage, use, processing, transmission, provision and disclosure of information such as financial data or user data, etc. comply with the relevant legal regulations and do not violate public order and good customs.

[0068] It should be noted that in the embodiments of the present application, some software, components, models and the like in the prior art may be mentioned, which should be considered as exemplary, and the purpose is only to illustrate the feasibility of the implementation of the technical solutions of the present application, but does not mean that the applicant has or will necessarily use the scheme.

[0069] The privilege violation is a common business logic vulnerability in an application. At present, the privilege detection method still has many deficiencies, mainly as follows: (1) incomplete detection. In the detection process, the security testers and the functional testers are independent. On the one hand, the account permissions applied by the security testers may not cover all business functions; on the other hand, the security testers may not fully understand the application functions, resulting in the omission of some function points in 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 rate and false negative rate. At present, the semi-automatic privilege detection is mostly based on the similarity of the returned message to judge whether there is a privilege violation. However, similar response messages do not mean that there is a privilege violation. For example, the menu returned by users with the same permission for the query menu interface is the same, which will be misjudged as a privilege violation. For example, the operation type request response result only returns a successful or failed state, and the same success return does not mean that there is a vulnerability. Similarly, the returned messages are different or have low similarity, which does not mean that there is no privilege. For example, after user A triggers the delete operation, the return is True, and the user B's credentials are re-sent to send the detection message, which returns False. This may be caused by the absence of the data, and in fact, the interface may still have a privilege. For applications using dynamic content or automatically generated content, the similarity matching method may not be able to accurately match the changing content of the returned message. (3) Low implementation efficiency. Privilege violation detection using the replacement credential method requires manual configuration of user credentials by security testers each time. Because it depends on the configuration of security testers, security testers cannot perform concurrent testing of multiple applications in the face of high concurrency. In addition, the verification of the vulnerability also needs manual verification. (4) Not applicable to encryption or anti-replay scenarios. More and more applications encrypt the returned message because some parameter values in the returned message are dynamically changing, resulting in different ciphertexts each time.

[0070] To address the aforementioned issues, this application provides a technology solution for detecting privilege escalation vulnerabilities, thereby improving the comprehensiveness and efficiency of privilege escalation vulnerability detection before application system deployment. Specifically, it involves collecting and organizing request execution flow information generated during application runtime, then rearranging this information, and finally replacing the user information in the rearranged request messages. This modifies the request messages to simulate the user's normal operational process. This approach can cover as many application interfaces as possible and achieves automated privilege escalation vulnerability detection.

[0071] Figure 1 This is a schematic diagram of an automated privilege escalation detection scenario provided in an embodiment of this application, such as... Figure 1 As shown, during the functional testing phase before application deployment, the Interactive Application Security Testing (IAST) technology is used to automatically collect the application's API interfaces and the execution information of each request of the API interfaces and send them to the IAST privilege escalation detection system to achieve automated privilege escalation detection. The specific steps mainly include (1) Functional testers trigger business request messages, and the Java agent obtains the request information, execution context and application response content of the corresponding message through instrumentation technology and sends them to the IAST privilege escalation detection system. Among them, the collected request information includes API interfaces, request parameters, identity credentials, etc. (2) The IAST privilege escalation detection system performs message orchestration on the information sent by the Java agent according to the API interface. Message orchestration work mainly includes: message cleaning, session inference, request encapsulation, etc. (3) After orchestrating the business request message to be detected, the IAST privilege escalation detection system automatically replaces the credentials in the request with the credentials of users with equal or lower privileges, and then replays the request. (4) The IAST privilege escalation 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 privilege escalation verification engine determines privilege escalation vulnerabilities based on the execution context and response content.

[0072] The technical solution of this application will now be described in detail 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 again in some embodiments.

[0073] Figure 2 This is a flowchart illustrating the application privilege escalation vulnerability detection method provided in this embodiment. The entire process of automated privilege escalation vulnerability detection based on IAST technology mainly includes: business request message orchestration technology, detection module, privilege escalation vulnerability verification method, and result verification. Figure 2 As shown, it includes the following steps:

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

[0075] In the embodiment, the IAST can comprehensively perceive API assets of the application program, can not only realize visual management of the API assets, but also can perform operations such as classification, labeling and scoring on the API assets, and facilitate the security tester to prioritize and evaluate the API assets. In addition, the IAST technology can also identify and collect encrypted requests and requests of distributed micro services, whether it is symmetric encryption or asymmetric encryption, whether it is a monolithic application or a micro service architecture, the API and data information of the plaintext can be acquired through the insertion of the encryption and decryption functions and the micro service nodes, and the coverage of API detection is improved. At the same time, the IAST technology can also collect business request messages in combination with functional testing, which can avoid the cognitive defects of the security tester, such as ignoring some edge scenarios or hidden function APIs, resulting in missed vulnerabilities. Finally, the IAST technology can also realize request cross-service full-link tracking, which can clearly see the source, destination, parameters, response and other information of each message request, and maximize the comprehensiveness of security testing.

[0076] In the embodiment, the application running process can refer to the process of performing functional testing on the application in the functional testing stage. After the functional tester triggers the business request message, the application will respond to the business request message. In the interaction process of the request and the response, the request execution information can be acquired through the IAST technology.

[0077] The request execution information can be acquired through the insertion technology, and can specifically include request information, execution context and response content of the business request message. Further, the request information includes API interface, request parameter and identity certificate.

[0078] The IAST technology can use the insertion technology to insert some session functions of the web framework to acquire the execution context information. At the same time, login request identification, user session certificate information extraction, confirmation of login and logout request interfaces and session parameters, automatic login configuration information confirmation and extraction can be realized, which effectively reduces the labor cost. The IAST technology can also acquire the existing permission list of the application through the configuration information collection of the permission framework, automatically acquire user accounts of different roles, and realize automatic permission testing.

[0079] Step S220: According to the request execution information, the request message is arranged.

[0080] In the embodiment, the request flow of the application can be collected and combed through the IAST technology, the business request message processed by the application is rearranged, the business request line is constructed according to the time sequence, the normal operation flow of the user can be simulated, and the automatic privilege violation detection is realized.

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

[0082] Exemplarily, Figure 3 The working principle diagram of the business request message coding technology provided in the embodiment is shown in Figure 3 As shown, the message cleaning includes response exception state filtering, request type filtering and request behavior filtering. The session inference includes login request address inference, login configuration field inference, login session inference and login user association. The request encapsulation includes user-session association, user-request association, session pool creation and request encapsulation. The message replay includes building a traffic replay verification platform, constructing a verification strategy and collecting response information.

[0083] The message cleaning is mainly used for filtering the request message meeting the set filtering condition according to the set filtering condition. Specifically, the set filtering condition includes one or more of the following: application exception response exists, set request type is not met, and set request behavior requirement is not met. The request message meeting the condition is filtered out, so that the subsequent message modification is facilitated, and the message utilization rate and the message modification efficiency are improved.

[0084] Step S230: replacing the user association information in the rearranged request message with target test information to obtain a new request message.

[0085] In the embodiment, after the IAST privilege detection system rearranges the business request message, the user credentials in the business request message are automatically replaced by user credentials with the same or lower privileges, so that the final modification of the business request message is realized.

[0086] Exemplarily, in the replacement process, the user information needs to be set with privileges, such as setting the role weight of the user according to the privilege level, and then mapping the user list collected in each business request and test traffic, encapsulating the test traffic of the user with high weight into other users with low weight that do not exist in the mapping list, or encapsulating the test traffic of the users with the same weight into other users with different weights that do not exist in the mapping list.

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

[0088] Step S230: determining whether the application has a privilege violation based on the feedback information.

[0089] In the embodiment, by means of IAST technology, API interface mapping, taint data flow tracking, request re-arrangement, permission framework configuration collection, function call sequence collection, key function trigger awareness, etc. can be used to realize all-round awareness of API assets and request behavior of the application program.

[0090] The similarity can be obtained by comparing the feedback information and the request execution information returned by the original request message, and the higher the similarity, the more likely there is an unauthorized vulnerability.

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

[0092] The application embodiment collects and sorts the request execution flow information generated during the application running process, and then replaces the application request after re-arrangement to form a new request message, which can simulate the normal operation process of the user, realize the automatic unauthorized vulnerability detection, improve the detection efficiency, and improve the detection effect of the unauthorized vulnerability of the application.

[0093] Further, in some embodiments, in the actual scene, when collecting and sorting the business request message, considering that the business request message is directly stored without processing, which may occupy a large memory space. Therefore, after filtering part of the business request message that meets the set filtering condition, the remaining business request message can be stored by the following steps for subsequent replay. Specifically, Figure 4 The application embodiment and the provided business request message processing method flowchart are shown in Figure 4 The steps include:

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

[0095] Step S420: concatenating the uniform resource identifier, request header, request body, response status code, response header, and response body field in each request message to obtain a to-be-processed string;

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

[0097] Step S440: store the unique hash value into a remote dictionary service (Redis) cache database. The unique hash value and the application identifier have a corresponding relationship.

[0098] Step S450: traverse and remove duplicates of all unique hash values stored in the cache database.

[0099] Step S460: store other information in each request message into a 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 the index field of the 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 K-V key-value pair form, 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 message digest obtained is of fixed length, thereby facilitating 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 occupy storage space.

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

[0103] 1. Filter pictures, pages (including js / css / html), and some response status code abnormal requests. These contents usually do not involve business logic or are not normal business requests, and do not need to be arranged for subsequent replay testing. Filtering out can save network bandwidth and storage space.

[0104] 2. Concatenate the uniform resource identifier (URI) of the service request message, the request header, the request body, the response status code, the response header, and the response body field to obtain a to-be-processed string. The request URI, the request body, and the response body can be filtered by adding configurations.

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

[0106] 4. Store the hash value generated by the service request message into the Redis cache database as the V value of the K-V key-value pair, and store the universally unique identifier (UUID) of each application as the K value of the K-V key-value pair.

[0107] 5. The V value of the K-V key-value pair is traversed using the method provided by the Redis cache database, and each K-V element without repetition is added to the set, thereby obtaining a non-repetitive data set.

[0108] 6. The hash value generated by the service request message is used as the index field of the table, and the specific data of the service request message is stored in multiple column data of the MySQL table.

[0109] The embodiments of the present application can reduce the storage space occupied by the service request message by filtering, removing duplicates, and establishing key-value pairs. Finally, the hash value is used as the index field of the table, and the specific data of the service request message is stored in multiple column data of the MySQL table, which can facilitate subsequent quick retrieval and query of the desired service request message information, to realize the modification of the service request message and improve the automatic privilege escalation vulnerability detection effect.

[0110] On the basis of the above embodiments, the session inference process will be described in detail through some embodiments.

[0111] Among them, the session inference is mainly based on the request parameters in the request message to determine the user information and user session in the request message, and then associate the user information and session information of the same user. In this way, the subsequent replacement of user association information can be facilitated.

[0112] Among them, the user association information can refer to the user information and the session information associated with the user information.

[0113] In this embodiment, after the service request message is cleaned through the above message cleaning, the login state, session information and user identity of the user can be inferred according to the request parameters in the service request message.

[0114] Among them, the session inference mainly uses the features in the service request message, such as the / login in the URI, the set-cookie information in the response header, etc. for rule analysis, to realize automatic login configuration recognition, user session recognition and user information recognition, and improve the efficiency of privilege escalation detection.

[0115] Specifically, Figure 5 The session inference process provided by the embodiments of the present application is shown in Figure 5 As shown, it includes the following steps:

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

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

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

[0119] The username is usually input by the user during registration or login, and can be used to distinguish different users and user groups, and provide a basis for subsequent business request message processing.

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

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

[0122] On the basis of the above embodiment, the information replacement process will be described in detail in some embodiments.

[0123] In this embodiment, in order to realize privilege violation detection, the user in the original request message needs to be modified, for example, replaced by another user with lower permission, and then the modified request message is replayed. Wherein, the target user information and target session information need to be obtained from the target test environment by the security tester during the replacement, and then the session information and user information in the arranged request message are replaced by the target user information and target session information to obtain a new request message.

[0124] Wherein, the application permission of the target user is equal to or lower than the application permission of the user in the request message. During the replacement process, the user information obtained in the session inference stage needs to be set with permission, such as simply setting the role weight of the user from the permission level, and then mapping the user list collected in each request and test traffic, encapsulating the test traffic of the user with high weight into other users with low weight that do not exist in the mapping list, or encapsulating the test traffic of the users with the same weight into other users with different weights that do not exist in the mapping list.

[0125] In this embodiment, during the replacement of the information in the request message, further request encapsulation is needed to obtain the new request message that can be reused and replayed. Specifically, Figure 6 The request encapsulation process provided by the embodiment of the application is shown in the schematic diagram as Figure 6 The schematic diagram includes the following steps:

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

[0127] Step S620: Based on the session mapping, replace the session information in the message request. That is, according to the session information in the target test environment, update the session ID, token, Cookie, etc. in the message request to ensure the validity and consistency of the request.

[0128] Step S630: Based on the association relationship between the user and the request, replace the username in the message request. That is, according to the username in the target test environment, update the username in the request to simulate different users and user groups, and provide diversity and randomness for subsequent testing.

[0129] Step S640: Based on automatic session replacement, encapsulate the test request. That is, according to the above three steps, replace the session information and username in the original message request with the information in the target test environment, implement the modification of the business request message, obtain a new request message, and then reuse the replay.

[0130] The embodiments of the present application replace the user information and session information to modify the request message, which is equivalent to simulating the normal interaction operation process of the user and the application, can more comprehensively test the function points of the application, determine whether there is an unauthorized vulnerability, and solve the problem that the security tester manually triggers the detection of the business request message, which cannot cover all API interfaces, resulting in incomplete detection.

[0131] In addition, in some embodiments, some applications may increase the replay mechanism, and the same message after modification may not be able to be directly replayed (in the unauthorized detection process, after completing the information replacement, the application is often intercepted when passing through the signature verification function). This is mainly because the application end 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 end to perform signature verification through the signature verification function. Among them, the signature verification function is used to verify the digital signature. By receiving a request message as input, 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 returns a false value (False). For such applications configured with a replay mechanism, the signature verification result returned by the application's signature verification function needs to be forcibly modified to a valid value, so that the modified new request message can be replayed.

[0132] In the embodiment, the IAST technology can be used to instrument the signature verification function, modify the return value of the signature verification function, and force the return of a true value (True). Specifically, the IAST tool is used to dynamically analyze the signature verification function, find its location, parameters, return value, and the like, and then insert a code in the execution process of the signature verification function, which is used to modify the return value to a true value (True). In this way, no matter how the original request message is modified, the signature is considered correct, and thus the request is accepted.

[0133] In addition, in some security scenarios, the interaction data between the application and the user is encrypted. At this time, the IAST technology can be used to instrument the encryption and decryption function, the tracking of the encryption request message decryption process is performed by using the tracking of the tainted data and the data flow analysis technology, the original message information of the encrypted data is obtained, and the key-value pair of the data can be extracted according to the request format of the original message in the subsequent process, and the application interface information and the request data information in the encrypted message are identified.

[0134] The embodiment of the application can effectively cope with the application with the added anti-replay mechanism by forcibly modifying the signature verification result returned by the signature verification function of the application to a valid value, so as to implement the reuse and replay of the request message and improve the applicability of the privilege escalation vulnerability detection in complex scenarios.

[0135] The following describes in detail how to determine whether the application has a privilege escalation vulnerability through some embodiments.

[0136] Figure 7 The privilege detection system flowchart provided by the embodiment of the application is shown in FIG. 1, which mainly includes the following steps. Figure 7

[0137] 1. Java agent configuration. The security tester or the project team can configure and download the Java agent on the IAST privilege detection system and run the Java agent on the application to be tested.

[0138] 2. The functional tester performs functional testing, triggers the business request data packet, and the Java agent performs information collection without sensing. This includes API asset mapping, business request message analysis, and execution context sensing.

[0139] 3. The privilege escalation test module performs privilege escalation testing without sensing, arranges the message, and performs message replay.

[0140] 4. The privilege verification module tests the API interface to determine whether the privilege is escalated, and outputs the result.

[0141] 5. The security tester checks the detection result and confirms the part that needs to be verified again manually.

[0142] ​In the method, the fusion verification manner can be used to detect the privilege violation, and the privilege violation detection further includes the authentication function execution audit, the field list identification, and the behavior identification comparison in addition to the similarity comparison of the returned message. Figure 8 A privilege violation detection flowchart provided by the embodiment of the application is shown in FIG. 3. Figure 8 As shown in FIG. 3, the application program interface to be verified is first acquired. The IAST privilege violation detection system monitors the execution of the request message that needs to be detected for privilege violation according to the authentication function audit rule when the API asset is surveyed, and audits whether the corresponding API interface calls the authentication function. The authentication function can be configured by the security tester on the IAST privilege violation detection system. If not configured, the Java agent probe identifies the authentication function information according to the annotations, function execution return results, and the like during the application running. After the authentication function call determination is completed, the interface type of the application program interface is further determined.

[0143] When the interface type is the query type, it is determined whether the target field (i.e., the review field) exists in the feedback information. If the target field exists, it is determined whether the privilege violation exists according to 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] The judgment of the target field mainly identifies whether the sensitive field name exists in the message in the feedback information. Further, if the target field does not exist, the behavior identification step is performed to determine whether the privilege violation exists based on the request execution information and the feedback information.

[0145] When the review field list is configured, the field design and naming of the same application are similar or even consistent for different interfaces. The configuration mainly configures some sensitive fields of the user, such as the ID card field, the mobile phone field, the home address field, and the like. When the security tester does not perform the configuration, the IAST privilege violation detection system infers the corresponding field according to the business process of the application login.

[0146] In addition, in some embodiments, when the interface type is the operation type, the behavior identification step is performed. The behavior identification process mainly acquires at least one of the execution context, the key structured query statement, and the call chain in the request execution information, and then determines whether the target information matching the at least one of the execution context, the key structured query statement, and the call chain exists in the feedback information. If the target information exists, it is determined that the privilege violation exists.

[0147] When the API interface is the operation type, the execution context, the key structured query statement (Structured Query Language, SQL), and the call chain of the original message are identified and judged. The key SQL statement is consistent, and it can be determined that the privilege violation exists.

[0148] Finally, in some other embodiments, 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 further 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 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 privilege leakage; if the similarity is higher than the second similarity threshold (the value is relatively large, at least larger than the first similarity threshold), it is determined that there is a privilege leakage.

[0149] For example, when the API is a query type and there is no audit field list in the feedback information message, after excluding non-public interfaces, the consistency of the key SQL statement and the similarity of the returned message can be comprehensively judged. The similarity includes the response status code, if the status code is inconsistent, there is no privilege leakage.

[0150] For example, in addition to setting the first similarity threshold and the second similarity threshold, a plurality of similarity thresholds can be set to make a hierarchical judgment on the privilege behavior, for example, similarity threshold A, similarity threshold B and similarity threshold C are set, if the similarity is lower than the similarity threshold A, it is determined that there is no privilege leakage, and if the similarity is higher than the similarity threshold B and less than the similarity threshold C, it is determined that there is a privilege leakage suspicion, which needs to be further verified. If the similarity is higher than the similarity threshold C, it is determined that there is a privilege leakage.

[0151] The application embodiment detects the privilege leakage by using the fusion verification method, and in addition to comparing the similarity of the returned message, the authentication function execution audit, field list identification and behavior identification comparison are added, which can improve the accuracy of the privilege leakage detection and solve the problem of high false positive rate and false negative rate of the current semi-automatic privilege detection.

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

[0153] Figure 9 The structure schematic diagram of the application privilege leakage detection device provided by the present application is shown in FIG. 9, which comprises an information acquisition module 910, a message arrangement module 920, an information adjustment module 930, a message replay module 940 and a leakage detection module 950. Figure 9

[0154] ​The information acquisition module 910 is configured to acquire request execution information returned according to at least one request message in an application running process based on an interactive application security testing technology. The message arrangement module 920 is configured to arrange the request message based on the request execution information. The information adjustment module 930 is configured to replace user-associated information in the arranged request message with target test information to obtain a new request message. The message replay module 940 is configured to replay the new request message to the application to acquire feedback information of the application. The vulnerability detection module 950 is configured to determine whether the application has an unauthorized vulnerability based on the feedback information.

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

[0156] Optionally, the message arrangement further includes a message cleaning module configured to filter out a request message in the at least one request message that meets a set filtering condition, the set filtering condition including one or more of an application abnormal response, a set request type not being met, and a set request behavior requirement not being met.

[0157] Optionally, the message arrangement further includes a storage module configured to filter out irrelevant information in each request message; splice a uniform resource identifier, a request header, a request body, a response status code, a response header, and a response body field in each request message to obtain a to-be-processed string; acquire a unique hash value of the to-be-processed string based on digest information of the to-be-processed string; store the unique hash value in a cache database, the unique hash value and an application identifier having a corresponding relationship; iterate and remove duplicates of all unique hash values stored in the cache database; and store other information in each request message in a relational database management system.

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

[0159] Optionally, the message arrangement further includes a session inference module configured to determine user information and a user session in the request message based on a request parameter in the request message; and associate the user information and the session information of the same user.

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

[0161] Optionally, an application permission of the target user is equal to or lower than an application permission of a user in the request message.

[0162] Optionally, the packet replay module can be specifically configured to determine whether there is a signature verification behavior in the request packet; if there is a signature verification behavior, the signature verification result returned by the signature verification function applied when replaying the new request packet is modified to a valid value, the signature verification function is used to verify the signature validity of the request packet, and the application intercepts the request packet when it is verified that the signature is invalid.

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

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

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

[0166] The apparatus provided by the embodiments of the present application can be used to execute the method in the above embodiments, and has similar implementation principles and technical effects, which will not be described here in detail.

[0167] It should be noted that the division of the various modules of the above apparatus is only a logical functional division, and all or part of them can be integrated into one physical entity, or physically separated. These modules can all be implemented in the form of software invoked by a processing element; all can be implemented in the form of hardware; or some modules are implemented in the form of software invoked by a processing element, and some modules are implemented in the form of hardware. For example, the information acquisition module can be a separately established processing element, or can be integrated in a chip of the above apparatus, in addition, it can also be stored in the form of program code in the memory of the above apparatus, and the function of the above information acquisition module is invoked and executed by a processing element of the above apparatus. The implementation of other modules is similar. In addition, all or part of these modules can be integrated together, or can be independently implemented. The processing element here can be an integrated circuit with signal processing capability. In the implementation process, each step of the above method or each module can be completed by the integrated logic circuit of hardware or the instruction of software in the processing element.

[0168] Figure 10 The structure schematic diagram of the electronic device provided by the embodiment of the present application is shown in the figure. Figure 10 As shown in the figure, the electronic device 1000 includes at least one processor 1001, memory 1002, bus 1003 and communication interface 1004. Among them: the processor, the communication interface and the memory complete the mutual communication through the bus. The communication interface is used for communication 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 execution instruction stored in the memory, and can execute the related steps in the method described in the above embodiment.

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

[0171] The embodiment also provides a computer readable storage medium, and the computer readable storage medium stores computer instructions. When at least one processor of an electronic device executes the computer instructions, the electronic device executes the method provided by the various embodiments.

[0172] The embodiment also provides a computer program product, and the computer program product includes computer instructions stored in a readable storage medium. At least one processor of an electronic device can read the computer instructions from the readable storage medium, and the at least one processor executes the computer instructions to enable the electronic device to implement the method provided by the various embodiments.

[0173] In the present application, "at least one" means one or more, and "multiple" means two or more. The "and / or" describes the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can represent the following three cases: A exists alone, A and B exist together, and B exists alone, where A and B can be singular or plural. The character " / " generally represents an "or" relationship between the associated objects before and after it; in the formula, the character " / ", represents an "division" relationship between the associated objects before and after it. "At least one of the following" or similar expressions means any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c, can represent a, b, c, a-b, a-c, b-c, or a-b-c, where a, b, and c can be single or multiple.

[0174] A person of ordinary skill in the art can understand that all or part of the steps of the above-mentioned method embodiments can be completed by program instruction related hardware. 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, magnetic disc or optical disc and various storage medium 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, and not to limit them; although the present application has been described in detail with reference to the above embodiments, a person of ordinary skill in the art should understand that he or she can still modify the technical solutions recorded in the above embodiments, or make equivalent replacement for part or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. An application privilege-escalation vulnerability detection method, characterized by, The application comprises the following steps: Based on the interactive application security testing technology, the request execution information returned according to at least one request message during the application running process is obtained; According to the request execution information, the request message is arranged, which includes at least one of message cleaning, session inference and request encapsulation; The target user information and target session information provided in the target test environment are obtained, and the application permission of the target user is equal to or lower than the application permission of the user in the request message; The session information and user information in the arranged request message are replaced by the target user information and the target session information to obtain a new request message; The new request message is replayed to the application to obtain the feedback information of the application; The application program interface in the request execution information is obtained, and the interface type of the application program interface is determined, which includes query type and operation type; When the interface type is query type, it is determined whether the target field exists in the feedback information; If the target field exists, it is determined whether there is an unauthorized vulnerability according to 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 vulnerability based on the request execution information and the feedback information; When the interface type is operation type, at least one of the execution context, the key structured query statement and the call chain in the request execution information is obtained; It is determined whether the target information exists in the feedback information, which matches 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 there is an unauthorized vulnerability.

2. The method of claim 1, wherein, The message cleaning of the request message comprises the following steps: The request message in the at least one request message that meets the set filtering condition is filtered out, and the set filtering condition includes one or more of the following: existence of application exception response, non-compliance with set request type, non-compliance with set request behavior requirement.

3. The method of claim 2, wherein, After the message cleaning of the request message, the following steps are further included: Irrelevant information in each request message is filtered out, which includes at least one of static content and abnormal response information; The uniform resource identifier, request header, request body, response status code, response header and response body field in each request message are spliced to obtain a to-be-processed string; Based on the digest information of the to-be-processed string, the unique hash value of the to-be-processed string is obtained; The unique hash value is stored in the cache database, and the unique hash value and the application identifier have a corresponding relationship; All unique hash values stored in the cache database are iterated and de-duplicated; Other information in each request message is stored in a relational database management system, and the unique hash value of the request message is used as the index field of the other information.

4. The method of claim 1, wherein, The session inference of the request message comprises the following steps: Based on the request parameters in the request message, the user information and user session in the request message are determined; The user information and session information of the same user are associated.

5. The method of claim 1, wherein, The replaying the new request message by the application comprises: determining whether there is a signature verification behavior in the request message; if there is the signature verification behavior, modifying a signature verification result returned by a signature verification function of the application to a valid value when replaying the new request message, the signature verification function being used for verifying a signature validity of a request message, and the application intercepting the request message when verifying that the signature is an invalid value.

6. The method of claim 1, wherein, The determining whether there is the privilege-escalation vulnerability based on the request execution information and the feedback information comprises: when the interface type is the 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, determining that there is no privilege-escalation vulnerability; if the similarity is higher than a second similarity threshold, determining that there is the privilege-escalation vulnerability.

7. An off-the-shelf vulnerability detection apparatus characterized by comprising: comprise: an information obtaining module, configured to obtain request execution information returned according to at least one request message in an application running process based on an interactive application program security testing technology; a message arrangement module, configured to arrange a message of the request message according to the request execution information, the message arrangement comprising at least one of message cleaning, session inference, and request encapsulation; an information adjusting module, configured to obtain target user information and target session information provided in a target test environment; and replace session information and user information in the arranged request message with the target user information and the target session information to obtain a new request message, an application privilege of a target user being equal to or lower than an application privilege of a user in the request message; a message replaying module, configured to replay the new request message by an application to obtain feedback information of the application; a vulnerability detecting module, configured to perform the following operations: obtain an application program interface, determine an interface type of the application program interface, the interface type comprising a query type and an operation type; when the interface type is the query type, determine whether there is target field in the feedback information; if there is the target field, determine whether there is a privilege-escalation vulnerability according to a value of the target field, a field value of an original user of a request message, and a field value of a current user of the new request message; if there is no target field, determine whether there is a privilege-escalation vulnerability based on the request execution information and the feedback information; when the interface type is the operation type, obtain at least one of an execution context, a key structured query statement, and a call chain in the request execution information; determine 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 there is the target information, determine that there is the privilege-escalation vulnerability. comprise:

8. An electronic device, comprising: a processor, and a memory connected with the processor in communication; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory to implement the method in any one of claims 1 to 6. ​ 9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer-executable instructions, which, when executed by a processor, implement the method of any one of claims 1 to 6.

10. A computer program product, characterised in that, A computer program is included, which, when executed by a processor, implements the method of any one of claims 1 to 6.

Images