Access control vulnerability detection method based on RBAC mode Web application security

Abstract

The invention discloses an access control vulnerability detection method based on RBAC mode Web application security, and particularly relates to the technical field of authority management and Web security. Obtaining access control log data during the running period of the Web application; constructing a cross-session time sequence RBAC role inheritance graph and dynamically labeling a resource access set of each role; performing time sequence consistency verification on the inheritance graph path, and extracting a ghost path sub-graph which has permission conduction but lacks an authorization record; constructing an access behavior context graph model in combination with resource call stack information, and identifying semantic deviation abnormal node pairs by using a graph attention mechanism; performing a behavior replay test on the abnormal path node pair, judging whether an unauthorized access success event exists or not, and generating a vulnerability report; according to the method, the problem of access control failure caused by role inheritance relation mismatching or dynamic access chain abnormity can be recognized on the premise of not depending on an existing vulnerability template, and the method has the advantages of being fine in detection granularity, wide in application range and high in interpretability.

Description

Technical Field

[0001] This invention relates to the fields of access control and web security technology, specifically to a method for detecting access control vulnerabilities in web applications based on the RBAC model. Background Technology

[0002] As web-based application systems become increasingly complex, access control has become a crucial mechanism for ensuring system security. Role-based access control (RBAC), due to its flexible permission allocation and ease of management, is widely used in sensitive sectors such as government, finance, and healthcare. However, traditional RBAC models primarily cater to static organizational structures and clearly defined role and permission boundaries, making it difficult to effectively address the dynamic inheritance of permissions, polymorphic resource binding, and temporary identity authorization characteristics of dynamic web application environments. This leads to deviations in the "role-permission" mapping during actual operation.

[0003] Especially in multi-tenant or microservice architectures, different service modules often quickly authorize access permissions through token-based or session-based mechanisms. When there are abnormal states such as "role inheritance chain misconfiguration" or "residual binding of roles across contexts" in the RBAC model, it may cause "phantom access" problems: that is, the originally unauthorized session entity obtains indirect access permissions through legacy or propagation paths, forming highly concealed and highly harmful access control vulnerabilities.

[0004] Most current access control detection methods are based on static configuration file analysis, which cannot cover the dynamic mapping process of role permissions at runtime. Some dynamic analysis methods rely on attack sample libraries or known vulnerability templates, lack the ability to detect zero-day vulnerabilities such as "inheritance chain pollution", and are difficult to achieve fine-grained behavior modeling and abnormal path identification of RBAC systems in real web operating environments. Summary of the Invention

[0005] The purpose of this invention is to provide a method for detecting access control vulnerabilities in web applications based on the RBAC model, in order to address the shortcomings of the prior art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a method for detecting access control vulnerabilities in web application security based on RBAC mode, comprising: Retrieve access control log data generated by the web application during runtime; Based on the access control log data, an inheritance graph of cross-session time-series RBAC roles is constructed. The inheritance graph has role nodes as vertices and inheritance relationships between roles as edges. The actual resource access set of each role node is dynamically labeled in combination with the user request sequence. The path between nodes in the inheritance graph is verified for temporal consistency, and potential ghost path subgraphs with permission transmission but lacking explicit authorization records are extracted to form an abnormal access path feature set. The abnormal access path feature set is used as input, and an access behavior context graph is constructed by combining it with resource call stack information. The graph attention mechanism is used to identify abnormal path node pairs with high semantic bias. The identified abnormal path node pairs are subjected to behavior replay tests to simulate cross-role resource access scenarios in a real web environment. The test determines whether there are unauthorized access success events. If so, the abnormal path and related role nodes are recorded. Based on the user identity and successful resource access events corresponding to the abnormal path, an access control vulnerability report is generated.

[0007] Preferably, constructing an inheritance graph of cross-session temporal RBAC roles includes: The access control log data is clustered according to user identity, and the role allocation information and request target resource sequence of the same user in multiple sessions are extracted to form a cross-session access behavior trajectory. Based on the time sequence of role changes and resource access context in the cross-session access behavior trajectory, inheritance edges between role nodes are generated, and a directed graph structure with role nodes as vertices and inheritance relationships between roles as edges is constructed.

[0008] Preferably, the step of verifying the temporal consistency of paths between nodes in the inheritance graph includes: Based on all reachable paths in the role inheritance graph, construct a time series set of each role node on each path, and extract the earliest authorized time and the last active time of node access behavior; Perform time window constraint checks on each path to determine whether the access times of each role node in the path are continuous and do not violate the time increment rule, and remove paths with time discontinuity. For paths that pass the time-series verification, the access control logs are further compared. If the authorization behavior of the path's endpoint node is not explicitly authorized in the logs, it is marked as a potential ghost path. Extract all character sequences marked as potential ghost paths and their connections into a subgraph to form a potential ghost path subgraph.

[0009] Preferably, constructing the access behavior context graph includes: Based on the role nodes and resource nodes in the abnormal access path feature set, a heterogeneous graph structure is constructed, in which access edges are established between role nodes and resource nodes, inheritance edges are established between role nodes, and call depth, execution order and timestamp are added to the edges in combination with call stack information to form a context graph containing semantic behavior information.

[0010] Preferably, the method of identifying anomalous path node pairs using graph attention mechanisms includes: For each role node and resource node in the context graph, construct a multi-dimensional feature vector, input the graph attention network model, calculate the edge weight attention coefficient between nodes, and output the semantic deviation metric between node pairs by embedding. Use cosine similarity as the evaluation index, and identify abnormal path node pairs whose deviation exceeds the preset range based on the semantic deviation threshold.

[0011] Preferably, the behavior replay test for the identified abnormal path node pairs includes: Construct a set of simulated access requests based on abnormal role nodes and resource nodes; In a controlled web testing environment with isolated deployment, requests are scheduled and executed one by one according to the access time order, and the response status code, response body content and resource access results are recorded. If the access response status code is of the successful access type and the resource returned content is consistent with the authorized access result, and the access control log lacks a formal authorization record for the role, it is considered an unauthorized successful access event and recorded as an abnormal path.

[0012] Preferably, the access control log data includes user identity identifier, role allocation information, requested target resource, request timestamp, and authorization result.

[0013] The technical effects and advantages provided by the present invention in the above technical solution are as follows: 1. This invention, by introducing runtime behavior data-driven inheritance graph modeling and context graph semantic analysis, can effectively identify ghost path access control vulnerabilities in RBAC mode caused by dynamic role evolution, incorrect inheritance chain configuration, or ambiguous access control boundaries. Compared to traditional detection methods based on static permission rules or policy templates, this invention combines time-series consistency verification and access log data tracing analysis, does not rely on existing vulnerability samples, and has the ability to discover zero-day access control vulnerabilities, significantly improving the comprehensiveness of vulnerability detection.

[0014] 2. This invention constructs an access behavior context graph and introduces the graph attention mechanism from graph neural networks. This enables accurate identification of abnormal node pairs with high semantic discrepancies between roles and resources. Automated behavior replay testing verifies the authenticity of access results, thus achieving a closed-loop processing flow of detection, verification, and reporting. This solution possesses good versatility and deployability, and can be widely applied to various scenarios involving permission auditing, security compliance, and access control optimization in web applications and microservice architectures. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0016] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] For examples, please refer to Figure 1 As shown in this embodiment, the access control vulnerability detection method for web application security based on RBAC mode includes: Retrieve access control log data generated by the web application during runtime.

[0019] In this embodiment of the invention, a runtime monitoring proxy module deployed in the web application server first collects access control-related data generated during the web application's operation in real time. This module is embedded into the application access control framework (such as Spring Security, Shiro, RBAC middleware, or a custom permission module) in a "transparent implantation" manner, and obtains accurate access control behavior data by intercepting the request authorization processing flow.

[0020] The access control log data refers to the behavioral logs recorded by the web application in response to user access requests, which are related to access permission determination. These logs mainly include, but are not limited to, the following fields: User Identifier: Used to uniquely identify the user entity that initiated the request, and can be an account ID, login credential number, token binding UID, etc.; Role assignment information: This indicates the set of roles that the user has been granted by the system in the current access context, including basic roles and inherited roles obtained through the inheritance chain; Requested target resource: refers to the resource identifier that the user requests to access, which can be a URL path, API interface number, microservice resource tag, database object, etc. Request timestamp: Accurately records the time when the access request was initiated, which is used to subsequently build access behavior sequences and time window constraints; Authorization result: The access control decision made by the system for this access request, including results such as "Allow" or "Deny".

[0021] In addition, to ensure the credibility and integrity of log data, the present invention may optionally perform hash signature and timestamp marking on the collected log data, and form an "access log chain" through a chain structure to prevent the logs from being tampered with in subsequent processing, thereby enhancing the traceability and legal compliance capabilities of vulnerability detection and analysis.

[0022] Based on the access control log data, an inheritance graph of cross-session time-series RBAC roles is constructed. The inheritance graph has role nodes as vertices and inheritance relationships between roles as edges. The actual resource access set of each role node is dynamically labeled in combination with the user request sequence.

[0023] To construct a temporal and structured role inheritance graph, clustering is first performed based on access control log data. Access control log data includes fields such as user identity, role assignment information, requested target resource, request timestamp, and authorization result. Each log record represents an access control interaction between a user and the system, and its structure can be represented as a six-tuple: ⟨User ID, Role ID, Resource ID, Timestamp, Access Result, Session ID>; where the "Session ID" is used to distinguish consecutive access operations within a single login cycle. The specific implementation is as follows: User behavior clustering: A hash-based grouping algorithm is used to group log data by "user identifier" to obtain a complete set of access behaviors for each user; In-session sorting: Sort each user's access records in ascending order by "timestamp" to construct a time-series access trajectory; Behavior triple extraction: Extract the "role identifier", "resource identifier" and "timestamp" fields from each access record to form an access triple; Trajectory Formation: The access triples of each user in different sessions are concatenated to generate a cross-session access trajectory chain for subsequent role evolution analysis.

[0024] This trajectory chain preserves the user's role change behavior caused by factors such as identity changes, module switching, and session renewal in the real environment, and is an important basis for identifying potential inheritance relationships.

[0025] Based on the access trajectory chain constructed above, the temporal evolution relationship and resource access overlap relationship between roles are further analyzed to construct a role inheritance graph. The principles for constructing inheritance relationships are as follows: If a user plays two different roles at different times, and there is a temporal sequence of "role A → role B", and the resources accessed by the two roles overlap or are accessed consecutively, then a potential role inheritance path exists between role A and role B. This inheritance path is represented by a directed edge, with the direction pointing from the first assigned role to the second assigned role, representing the potential logical path for permission transfer. The specific implementation steps are as follows: Time window definition: Set a threshold Δt for the role change judgment interval (e.g., 15 minutes). If the time interval between two role change behaviors is less than Δt, the change is considered a continuous permission evolution behavior; Resource overlap calculation: The resource access overlap R_overlap is defined as: R_overlap = (resource set of role A ∩ resource set of role B) ÷ (resource set of role A ∪ resource set of role B). When R_overlap ≥ 0.3, the access intentions of the two roles are considered to have logical continuity. Inherited edge generation: When the above two conditions are met, construct a directed edge edge(A,B) and record the edge weight as (behavior frequency × resource overlap). Graph structure definition: Combine all role nodes with inherited edges to form a directed graph structure G=(V,E), where V represents the set of role nodes and E represents the set of inherited edges between roles; Edge denoising: To avoid interference from random behavior, an edge weight threshold T_edge (e.g., 0.2) is set, and edges with weights lower than T_edge are removed to enhance the credibility of the graph structure.

[0026] This role inheritance graph not only reflects the "explicit role inheritance" that may exist in the access control structure, but also captures the "implicit permission transfer" path caused by dynamic identity changes during system operation.

[0027] To enhance the semantic information of the role inheritance graph, each role node needs to be labeled with the set of resources it has actually visited, for subsequent path analysis and access behavior inversion. The specific steps are as follows: Resource mapping initialization: Create a resource access set S_resources(R) for each role node, and initialize it as an empty set; Reverse mapping of access records: Iterate through the triple ⟨role identifier, resource identifier, timestamp> for each access record, and add the resource identifier to the resource set of the corresponding role; Sliding time window constraint: Introduce a time window sliding parameter W_t (e.g., set to 30 minutes) to limit the effective time range of resource labeling and prevent abnormal sessions from affecting the distribution of resource labels for a long time; Low-frequency resource filtering: To improve the discrimination capability, a minimum access frequency threshold F_min (e.g., set to 5 times) is used to remove resource identifiers below this threshold from the set, retaining only the most frequently accessed resources and avoiding noise pollution in role representation; Set merging process: Merge the resource sets accessed by the same role in different users or sessions to form a unified and highly representative role resource set.

[0028] Once the annotation is complete, each node in the role inheritance graph will have a clear resource access set attribute, which will facilitate the subsequent identification of overlapping access targets between roles and the rationality of permission transfer.

[0029] The path between nodes in the inheritance graph is verified for temporal consistency, and potential ghost path subgraphs with permission transmission but lacking explicit authorization records are extracted to form an abnormal access path feature set.

[0030] To perform temporal consistency verification, all reachable paths in the role inheritance graph are first traversed, and a set of node time series is constructed for each path. The specific method is as follows: Path definition and extraction: In the role inheritance graph, each path is defined as an ordered set of role nodes (R1, R2, ..., Rn), where R1 represents the starting role of the path, Rn represents the ending role of the path, and the directed edges of the path represent the inheritance direction. Access time extraction: For each role node Ri in the path, query the access control log data and extract the set of authorized timestamps from all access records corresponding to that role, which is defined as T(Ri); Time range calculation: For each role node Ri, calculate the earliest authorized time T_min(Ri) and the last active time T_max(Ri) for the timestamp set T(Ri). Then take the minimum and maximum values ​​in T(Ri) as the time boundary of the node on the path. Time series construction: Combine the T_min and T_max of each role node on each path in node order to form a path-level time series for subsequent continuity verification.

[0031] Through the above operations, each reachable path is transformed into a set of character sequences with time boundaries, realizing the temporal modeling of character behavior.

[0032] To ensure the temporal logic of the role inheritance path, a time consistency verification needs to be performed on the above path's time series. The specific steps are as follows: Set the maximum time interval threshold ΔT_max (e.g., set it to 60 minutes) to represent the longest allowed interval for role permission transfer behavior; For adjacent role nodes Ri and Ri+1 in the path, if the last active time T_max(Ri) of Ri is less than or equal to the earliest authorized time T_min(Ri+1) of Ri+1, and the time interval between them does not exceed ΔT_max, then the transmission of this segment is considered to be time-consistent. If there exists any pair of adjacent nodes whose time interval is greater than ΔT_max or if time inversion occurs (i.e., T_max(Ri) is greater than T_min(Ri+1)), then the path is marked as having a "temporal discontinuity". All paths with temporal discontinuities were removed from subsequent analyses, and only "continuous role evolution paths" that have been verified over time were retained.

[0033] This step ensures that role inheritance occurs within an acceptable timeframe, avoiding misjudgments caused by abnormal role jumps across sessions.

[0034] For paths that pass time verification, further comparison of authorization records is performed on the roles at the path endpoints to identify potential ghost access behavior.

[0035] For each verified path, the last role node Rn is taken as the path's endpoint role. In the access control log, use the user identity and role identity as a combined index to search for whether there is an explicit authorization record, that is, a record in which the user was officially assigned the role Rn by the system within a specific time period; If no role assignment behavior for role Rn is found in the user's access history, but the user has indeed accessed resources associated with Rn and there is a derivation path for Rn in the path, then the role is considered to be a role that has "gained access without authorization". The path containing the endpoint role is marked as a potential ghost path, and the user ID, role chain, time series and resource access behavior corresponding to the path are recorded.

[0036] This step is used to capture abnormal paths where the permission propagation layer is interrupted but the user still gains access, demonstrating strong zero-day vulnerability detection capabilities.

[0037] After identifying all potential ghost paths, to support further visualization analysis and vulnerability report generation, these paths need to be extracted into independent graph structures, forming a potential ghost path subgraph. The specific implementation is as follows: For each potential ghost path, extract all the role nodes involved and the resource access nodes at the path's endpoint, and use them as a set of nodes for the subgraph. The inheritance relationships between roles in the path are used as the edge set of the subgraph, and "access edges" are added between the endpoint role and its accessed resources to enhance the semantic representation. Add label attributes to each subgraph, including user identity, path start and end time, ghost role marker, resource access record summary, etc. All potential ghost path subgraphs are grouped into a set and used as input for subsequent behavior replay testing and risk level assessment.

[0038] This subgraph set clearly depicts the structured path of abnormal access behavior, which helps to accurately locate and verify hidden vulnerabilities in the RBAC inheritance chain.

[0039] The abnormal access path feature set is used as input, and an access behavior context graph is constructed by combining it with resource call stack information. The graph attention mechanism is then used to identify abnormal path node pairs with high semantic bias.

[0040] To further analyze abnormal access paths from a structural and semantic perspective, an access behavior context graph is first constructed based on the extracted abnormal access path feature set and resource call stack information. The specific implementation steps are as follows: Two key elements in the access behavior are defined as nodes in the graph model: one is the "role node", which represents each role identifier that appears in the abnormal path; the other is the "resource node", which represents the specific target resource being accessed, including interface paths, database entities or microservice resource tags. Establish "access edges" between role nodes and resource nodes to represent the actual access behavior of a role to a resource; establish "inheritance edges" between role nodes to represent the permission propagation path identified in the inheritance graph; When constructing the edge structure, runtime resource call stack information is introduced, and the call depth and call order are used as the attribute information of the edge to reflect the context position of the role's access path to resources in the internal call structure of the system. The resulting context graph is a heterogeneous graph structure containing two types of nodes (role nodes and resource nodes) and two types of edges (access edges and inheritance edges). Each edge also includes context attributes such as call sequence number, call depth, and access timestamp.

[0041] This context graph not only represents the static access relationships between roles and resources, but also reflects the dynamic contextual characteristics of the access path at the program execution level by introducing call stack information.

[0042] After constructing the context graph, to identify key roles and resource pairs in abnormal paths, it is necessary to introduce the graph attention mechanism from graph neural networks for feature learning. The specific steps are as follows: Node feature construction includes: Role node feature vector: includes the number of permissions a role possesses, average access frequency, number of user identities it belongs to, average call stack level, etc. Resource node feature vectors include the number of times the resource has been accessed, the call depth, the type of the module to which it belongs, and the distribution of return status codes. All features are normalized to form an initial feature matrix with uniform dimensions, which serves as the input to the graph neural network. Graph attention mechanism definition: Introducing a graph attention network structure, and introducing learnable attention weights when aggregating features for each node in the graph; For each node, the information of its neighboring nodes is aggregated in a weighted form, with the weights calculated from the edge attributes and feature similarity between the nodes; The weighting function adopts a dot product-based scoring mechanism and is normalized by the softmax function to form the final attention coefficient matrix. The objective function is defined as maximizing the identification of semantic deviation between node pairs, that is, strengthening the identification of nodes whose behavioral characteristics deviate significantly from normal roles or resources in abnormal paths; Using known ghost path nodes in the labeled data as training samples, the parameters of the graph attention network are optimized by minimizing the classification loss function.

[0043] After the graph attention network is trained, the node embedding vectors it outputs are used to identify node pairs with high semantic bias. The steps are as follows: Input all the role nodes and resource nodes in the context graph into the graph attention network, and output a high-dimensional embedding vector for each node; Construct a set of role-resource node pairs across all roles and resource nodes, and calculate the semantic deviation value between each pair of nodes; Cosine distance is used as a semantic difference measure to calculate the angle between the character node vector and its corresponding resource node vector. The larger the value, the more obvious the difference in their behavioral patterns. Set a semantic deviation threshold T_sem (e.g., 0.85). When the semantic deviation value of a node pair exceeds this threshold, it is marked as an "abnormal path node pair". Output all node pairs that meet the abnormal conditions, and record their access paths, call stack positions, and weight distribution information in the context graph for subsequent report generation and behavior replay verification.

[0044] This step enables the identification of semantically "violated role responsibilities" or "unauthorized access to resources" combinations from complex permission transmission graphs and access behavior contexts, thereby further improving the accuracy and interpretability of ghost path detection.

[0045] The identified abnormal path node pairs are subjected to behavior replay tests to simulate cross-role resource access scenarios in a real web environment. The test determines whether there are unauthorized access success events. If so, the abnormal path and related role nodes are recorded.

[0046] After identifying role nodes and resource nodes with high semantic bias, simulated access request data needs to be constructed based on the node pair information in order to perform behavior replay verification in real web applications.

[0047] Node pair input definition: Each abnormal path node pair consists of a role node R and a resource node O, indicating that role R has atypical access behavior to resource O in the context graph; The request parameters are constructed as follows: User binding information: In behavior replay testing, simulate the user identity U bound to the role R, and keep its access token or credentials consistent with the original log record; Request format matching: Based on the historical access logs corresponding to resource node O, extract the original request format, parameter structure, HTTP method, request headers, etc., to form a complete access request template; Dynamic parameter injection: For dynamic fields such as timestamp, session identifier, and transaction number, the current test environment variables are used to dynamically populate them to ensure that the request is effectively executed in the target environment; Dataset generation method: Using the set of node pairs as input, a set of request data is generated. Each data entry represents a role-resource access request to be verified, which is used for subsequent replay scheduling.

[0048] After constructing the simulated request, the behavior replay operation is executed sequentially in a controlled web environment to simulate the actual effect of role-unauthorized access behavior.

[0049] Test Environment Deployment: Clone the original application deployment environment, including the user permission database, resource access control module, and runtime service interface; disable unnecessary functional modules in the test environment to ensure that behavior replay does not affect external dependent resources or interface response status; Request Scheduling Method: Use sequential scheduling to send the corresponding request data for each abnormal node in the order of request time; for requests with dependency chains (such as those that need to obtain a session before accessing resources), arrange them according to their call stack order to ensure consistent request execution semantics; Request Execution Record: Completely record the response status, return code, and resource call path for each simulated access request; pay special attention to return status codes "200", "201", or other statuses indicating successful access, and combine them with the response body to determine whether the target resource was actually accessed.

[0050] After completing all behavior replay test requests, each test result is verified to determine if any unauthorized access was successfully granted. The judgment criteria are as follows: Authorization verification rule: If there is no record in the access control log of role R being formally authorized to access resource O; and user identity U bound to role R successfully accesses resource O in the behavior replay test; then this access behavior is considered an unauthorized access success event.

[0051] Status Code and Resource Confirmation: The response status code is used as the primary criterion. When the returned status code belongs to the access success category (such as 200 or 201), the access operation is confirmed to have been executed by combining the response body content with whether it contains sensitive resource fields, page redirection, or data download behavior. Optionally, a snapshot comparison method can be used to compare the structure of the replayed access page with the authorized user access page. If the consistency is greater than 90%, the access result is considered equivalent.

[0052] Record access events: For each unauthorized but successful access event, record its associated role identifier, user identity identifier, resource identifier, access time, request parameters, and response summary; at the same time, mark the path information of the node in the context graph to track the potential vulnerability propagation path.

[0053] After completing the behavior replay test, the paths confirmed to have unauthorized access will be compiled into a result set to provide basic data for subsequent report generation and remediation suggestions.

[0054] Path structure export: Extract the complete path of the node pair with successful behavior replay in the context graph as the abnormal access path structure; including the starting role node, the ending resource node, intermediate inheritance paths and call stack hierarchy information; Data structure definition: Each record includes the following fields: path number, user identifier, abnormal role identifier, target resource identifier, access request snapshot, response summary, access time, and replay result status; Output method: Store the abnormal path result set in a structured format (such as JSON or CSV); and provide interface support to connect with the vulnerability report generation module to ensure that the security analysis process chain is complete and traceable.

[0055] Through the above behavior replay verification process, the present invention can simulate real cross-role access behavior and confirm the actual access control failure path in the system based on the running results, thereby accurately identifying hidden vulnerabilities in the RBAC model.

[0056] Based on the user identity and successful resource access events corresponding to the abnormal path, an access control vulnerability report is generated.

[0057] After completing the identification of abnormal access paths and the verification of behavior replay, in order to achieve traceability, presentation, and management of access control vulnerabilities, an access control vulnerability report needs to be automatically generated based on each record confirming a successful unauthorized access event. The specific steps are as follows: Report Structure Construction: Based on the abnormal path result set, a structured report template is constructed. Each vulnerability report corresponds to one abnormal access path, and the report content includes, but is not limited to, the following fields: User identity identifier; abnormal role identifier; identifier of target resource accessed without authorization; access time of behavior replay; request and response summary information; inheritance path of the assigned role and time tags of each node in the path; semantic deviation score and successful behavior replay status; risk level assessment results and recommended handling measures.

[0058] Report generation method: Fields are populated using structured data and test results, and the report is automatically output in a visual format, such as HTML or PDF, using a template-based generation method, while retaining a structured report format (such as JSON or XML) that can be imported into the security platform.

[0059] Through this step, the present invention can achieve automated closed-loop recording and reporting of access control vulnerabilities caused by role inheritance failure in the Web environment, providing a basis for security auditing and permission optimization.

[0060] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for detecting access control vulnerabilities in web applications based on RBAC (Real-Time Access Control) model, characterized in that: include: Retrieve access control log data generated by the web application during runtime; Based on the access control log data, an inheritance graph of cross-session time-series RBAC roles is constructed. The inheritance graph has role nodes as vertices and inheritance relationships between roles as edges. The actual resource access set of each role node is dynamically labeled in combination with the user request sequence. The path between nodes in the inheritance graph is verified for temporal consistency, and potential ghost path subgraphs with permission transmission but lacking explicit authorization records are extracted to form an abnormal access path feature set. The abnormal access path feature set is used as input, and an access behavior context graph is constructed by combining it with resource call stack information. The graph attention mechanism is used to identify abnormal path node pairs with high semantic bias. The identified abnormal path node pairs are subjected to behavior replay tests to simulate cross-role resource access scenarios in a real web environment. The test determines whether there are unauthorized access success events. If so, the abnormal path and related role nodes are recorded. Based on the user identity and successful resource access events corresponding to the abnormal path, an access control vulnerability report is generated.

2. The method for detecting access control vulnerabilities in web application security based on RBAC mode according to claim 1, characterized in that: Constructing the inheritance graph of cross-session temporal RBAC roles includes: The access control log data is clustered according to user identity, and the role allocation information and request target resource sequence of the same user in multiple sessions are extracted to form a cross-session access behavior trajectory. Based on the time sequence of role changes and resource access context in the cross-session access behavior trajectory, inheritance edges between role nodes are generated, and a directed graph structure with role nodes as vertices and inheritance relationships between roles as edges is constructed.

3. The method for detecting access control vulnerabilities in web application security based on RBAC mode according to claim 1, characterized in that: The steps for verifying the temporal consistency of paths between nodes in the inheritance graph include: Based on all reachable paths in the role inheritance graph, construct a time series set of each role node on each path, and extract the earliest authorized time and the last active time of node access behavior; Perform time window constraint checks on each path to determine whether the access times of each role node in the path are continuous and do not violate the time increment rule, and remove paths with time discontinuity. For paths that pass the time-series verification, the access control logs are further compared. If the authorization behavior of the path's endpoint node is not explicitly authorized in the logs, it is marked as a potential ghost path. Extract all character sequences marked as potential ghost paths and their connections into a subgraph to form a potential ghost path subgraph.

4. The method for detecting access control vulnerabilities in web application security based on RBAC mode according to claim 1, characterized in that: in, Constructing an access behavior context graph includes: Based on the role nodes and resource nodes in the abnormal access path feature set, a heterogeneous graph structure is constructed, in which access edges are established between role nodes and resource nodes, inheritance edges are established between role nodes, and call depth, execution order and timestamp are added to the edges in combination with call stack information to form a context graph containing semantic behavior information.

5. The method for detecting access control vulnerabilities in web application security based on RBAC mode according to claim 1, characterized in that: in, Identifying anomalous path node pairs using graph attention mechanisms includes: For each role node and resource node in the context graph, construct a multi-dimensional feature vector, input the graph attention network model, calculate the edge weight attention coefficient between nodes, and output the semantic deviation metric between node pairs by embedding. Use cosine similarity as the evaluation index, and identify abnormal path node pairs whose deviation exceeds the preset range based on the semantic deviation threshold.

6. The method for detecting access control vulnerabilities in web application security based on RBAC mode according to claim 1, characterized in that: in, Behavioral replay tests on the identified abnormal path node pairs include: Construct a set of simulated access requests based on abnormal role nodes and resource nodes; In a controlled web testing environment with isolated deployment, requests are scheduled and executed one by one according to the access time order, and the response status code, response body content and resource access results are recorded. If the access response status code is of the successful access type and the resource returned content is consistent with the authorized access result, and the access control log lacks a formal authorization record for the role, it is considered an unauthorized successful access event and recorded as an abnormal path.

7. The method for detecting access control vulnerabilities in web application security based on RBAC mode according to claim 1, characterized in that: in, The access control log data includes user identity, role assignment information, requested target resource, request timestamp, and authorization result.

Images