Over-authority vulnerability black box detection method based on cross-request data dependency tracking mechanism

Abstract

The invention discloses an unauthorized vulnerability black box detection method based on a cross-request data dependency tracking mechanism. The method is used for identifying identity verification and authorization security problems with vulnerabilities in network applications. According to the method, a cross-request data dependency tracking mechanism is introduced to deduce an operation dependency relationship between pages, analyze feedback content and judge whether unauthorized reading or modifying operation exists or not, so that the detection of unauthorized vulnerabilities is realized. The method comprises the following specific steps: preprocessing: preparing an initial address of a target website and registering accounts of a common user and an attacker; constructing a cross-request data dependency graph, and establishing a dependency relationship among different operation requests; and vulnerability detection: tracking an attacker request through the cross-request data dependency graph so as to judge whether a vulnerability exists or not. According to the method for detecting the unauthorized vulnerability through the black box, the recall rate, the accuracy rate and the automation degree of unauthorized vulnerability detection are improved, and an effective unauthorized vulnerability detection tool is provided for software security analysts.

Description

Technical Field

[0001] The present invention belongs to the technical field of open source software security problem detection, and specifically relates to a black box detection method for unauthorized vulnerabilities based on a cross-request data dependency tracking mechanism. Background Art

[0002] With the rapid development of web applications, more and more commercial platforms store large amounts of sensitive user privacy data, including identity and payment information, making them a prime target for attackers. To protect this data, developers typically implement access control mechanisms to prevent unauthorized operations. However, when these mechanisms are improperly configured or poorly designed, they can lead to Balance of Access (BAC) vulnerabilities.

[0003] While BAC vulnerability detection is currently a significant concern, the increasing severity of BAC vulnerabilities highlights the persistent lack of effective detection techniques. Existing detection methods can be broadly categorized as white-box and black-box. White-box methods suffer from significant limitations, including high false positive rates, an inability to generate proof-of-concept (PoC) samples, and scalability issues associated with static analysis techniques. To address these limitations, researchers have explored dynamic black-box scanning techniques (i.e., scanners), a widely used method for penetration testing and particularly effective in detecting real-world security vulnerabilities. Specifically, existing black-box detection techniques rely on a decision mechanism based on response similarity to detect BAC vulnerabilities. Specifically, a security analyst uses a scanner to set up attacker and victim user accounts. The scanner uses the attacker's credentials to send HTTP requests to access the victim's personal data. If the attacker receives a response similar to the victim's, a BAC vulnerability is reported. However, this decision mechanism suffers from significant inherent design flaws. The decision mechanism is a critical and fundamental component of a black-box scanner and plays a key role in determining the effectiveness of black-box vulnerability detection. Unfortunately, the reactive verification mechanism is based on a flawed assumption: a direct response to a BAC attack request always provides evidence indicating whether the attack was successful. This assumption holds true in scenarios where unauthorized data is leaked through read-based Broken Access Control (RBAC) vulnerabilities, as the leaked data is returned directly to the attacker via the HTTP response. However, this assumption fails in scenarios where unauthorized data is deleted through modification-based Broken Access Control (MBAC) vulnerabilities, as the direct HTTP response to the attack request does not necessarily indicate whether the unauthorized operation was successful. This flawed vulnerability verification approach results in high false positive and false negative rates in existing methods when detecting MBAC vulnerabilities. Summary of the Invention

[0004] In view of the limitations of various detection technologies in the above-mentioned existing technologies that are unable to effectively detect BAC vulnerabilities, the present invention proposes a new, accurate, comprehensive and automatic black-box detection method for unauthorized access vulnerabilities to identify authentication and authorization security issues with vulnerabilities in network applications; the present invention introduces a cross-request data dependency tracking mechanism for the first time, and effectively detects MBAC vulnerabilities including unauthorized modifications by inferring the operation dependencies and result feedback between pages, providing software security analysts with an effective unauthorized access vulnerability scanning tool.

[0005] The technical solution of the present invention is specifically described as follows.

[0006] A black-box detection method for privilege escalation vulnerabilities based on a cross-request data dependency tracking mechanism. The specific steps are as follows: (1) Preprocessing For the target web application, the website login interface is collected, and ordinary users and attackers are registered according to the website registration guide, and the accounts are stored in a certain format; (2) Building a cross-request data dependency graph Deeply explore the target web application's web pages using crawler technology to build a navigation graph that presents the target web application's page organization structure, and filter public pages based on page address and content; When exploring each page, we intercept modification requests and replace all parameter values ​​except structured parameters in the modification requests with unique pseudo-random strings. We then release the modification requests so that the requests with the pseudo-random strings can flow normally in the web application. Locate and modify status pages that have data dependencies on class requests and connect nodes in the navigation graph to build a cross-request data dependency graph; (3) Vulnerability detection By replaying the requests of ordinary users using the attacker's identity and using the dependency relationship provided by the cross-request data dependency graph to find the corresponding status page to determine whether the request is successful, it is possible to determine whether there is an unauthorized modification vulnerability.

[0007] In the present invention, in step (1), a structured data storage method is used to organize the URL of the login interface, form field information, account user name, and password information into a data structure that is easy to read and access.

[0008] In the present invention, in step (2), four types of operations are implemented based on crawler technology to explore the web pages of the target application, and the current page is connected to the newly discovered page through navigation edges, thereby forming a navigation graph of the target application; the nodes of the navigation graph represent individual web pages, and the edges capture the relationships between page nodes, indicating how one page navigates to another page; wherein: The four types of operations include: extracting a static web page address, submitting a form, processing an iframe frame, and triggering a JavaScript event handler, thereby forming a navigation graph of the target application.

[0009] In the present invention, in step (2), public pages are filtered out by analyzing the addresses of pages recorded in navigation maps of different users and whether there is any publicly accessible content.

[0010] In the present invention, in step (2), the modification request includes POST, PUT, and DELETE requests, wherein the structured parameters in the modification request include date and email address, and the pseudo-random string is a 6-digit random lowercase letter string.

[0011] In the present invention, in step (2), the strategic positioning status page is traversed through the layered navigation graph, as follows: The hierarchical navigation graph traversal strategy prioritizes pages that are more likely to be status pages by evaluating the "likelihood score" of each page. Once a page containing data dependencies is found, the traversal stops. The score calculation formula is as follows:

[0012] Where: Sim(m, r) in the formula represents the URL similarity between the modification request m and the candidate state request r, calculated using the Livingston distance algorithm; p i To modify the request parameters of request m, I(p i ∈r) means when the parameter p i The value is 1 when it appears in the content of request r, otherwise it is 0. n is the number of request parameters of modification request m; Dist(m, r) represents the distance between modification request m and candidate state request r in the navigation graph; w1, w2, and w3 are weight parameters; the higher S(m, r) is, the more likely request r is a state feedback request related to the modification operation.

[0013] In the present invention, in step (3), a cross-request data dependency relationship is constructed by connecting the nodes of the modification page and the status page in the navigation graph; at the same time, the type of the data dependency edge is determined according to the relationship between the pseudo-random string inserted in the modification page and the content in the status page, thereby completing the construction of the cross-request data dependency graph; the type of the data dependency edge includes INSERT, UPDATE or DELETE type, corresponding to INSERT, UPDATE or DELETE modification requests, respectively.

[0014] In the present invention, in step (3), the type of the data dependency edge is determined based on the relationship between the pseudo-random string inserted in the modification page and the content in the status page, including the following three cases: If the inserted random character appears in the status page, create an edge of type INSERT; If a random character appears and replaces the original value, an UPDATE type edge is established; If the random character disappears from the status page, create an edge of type DELETE; For multiple modification pages that operate on the same random character, they are grouped into a node cluster and the operation type is marked as INSERT / UPDATE / DELETE to support subsequent vulnerability detection.

[0015] In the present invention, in step (3), different replay strategies are adopted for different types of modification requests: INSERT and UPDATE modification requests are directly replayed to attempt to perform unauthorized insertion or update operations on the victim's data; for DELETE type, the page where the random string was initially inserted is located by utilizing the node cluster, and then the corresponding INSERT page is re-accessed to reinsert the random string data, and then the parameters of the DELETE request are adjusted to ensure that the target data can be deleted. In this way, the DELETE request is ensured to be successfully executed under a controllable data state.

[0016] In the present invention, in step (3), when detecting the unauthorized modification vulnerability, based on the dependency edges in the cross-request data dependency graph, the victim's identity is used to re-access the status page that has data dependency with the modification request, and the feedback results in these pages are observed to determine whether unauthorized data modification has occurred; for different modification types, the following judgment strategy is adopted INSERT type: If a new random string appears on the status page, it indicates that an unauthorized insertion has occurred, and it is determined that a modification type unauthorized vulnerability exists. UPDATE type: If the original random string disappears from the status page and a new random string appears, it indicates that an unauthorized update has occurred. DELETE type: If the original random string disappears from the status page, it is determined that the unauthorized deletion was successful.

[0017] Compared with the prior art, the present invention has the following beneficial effects: Based on a thorough exploration of the challenges of current unauthorized access vulnerability detection, this paper proposes a black-box unauthorized access vulnerability detection method based on a cross-request data dependency tracking mechanism, based on research on how to effectively identify potential data dependencies between pages. By designing a cross-request data dependency tracking mechanism to infer operational dependencies between pages and analyze feedback content, the present invention determines whether unauthorized modifications have occurred. This allows for accurate identification of data feedback between pages and accurate tracking of data flows between pages, thereby improving the accuracy, recall, and automation of unauthorized access vulnerability identification. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 This is a flowchart of the black box detection method for unauthorized vulnerability based on the cross-request data dependency tracing mechanism of the present invention.

[0019] Figure 2 Build algorithms for cross-page data dependency graphs.

[0020] Figure 3 An example graph is constructed for a cross-request data dependency graph in an embodiment. DETAILED DESCRIPTION

[0021] The present invention will be further described below by way of embodiments with reference to the accompanying drawings.

[0022] The present invention proposes a black-box detection method for privilege surviving vulnerabilities based on a cross-request data dependency tracing mechanism. First, pages are crawled as an attacker and a victim respectively, and a navigation graph is constructed to obtain the difference in permission access. Subsequently, a unique identifier is inserted into the victim's modification request, and a cross-request data dependency graph (cross-request data dependency graph) is constructed to capture the feedback relationship between the modification page and the status page. Finally, the victim's request is replayed as an attacker and combined with the status page feedback to detect modification-type privilege surviving vulnerabilities, thereby achieving comprehensive identification of privilege surviving vulnerabilities in Web applications.

[0023] The following are the definitions of the navigation graph and cross-request data dependency graph: Navigation graph definition: A navigation graph is a data structure widely used in traditional tasks such as web vulnerability scanning. It shows how pages in a web application access each other through navigation edges. Following existing research, this paper introduces the key components of a navigation graph: nodes and edges. A node represents a single web page, such as a login page. Web crawlers typically collect new accessible web pages by exploring previously visited pages. Edges capture the relationships between page nodes, indicating how one page navigates to another, which may be achieved through hyperlinks, event handling, form submissions, and other methods.

[0024] In this invention, n is used to represent a node in the navigation graph, and NE is used to represent a set of navigation edges. The formal definition of NE is as follows:

[0025] Definition of cross-request data dependency graph: The cross-request data dependency graph is built on top of the navigation graph. The cross-request data dependency graph connects page nodes through a new directed edge - inter-page data dependency edge (IDDE) to represent the data dependency relationship between web pages. Specifically, IDDE connects from the modification page node to its corresponding status page node. The modification page handles requests to change data, such as submitting an order; the status page handles requests to retrieve data and display it to the end user, such as listing an order. IDDE indicates that the data modified by the modification page can be displayed on the connected status page. In addition, IDDE records the type of modification performed on the data (i.e., INSERT, UPDATE, and DELETE), which helps to further analyze data dependencies. The formal definition of IDDE is as follows:

[0026] The present invention provides a black-box method for detecting unauthorized access vulnerabilities based on a cross-request data dependency tracking mechanism. The specific steps are as follows: (1) Preprocessing: Collect the website’s login interface, register accounts for ordinary users and attackers according to the website’s registration guide, and store them in a certain format.

[0027] (2) Constructing a cross-request data dependency graph: Using crawler technology to explore the target application's web pages, we construct a navigation graph and filter public pages based on page address and content. During the exploration of each page, we replace all parameter values ​​in the modification request (except for unstructured parameters such as date and email address) with a unique pseudo-random string. Then, we release the request and insert the pseudo-random string. Using a layered navigation graph traversal strategy, we locate the status page and connect the nodes in the navigation graph to construct cross-request data dependencies.

[0028] (3) Vulnerability detection: By replaying the request of an ordinary user using the attacker's identity and using the dependency relationship provided by the cross-request data dependency graph to find the corresponding status page to determine whether the request is successful, it is possible to determine whether there is an unauthorized modification vulnerability.

[0029] Each step is further described below.

[0030] 1. Preprocessing

[0031] This phase mainly focuses on collecting website login interface information and completing the registration and storage of normal user and attacker accounts. The specific steps are as follows: (1) Login interface collection: Use web crawler technology, web page parsing tools, and automated scripts to conduct a comprehensive detection of the target web application. Use crawler technology to traverse each page of the website and accurately locate the URL address of the login interface by identifying HTML tags, page structure features, and specific URL patterns (such as those containing keywords such as "login" and "signin"). At the same time, parse the HTML code of the login page to obtain the form field information required for login, including the name, ID or other identifier of the username and password input box, as well as the relevant attributes of the login button, to ensure the smooth progress of subsequent login operations.

[0032] (2) Account registration: Simulate the registration process of real users according to the registration guide provided by the target website. For ordinary user account registration, fill in the required information according to the website requirements, such as selecting a username that meets the format requirements, setting a complex password containing letters, numbers and special characters, and providing a valid email address or mobile phone number for verification (if the website requires this). During the registration process, follow the website's verification rules, such as checking the uniqueness of the username and password strength requirements, to ensure successful registration. For attacker account registration, also follow the website's registration process, but when filling in the information, record the relevant operation details for use in subsequent vulnerability detection.

[0033] (3) Data storage: The collected login interface information and the account information of successfully registered ordinary users and attackers are stored in a specific format. Using a structured data storage method, such as JSON or XML format, the login interface URL, form field information, account username, password and other information are organized into a data structure that is easy to read and access. This storage format facilitates the rapid acquisition of login information during the subsequent vulnerability detection process, thereby improving detection efficiency.

[0034] 2. Build a cross-request data dependency graph The process mainly includes steps such as navigation graph construction, page filtering, token insertion, and hierarchical traversal to build data dependencies. The specific steps are as follows: (1) Navigation graph construction and page filtering: With the help of advanced crawler technology, the interactive behavior of users in web applications is simulated to conduct in-depth exploration of the target application's web pages. The crawler comprehensively collects accessible page information by extracting static URL links in the page, automatically submitting forms, interacting with iframe elements in the page, and triggering JavaScript events (such as clicking buttons, scrolling pages, etc.). During the exploration process, the navigation relationship between pages is recorded, each page is regarded as a node, and the navigation paths between pages are regarded as edges, so as to construct a navigation graph and clearly present the page organization structure of the web application. At the same time, based on the address and content of the page, those pages that are publicly visible to all users (including ordinary users and attackers) are filtered out. By comparing the page content and URL when different users visit the same page, if the two are exactly the same, the page is determined to be a public page and excluded, ensuring that subsequent analysis focuses on non-public pages that may have vulnerabilities.

[0035] (2) Token insertion: During the exploration of each page, the present invention intercepts all modification requests (such as POST, PUT, and DELETE requests) in real time. For these requests, except for structured parameters (such as date, email address, etc.), the remaining parameter values ​​are replaced with a unique pseudo-random string (for example, a pseudo-random string of 6 lowercase characters such as "axdvhn" is generated). This pseudo-random string has a sufficiently high entropy and can effectively avoid being confused with other strings in the application. After the replacement is completed, the modification request is released, allowing the request with the pseudo-random string to flow normally in the web application, so as to track data dependencies later.

[0036] (3) Constructing data dependencies by traversing the layered navigation graph: For modification requests that insert pseudo-random strings, a layered navigation graph traversal strategy is used to locate the corresponding status page and construct cross-request data dependencies. A comprehensive scoring algorithm is designed to evaluate pages from multiple dimensions, including URL similarity, request parameter relevance, and the distance between pages in the navigation graph. In terms of URL similarity, the redirect URL that may exist in the intercepted modification request response is analyzed (which may be located in the "Location" field of the response header or in the response body). The similarity between the redirect URL and the URL of the visited page is calculated using the Livingston distance algorithm. The higher the similarity, the higher the score of the page. If the redirect URL is not included in the response, the URL of the modification page is used for comparison by default. For request parameter relevance, the parameter names are parsed from the modification request and checked to see if these parameters appear in the content of the visited page. If so, the corresponding indicator score is increased. Considering the distance between pages in the navigation graph, since the modification page and its corresponding status page are usually closely related in business logic, developers generally design them to be close to each other in the navigation graph. Therefore, pages closer to the modification page score higher. Based on the scoring results, pages with high scores are visited first. Once a status page with a data dependency relationship with the modification request is found (i.e., the inserted pseudo-random string appears or disappears from the page content), traversal stops immediately and the nodes of the modification page and status page are connected in the navigation graph to construct a cross-request data dependency relationship. Furthermore, based on the appearance or disappearance of the pseudo-random string on the status page, the type of data dependency edge (INSERT, UPDATE, or DELETE) is determined, completing the construction of the cross-request data dependency graph.

[0037] 3. Vulnerability Detection This process primarily involves replaying normal user requests and analyzing them using a cross-request data dependency graph to accurately determine whether access control vulnerabilities exist in web applications. The specific steps are as follows: (1) Request replay: Use the attacker's identity information (including the username and password obtained during registration) to log in to the web application and obtain the attacker's session credentials (such as session cookies). Based on the cross-request data dependency graph, find the request records sent by ordinary users to the modification page. Use the attacker's session credentials to replay these requests to the corresponding modification page. During the replay process, some situations that may cause the request to fail (such as the need for CSRF tokens, page state dependencies, etc.) are handled. For example, if the request requires a CSRF token, the present invention will trace back along the navigation graph to the previously visited page containing the token, obtain the token and add it to the replay request; for DELETE type modification requests, since the target data may have been deleted when the cross-request data dependency graph was constructed, causing the direct replay request to fail, the present invention will use the node cluster to locate the page where the relevant token was originally inserted, reinsert the token and adjust the parameters of the DELETE request (such as modifying the order ID, etc.) to ensure that the request can be successfully replayed.

[0038] (2) Vulnerability determination: Based on the dependency relationship provided by the cross-request data dependency graph, find the status page corresponding to the replayed modification request. Use the victim's (ordinary user's) session credentials to access the status page and obtain the page content. Determine whether there is a vulnerability based on the type of modification request and the changes in the status page content. For INSERT-type modification requests, if a new pseudo-random string inserted during the replay request appears in the status page, it indicates that an unauthorized insertion operation has occurred, and a vulnerability is determined to exist. For UPDATE-type modification requests, if a new pseudo-random string appears in the status page and the original related string disappears, it indicates that an unauthorized update operation has occurred, and a vulnerability is determined to exist. For DELETE-type modification requests, if the related pseudo-random string originally existing in the status page disappears, it indicates that an unauthorized deletion operation has occurred, and a vulnerability is determined to exist. In this way, with the help of the cross-request data dependency graph and the request replay mechanism, it is possible to accurately determine whether there is an access control vulnerability in the Web application.

[0039] Figure 1 The architecture of the present invention is presented, which consists of two key modules: Cross-request data dependency graph construction module: This module constructs a cross-request data dependency graph to represent the data dependency relationship between requests, thereby facilitating vulnerability detection.

[0040] A vulnerability detection module based on the cross-request data dependency graph initiates HTTP requests and uses the vulnerability verification mechanism of cross-request data dependency tracking and the response-based vulnerability verification mechanism to detect BAC vulnerabilities.

[0041] Cross-request data dependency graph construction (1) Construction of cross-request data dependency graph

[0042] Now we describe how the present invention constructs a navigation graph and connects IDDEs between pages. Figure 2 shown.

[0043] Page Exploration: This invention first uses a crawler to explore each web page to build a navigation graph. Following state-of-the-art crawler techniques, this invention explores web pages through four operations: extracting static URLs, submitting forms, interacting with iframes, and triggering JavaScript event handlers (such as clicks) within the page. This approach ensures a comprehensive exploration of the current web page. The invention then treats the pages generated by these operations as new page nodes and links them to the currently explored page via navigation edges. These edges represent how the operations facilitate navigation from one page node to another, thereby forming a navigation graph for the target application.

[0044] Token Insertion: While exploring each page, we intercept all incoming modification requests. We then replace all parameter values ​​in the request with unique tokens, except for certain structured parameters (such as date and email), and then release each intercepted request one by one. Specifically, we generate these unique tokens as pseudo-random strings of six lowercase characters, such as axdvhn. This randomness ensures sufficiently high entropy to prevent them from being mistaken for other strings in the application.

[0045] It's important to acknowledge that some data dependencies originate from structured data, such as email addresses. Simply replacing unstructured parameters with unique tokens might miss these relationships. However, pages with MBAC vulnerabilities often contain many unstructured parameters (such as usernames and addresses) that can be replaced. Therefore, we can leverage these parameters to establish data dependencies between pages without significantly impacting MBAC vulnerability detection.

[0046] Hierarchical navigation graph traversal: For each intercepted modification request that inserts a token, the present invention attempts to traverse the navigation graph to find the corresponding status page. A direct approach is to revisit all web pages to search for the status page, but this method is very time-consuming and impractical. Therefore, the present invention adopts a hierarchical traversal strategy to efficiently identify the corresponding status page, thereby establishing a data dependency. Specifically, the hierarchical strategy involves a comprehensive evaluation of all pages to prioritize revisiting the most likely pages. Once the first page that has a data dependency with the intercepted modification request is found, the traversal stops. This approach helps avoid indiscriminate traversal of all pages, thereby more efficiently identifying the status page that provides feedback.

[0047] To achieve this goal, we designed a scoring algorithm to assess the likelihood that a page will become a specific modified page status page. This algorithm considers multiple factors, including URL similarity, request parameter relevance, and distance from the intercepted modified page in the navigation graph. We then prioritize access to the page with the highest score. The scoring algorithm and its breakdown are detailed below: (1) URL similarity: The present invention analyzes the response to the intercepted modification request and attempts to extract the redirect URL provided in the response, which may appear in the response header (e.g., location: / order) or the response body (e.g., redirect: / order). This design choice is based on the following observation: developers tend to redirect users to a page that displays the modified data, i.e., a status page, after performing a modification operation. Since the redirect URL may contain various path parameters, causing direct URL matching to fail, the present invention utilizes the Livingston distance algorithm to evaluate the similarity between the redirect URL and the URL of the previously visited page (Sim(m,r) in Formula 1). Pages with higher similarity have higher scores. In addition, when no redirect information is found in the response, the present invention defaults to using the URL of the modified page as a substitute for the redirect URL.

[0048] Request parameters: Then, the present invention analyzes the parameters of the intercepted modified page (ie p i ) and the content of the previously visited page (i.e., the HTTP response). Specifically, as shown in formula (1), the present invention parses the parameter names from the modification request and checks whether they appear in the content of the visited page. If the parameters are found in the content, then I(p i ) is set to 1 if the result is not set, otherwise it is set to 0. This metric is reasonable. For example, consider a modification request containing an address parameter, and another page presents information related to the address. In this case, the data-reading page is more likely to have a data dependency with the modification request than the other page.

[0049] Navigation distance: Another key factor considered by the present invention is the distance between the previously visited status page and the intercepted modification page in the navigation graph, denoted as Dist(m, r). Modification pages and their corresponding status pages are typically closely related in terms of business functionality, and developers design them to minimize interaction, resulting in their placement relatively close together in the navigation graph. Therefore, the present invention assigns higher scores to pages that are closer.

[0050] IDDE connection: In the last step, the present invention establishes IDDE by analyzing the relationship between the tokens inserted by the modification page and the content of the re-accessed data read page. Specifically, according to the type of operation performed on the token, we divide IDDE into three types: 1) If the inserted token appears in the content of the read page, the present invention regards it as the corresponding status page and establishes an INSERT type edge between the two nodes. 2) If the inserted token is found in the read page and the previously existing token disappears, the present invention creates an UPDATE type edge. 3) If only the previously existing token disappears from the read page, the present invention forms a DELETE type edge. For modification page nodes that operate the same token, the present invention groups them into a node cluster and marks the modification type (i.e., INSERT, UPDATE, or DELETE) for each page to facilitate further BAC vulnerability detection.

[0051] (2) Build example We Figure 3 Taking an example, it is explained in detail how the present invention constructs a cross-request data dependency graph. Figure 3 A) in Figure 1 shows a web page that displays order data. The end user accesses this function through the / orderList path to view the orders she has submitted. Figure 3 Figure (b) shows the cross-request data dependency graph constructed from order data. The cross-request data dependency graph consists of three nodes, representing adding an order, viewing an order, and deleting an order. Specifically, we use the IDDE between the "Add Order" and "List Order" pages as an example to describe its construction process. Initially, during the page exploration phase, the present invention identifies that the "List Order" page can navigate to the "Add Order" page, thus connecting the two nodes using a navigation edge (black line). Subsequently, the present invention intercepts the order submission request, replaces the order address parameter with a pseudo-randomly generated token, and traverses the navigation graph to locate this inserted token. Finally, by observing and analyzing the token's behavior (such as its appearance or disappearance on the page), the present invention confirms that the token exists on the "List Order" page. Therefore, the present invention establishes an IDDE to represent the data dependency relationship between the "Add Order" and "List Order" pages (red line). Figure 3 Figure c) shows a node cluster for manipulating order data. This invention precisely identifies and marks the location of tokens within a webpage, enabling subsequent modifications to those tokens (e.g., insertions and deletions) to be grouped into a single operation cluster. The overall algorithm flow is attached.

[0052] (3) BAC vulnerability detection The BAC vulnerability detection process mainly includes two stages: modifying the vulnerability verification mechanism of request replay and cross-request data dependency tracking.

[0053] Modification Request Replay: The present invention attempts to use the attacker's session to replay the victim's request to modify the page in the cross-request data dependency graph, and replace the token in the parameter with a newly generated token. Since modification requests are usually POST or similar types, they often require a CSRF token, and directly replaying these requests may fail. To solve this problem, the present invention backtracks along the navigation edge to locate the previous data reading page of the target modification page. Then, starting from this reading page, the present invention performs relevant operations along the navigation edge, such as triggering event handlers and submitting forms, until the target modification page is successfully reached.

[0054] In addition, the present invention adopts different strategies to replay modification requests according to the operation type. For modification pages of INSERT and UPDATE types, it directly replays the request in an attempt to operate the victim's data without authorization. However, for modification pages of DELETE type, direct replay usually fails. This is because when building the cross-request data dependency graph, the target data related to the deletion page may have been permanently deleted. Therefore, replaying a request to delete non-existent data will cause a server error. For example, when building the cross-request data dependency graph, if a DELETE type request has deleted an order with the parameter OrderId=1, replaying the same request will fail because the order no longer exists and cannot be deleted again.

[0055] To address this issue, the present invention first leverages the node cluster to locate the page that originally inserted the token into the currently deleted page. It then revisits the corresponding INSERT-type page, reinserts the token into the application, and modifies the parameters of the replayed DELETE request to reference the newly inserted data (e.g., OrderId = 2). This approach ensures the successful replay of DELETE-type modification requests.

[0056] Vulnerability Verification Mechanism for Cross-Request Data Dependency Tracking: The present invention then locates the status page that has a data dependency relationship with the replayed modification request along the IDDE and uses the victim's session to revisit the status page to obtain feedback on whether the unauthorized modification was successful. Specifically, the present invention adopts different detection strategies based on the type of modification request.

[0057] For INSERT type operations, the presence of a new insert token on the status page serves as feedback that directly indicates the presence of an MBAC vulnerability. This feedback confirms that the scanner can observe unauthorized insert operations.

[0058] For UPDATE type operations, the appearance of a new token on the status page and the disappearance of the existing token indicates an MBAC vulnerability.

[0059] For DELETE type operations, the previously existing token on the status page disappears as evidence of the MBAC vulnerability.

[0060] For example, in Figure 3 In b), we use the victim's session to insert token A through the / addOrder modification page. The inserted token A can be viewed on the corresponding status page (i.e., / orderList). Next, we use the attacker's session to replace the value of the Address parameter with token B and replay the / addOrder request. Finally, we use the victim's session to revisit the / orderList status page and check whether token B exists. If token B is found, we report an MBAC vulnerability.

Claims

1. A black-box detection method for unauthorized access vulnerabilities based on a cross-request data dependency tracking mechanism, characterized in that: The specific steps are as follows: (1) Preprocessing For the target web application, the website login interface is collected, and ordinary users and attackers are registered according to the website registration guide, and the accounts are stored in a certain format; (2) Building a cross-request data dependency graph Deeply explore the target web application's web pages using crawler technology to build a navigation graph that presents the target web application's page organization structure, and filter public pages based on page address and content; When exploring each page, we intercept modification requests and replace all parameter values ​​except structured parameters in the modification requests with unique pseudo-random strings. We then release the modification requests so that the requests with the pseudo-random strings can flow normally in the web application. Locate and modify status pages that have data dependencies on class requests and connect nodes in the navigation graph to build a cross-request data dependency graph; (3) Vulnerability detection By replaying the requests of ordinary users using the attacker's identity and using the dependency relationship provided by the cross-request data dependency graph to find the corresponding status page to determine whether the request is successful, it is possible to determine whether there is an unauthorized modification vulnerability.

2. The black box detection method for unauthorized access vulnerability according to claim 1 is characterized in that: In step (1), a structured data storage method is used to organize the URL of the login interface, form field information, account username, and password information into a data structure that is easy to read and access.

3. The black box detection method for unauthorized access vulnerability according to claim 1, characterized in that: In step (2), four types of operations are implemented based on crawler technology to explore the web pages of the target application, and the current page is connected to the newly discovered page through navigation edges, thereby forming a navigation graph of the target application; the nodes of the navigation graph represent individual web pages, and the edges capture the relationships between page nodes, indicating how one page navigates to another page; wherein: The four types of operations include: extracting a static web page address, submitting a form, processing an iframe frame, and triggering a JavaScript event handler, thereby forming a navigation graph of the target application.

4. The black box detection method for unauthorized access vulnerability according to claim 1, characterized in that: In step (2), public pages are filtered out by analyzing the addresses of pages recorded in the navigation graphs of different users and whether there is any publicly accessible content.

5. The black box detection method for unauthorized access vulnerability according to claim 1 is characterized in that: In step (2), the modification request includes POST, PUT, and DELETE requests, wherein the structured parameters in the modification request include date and email address, and the pseudo-random string is a 6-digit random lowercase letter string.

6. The black box detection method for unauthorized access vulnerability according to claim 1, characterized in that: In step (2), the strategy positioning status page is traversed through the layered navigation graph as follows: The hierarchical navigation graph traversal strategy prioritizes pages that are more likely to be status pages by evaluating the "likelihood score" of each page. Once a page containing data dependencies is found, the traversal stops. The score calculation formula is as follows: ， Where: Sim(m, r) in the formula represents the URL similarity between the modification request m and the candidate state request r, calculated using the Livingston distance algorithm; p i To modify the request parameters of request m, I(p i ∈r) means when the parameter p i The value is 1 when it appears in the content of request r, otherwise it is 0. n is the number of request parameters of modification request m. Dist(m, r) represents the distance between modification request m and candidate state request r in the navigation graph. w1, w2, and w3 are weight parameters. Finally, the higher S(m, r), the more likely request r is a state feedback request related to the modification operation.

7. The black box detection method for unauthorized access vulnerability according to claim 1, characterized in that: In step (3), a cross-request data dependency relationship is constructed by connecting the nodes of the modification page and the status page in the navigation graph. At the same time, the type of the data dependency edge is determined according to the relationship between the pseudo-random string inserted in the modification page and the content in the status page, completing the construction of the cross-request data dependency graph. The data dependency edge type includes INSERT, UPDATE, or DELETE.

8. The black box detection method for unauthorized access vulnerability according to claim 7, characterized in that: The type of data dependency edge is determined based on the relationship between the pseudo-random string inserted in the modification page and the content in the status page. There are three cases: If the inserted random character appears in the status page, create an edge of type INSERT; If a random character appears and replaces the original value, an UPDATE type edge is established; If the random character disappears from the status page, create an edge of type DELETE; For multiple modification pages that operate on the same random character, they are grouped into a node cluster and the operation type is marked as INSERT / UPDATE / DELETE to support subsequent vulnerability detection.

9. The black box detection method for unauthorized access vulnerability according to claim 7, characterized in that: In step (3), different replay strategies are adopted for different types of modification requests: INSERT and UPDATE modification requests are directly replayed to attempt to perform unauthorized insertion or update operations on the victim's data; for DELETE type, the node cluster is used to locate the page where the random string was originally inserted, and then the corresponding INSERT page is revisited to reinsert the random string data. Then, the parameters of the DELETE request are adjusted to ensure that the target data can be deleted. In this way, the DELETE request is successfully executed under a controllable data state.

10. The black box detection method for unauthorized access vulnerability according to claim 7, characterized in that: In step (3), when detecting the unauthorized modification vulnerability, based on the dependency edges in the cross-request data dependency graph, the victim's identity is used to re-access the status pages that have data dependencies with the modification request, and the feedback results in these pages are observed to determine whether unauthorized data modification has occurred. For different modification types, the following judgment strategies are adopted: INSERT type: If a new random string appears on the status page, it indicates an unauthorized insertion, which is considered a modification type unauthorized vulnerability. UPDATE type: If the original random string disappears from the status page and a new random string appears, it indicates an unauthorized update. DELETE type: If the existing random string disappears from the status page, it is determined that the unauthorized deletion was successful.

Images