A business system privilege breach detection method and device
By parsing permission rule files and building a permission benchmark library, the system automatically identifies and compares unauthorized access vulnerabilities in business systems, solving the problem of low efficiency in traditional tools and manual auditing, and achieving efficient and accurate detection and remediation suggestions for unauthorized access vulnerabilities.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING CHAITIN TECH CO LTD
- Filing Date
- 2026-05-07
- Publication Date
- 2026-07-24
Smart Images
Figure CN122153919B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of network and system security technology, and in particular to a method and apparatus for detecting privilege escalation vulnerabilities in business systems. Background Technology
[0002] In business systems such as finance, government affairs, and enterprise resource planning, access control is a core mechanism for ensuring data security. Privilege escalation vulnerabilities refer to situations where a user can access or manipulate data or functions beyond their authorized scope, including horizontal privilege escalation (a user can manipulate data belonging to other users at the same level) and vertical privilege escalation (a user with lower privileges can perform operations with higher privileges). According to the latest statistics, privilege escalation vulnerabilities have become one of the most serious security risks in current web applications.
[0003] Traditional Static Application Security Testing (SAST) tools primarily rely on sink-source rule matching and syntax feature analysis, effectively detecting technical vulnerabilities such as SQL injection and cross-site scripting (XSS). However, for business logic vulnerabilities like privilege escalation, traditional SAST tools are almost powerless. This is because privilege escalation vulnerabilities do not manifest as specific syntax features or code patterns, but rather as a lack of permission boundary checks, such as missing validation of data ownership fields or user role verification. Such deficiencies cannot be detected through simple rule matching and require a deep understanding of the business logic and permission design.
[0004] Currently, the detection of privilege escalation vulnerabilities mainly relies on manual code auditing by security experts, but manual auditing has significant drawbacks. For example, it is inefficient, often taking several hours to audit a single interface; it is highly dependent on the auditor's business understanding and experience; and it is difficult to promote and apply in large-scale systems. Therefore, there is an urgent need for a technology that can effectively detect privilege escalation vulnerabilities in business systems. Summary of the Invention
[0005] In view of the above-mentioned defects or deficiencies in the prior art, the present invention provides a method and apparatus for detecting privilege escalation vulnerabilities in business systems, which can automatically and effectively identify missing permission verification points in the code and accurately locate privilege escalation vulnerabilities.
[0006] One aspect of the present invention provides a method for detecting privilege escalation vulnerabilities in a business system, comprising the following steps: Obtain the project code of the business system, parse and identify the permission rule files related to the target business function; Analyze the permission rule file to determine the user authentication mechanism, business operation authorization mechanism, and target business data ownership field; wherein, the target business data ownership field is used to identify the subject to which the target business data belongs; Obtain all data entities in the project code that contain the target business data attribution field. Based on the user authentication mechanism, the business operation authorization mechanism, and the target business data attribution field, determine the permission constraints that the user must meet when accessing or operating the data entity. Construct a permission benchmark library using the permission constraints corresponding to all data entities. Based on the permission benchmark library, the code execution path of each API interface related to the target business function is tracked, and all actual permission verification points are identified and marked on the code execution path; the permission verification points are compared point by point with the permission constraints of the corresponding data entities in the permission benchmark library to identify the missing permission verification points on the code execution path. The missing permission verification points are compared and matched with a predefined knowledge base for unauthorized privilege classification to determine the type of unauthorized privilege vulnerability and generate vulnerability remediation suggestions.
[0007] In another aspect, the present invention provides a business system privilege escalation vulnerability detection device, comprising: The code parsing module is used to obtain the project code of the business system, parse and identify the permission rule files related to the target business function; The authentication and authorization analysis module is used to analyze the permission rule file to determine the user identity authentication mechanism, business operation authorization mechanism, and target business data ownership field; wherein, the target business data ownership field is used to identify the subject to which the target business data belongs; The permission benchmark construction module is used to obtain all data entities in the project code that contain the target business data attribution field, and determine the permission constraints that users must meet when accessing or operating the data entities based on the user authentication mechanism, the business operation authorization mechanism and the target business data attribution field, and construct a permission benchmark library using the permission constraints corresponding to all data entities. The permission verification missing identification module is used to track the code execution path of each API interface related to the target business function based on the permission benchmark library, and identify and mark all actual permission verification points on the code execution path; compare the permission verification points with the permission constraints of the corresponding data entities in the permission benchmark library point by point, and identify the missing permission verification points on the code execution path. The vulnerability output module is used to compare and match the missing permission verification points with a predefined knowledge base of unauthorized privilege classifications, determine the type of unauthorized privilege vulnerability, and generate vulnerability remediation suggestions.
[0008] The method and apparatus for detecting privilege escalation vulnerabilities in business systems provided by this invention have the following beneficial effects: (1) By parsing the security components to extract the authentication and authorization mechanism, establishing a permission benchmark library based on key fields, and tracing the code execution path and marking permission checkpoints for each API interface, the detection of business logic privilege escalation vulnerabilities is effectively realized.
[0009] (2) By comparing the permission constraints of the business system obtained in advance with the API interface code, the efficient and accurate location of privilege escalation vulnerabilities can be achieved.
[0010] (3) By comparing and matching the detected missing permission verification with a predefined vulnerability classification library, it is possible to efficiently and accurately output standardized vulnerability types and vulnerability reports containing remediation suggestions. Attached Figure Description
[0011] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart illustrating a method for detecting privilege escalation vulnerabilities in a business system according to an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a business system privilege escalation vulnerability detection device provided in one embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation
[0012] 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.
[0013] To ensure that those skilled in the art can accurately understand the technical solutions of this invention, the technical terms used in this invention are hereby clearly defined.
[0014] (1) Business System Computer software systems that provide specific business functions (such as financial transactions, customer management, resource scheduling, etc.) for enterprises, organizations, or individuals typically include requirements for multiple users, multiple roles, and data isolation.
[0015] (2) API interface Application Programming Interface (API).
[0016] (3) Permission rule file The project code of the business system contains a collection of files related to authentication, authorization, and permission verification logic, including at least security filter files, user model files, and data access mapping files.
[0017] (4) User authentication mechanism The system uses technical solutions to verify the authenticity of user identities, identifying who the user is. Examples include authentication methods based on JWT tokens, Session-Cookies, or OAuth.
[0018] (5) Business operation authorization mechanism The system uses a logical framework to determine whether an authenticated user can perform a specific operation or access specific data, thus limiting what a user can do. Examples include role-based access control or attribute-based access control.
[0019] (6) Field to which target business data belongs The field in a data entity that identifies which specific entity (such as an enterprise, department, or individual) the data belongs to is the core basis for data-level permission verification. For example, the enterprise_id field in a database table.
[0020] (7) Data entities The structured representation of business objects in the business system code, including but not limited to entity classes corresponding to database tables, persistent objects, or data structures in document storage.
[0021] (8) Access Control Constraints These are logical rules that users must meet when accessing or operating on specific data entities, derived from authentication mechanisms, authorization mechanisms, and data ownership fields.
[0022] (9) Permission Baseline Library The set consisting of all data entities involved in the target business function and their corresponding permission constraints serves as the benchmark for subsequently judging whether there are defects in the code implementation.
[0023] (10) Code execution path Starting from the code entry point of the API interface, the complete code execution sequence follows the call chain to the return point, including all methods, conditional branches, and data operations called along the way.
[0024] (11) Permission verification point The logical judgment location on the code execution path used to check user identity, permission roles, or data ownership.
[0025] (12) Horizontal over-weight check The core of the mechanism for checking user access to or manipulation of other users' data at the same level is to ensure that users can only manipulate the data that belongs to them, and cannot manipulate the data of other users at the same level beyond their boundaries.
[0026] (13) Vertical over-weighting check The core of the permission check mechanism for low-privilege users attempting to access or execute high-privilege functions is to ensure that users can only perform corresponding operations within the scope of their role permissions, and cannot bypass the permissions to execute functions that are only allowed for higher-level roles.
[0027] (14) Business rule verification points Permission verification points are used to check whether the current operation meets preset business logic constraints (such as whitelist, transaction limit, account status).
[0028] Example 1 This embodiment provides a method for detecting privilege escalation vulnerabilities in a business system, which can be implemented using computer software. For example... Figure 1 As shown, the method mainly includes the following steps: Step S101: Obtain the project code of the business system, parse and identify the permission rule file related to the target business function.
[0029] Existing technologies for analyzing privilege escalation vulnerabilities often require manual intervention to locate critical code or involve analysis of the entire codebase without a clear target, resulting in inefficiency and a high risk of omissions. This step automates the identification of permission rule files strongly related to the target business function, narrowing the analysis scope from the entire project code to a core set of files, thus laying the foundation for efficient execution of subsequent steps.
[0030] Specifically, this step is the starting point for privilege escalation vulnerability detection. Its purpose is to accurately locate files related to the access control of the target business function from massive amounts of project code. First, the complete project source code is obtained through the code repository address (such as a Git URL). Then, static code analysis technology is used to scan the project source code structure and identify files with specific semantic characteristics. These semantic characteristics include file names (such as those containing keywords like "Controller", "Service", "Filter", "Entity", "Mapper", etc.), file annotations (such as @Controller, @Service, @Entity, etc. in the Spring framework), and the package path of the file (i.e., the logical storage location of the source code file in the project directory structure). By combining these characteristics, the privilege escalation vulnerability detection software can intelligently filter out the core files of the controller layer, service layer, security layer, model layer, and data access layer, and classify them into permission rule files. These files collectively define the entry point of the business function, business logic, authentication and authorization mechanisms, and data model, which are the foundation for subsequent analysis.
[0031] This step allows the system to automatically pinpoint the analysis target, avoiding blind searches across the entire codebase and improving detection accuracy and efficiency. Furthermore, by focusing only on permission-related files, subsequent semantic analysis becomes more focused, reducing interference from irrelevant code.
[0032] Step S102: Analyze the permission rule file to determine the user authentication mechanism, business operation authorization mechanism, and target business data ownership field.
[0033] Existing technologies often view authentication and authorization in isolation when performing permission analysis, lacking an extraction and understanding of the overall system permission architecture. This step, through comprehensive analysis of three types of files, systematically constructs a three-in-one security benchmark of "authentication-authorization-attribution," providing a reliable basis for subsequently generating precise permission constraints.
[0034] Specifically, this step aims to extract the permission design blueprint of the business system from the permission rule file, including the following analysis steps: (1) Extraction of user identity authentication mechanism By analyzing JWT filter files (such as JwtFilter.java), the specific implementation mechanism of authentication can be identified. This includes the location where the JWT token is extracted (such as the Authorization field in the HTTP request header), the token signature verification algorithm (such as HS256, RS256), and the storage container for user information after successful verification (such as SecurityContext). By parsing this code logic, it is possible to determine whether the business system uses JWT, OAuth, or Session authentication methods, and to understand how user identity is passed and accessed throughout the request processing lifecycle.
[0035] (2) Extraction of business operation authorization mechanism By analyzing enterprise user model files (such as EnterpriseUser.java), the system extracts user identification fields, especially key fields used for permission determination, including field names, field annotations, and field context. Field names include the user's unique identifier (userId), user ownership identifier (enterpriseId), user role and permission identifier (role), and possibly department identifier (departmentId). The system not only identifies field names but also performs semantic reasoning based on field annotations (such as @Id, @NotNull, @Enumerated), field naming semantics, and context (such as class names and package names) to determine the authorization model used by the system. For example, if a role field exists and is an enumeration type, it can be inferred that the system uses role-based access control (RBAC); if an enterpriseId field exists, it can be inferred that the system uses data ownership control; the presence of both indicates a hybrid authorization model.
[0036] (3) Extraction of the target business data belonging field By analyzing target business data access mapping files (such as AccountMapper.xml) or annotations on entity classes, the system scans the definitions of core data tables to identify fields used to identify data ownership, such as enterprise_id in the account table. These fields act as a bridge connecting user identity and data resources, and their existence implies the need for data isolation, namely: data from different entities should be isolated from each other, users can only access data belonging to their own entity, and cross-entity operations are not allowed without authorization.
[0037] This step not only reveals how users log in and authenticate, but also what they can do after logging in (authorization) and how data identifies itself (attribution field). This multi-dimensional information integration ensures that subsequent permission rule derivation is no longer a matter of blind men and an elephant, but is based on the actual system design.
[0038] Step S103: Obtain all data entities in the project code that contain the target business data attribution field. Based on the user authentication mechanism, the business operation authorization mechanism, and the target business data attribution field, determine the permission constraints that the user must meet when accessing or operating the data entity. Construct a permission benchmark library using the permission constraints corresponding to all data entities.
[0039] Existing technologies often lack unified modeling and management of permission rules, resulting in a lack of clear judgment criteria when conducting vulnerability detection. This step transforms implicit and scattered permission design intentions into explicit and centralized rule sets by constructing a permission benchmark library, providing a reliable benchmark for subsequent comparisons that may be missing in permission verification.
[0040] Specifically, this step concretizes the abstract information extracted in steps S101 and S102, generates explicit permission constraints for each data entity protected by permissions, and constructs a global permission benchmark library.
[0041] The specific implementation process includes: (1) Scanning data entities Using the target business data attribution field (e.g., enterprise_id) determined in step S102 as the search key, the entire project code is traversed to find all data entities containing that field. These entities may exist as Java classes (e.g., @Entity) or table definitions in XML mapping files. The scan results constitute a set of entities to be analyzed.
[0042] (2) Obtain user identity identifier From the user authentication mechanism determined in step S102, the system clarifies the method of obtaining user identity identifiers and their storage location. For example, user identity identifiers (such as enterpriseId) can be obtained from SecurityContext.
[0043] (3) Determine the permission judgment logic From the business operation authorization mechanism determined in step S102, the system clarifies the logical framework for permission determination. If it is a hybrid authorization model, permission determination needs to consider both role conditions and data ownership conditions; if it is a purely role-based access control, only roles need to be considered; if it is a purely data ownership control, only data ownership needs to be considered.
[0044] (4) Generate permission constraints For each scanned data entity, the system combines the field name, field annotation, field context, correspondence with user identity identifier, and permission determination logic to perform comprehensive reasoning and generate the corresponding permission constraints for that entity.
[0045] For example, the reasoning process is as follows: First, perform semantic understanding of the fields. Infer the business meaning of a field as "enterprise identifier" from its name (e.g., enterprise_id); infer the constraint strength from its annotations (e.g., @NotNull); and infer the business object it represents from its context (e.g., the entity it belongs to is named Account).
[0046] Next, the corresponding relationship is established. The attribution field in the data entity (such as enterprise_id) is associated with the attribution identifier in the user identity (such as enterpriseId) to infer that there should be a matching relationship between the two.
[0047] Next, the logical framework is integrated. Based on the permission determination logic determined in step S102, it is decided whether role conditions need to be introduced. For example, if the authorization mechanism is a hybrid model, the generated constraints may include both data ownership conditions and role conditions.
[0048] Finally, rules are generated, resulting in constraints such as "For an account entity, the user must satisfy account.enterprise_id = current user.enterpriseId, and (if the operation is sensitive) the current user role is OPERATOR or ADMIN".
[0049] By aggregating the permission constraints of all data entities, a structured permission baseline library is formed. This library is essentially a complete description of the ideal permission constraint state for the target business function. It presents the permission design intent scattered throughout the code as an explicit set of rules.
[0050] This step, by establishing a permission benchmark database, transforms privilege escalation vulnerability detection from experience-based manual judgment to automated comparison based on explicit rules. It not only improves the accuracy and consistency of detection but also makes the detection process interpretable and traceable.
[0051] Step S104: Based on the permission benchmark library, track the code execution path of each API interface related to the target business function, and mark all actual permission verification points on the code execution path; compare the permission verification points with the permission constraints of the corresponding data entities in the permission benchmark library point by point, and identify the missing permission verification points on the code execution path.
[0052] Traditional static analysis tools cannot understand business logic, thus failing to determine whether a missing permission checkpoint is due to design flaws or code defects. This step introduces a permission benchmark library as a judgment standard, enabling the privilege escalation vulnerability detection software to understand which permission checks should be performed in specific business scenarios, thereby accurately identifying the missing points.
[0053] Specifically, the implementation process includes the following: (1) API interface parsing and operation intent recognition For each API interface related to the target business function, the system first parses its request method (e.g., GET, POST), request path (e.g., / api / transfer), and request parameters (e.g., fromAccountId, toAccountId, amount). By combining the semantics of the path naming and parameter names, the system infers the business operation intent of the API. For example, it identifies that this is a transfer interface. Identifying the operation intent helps to focus on the relevant data entities (e.g., account entities, transaction record entities) in subsequent steps.
[0054] (2) Code execution path tracing Starting from the entry point of the API interface (such as the first line of code in TransferController.transfer()), the system performs static, deep code execution path tracing. Specifically, the tracing follows the method call chain, sequentially entering the service layer, data access layer, and finally the return point. During the tracing process, the system records every line of code executed along the way, every method call, and every conditional branch. This is equivalent to constructing a complete flowchart of the API's request processing.
[0055] (3) Permission verification point marking Along the traced code execution path, the system identifies and marks all code locations related to access control, i.e., access control checkpoints. Examples of these access control checkpoints include: ① Authentication checkpoints: such as operations that retrieve the current user information from the SecurityContext, which is a prerequisite for any subsequent permission verification.
[0056] ② Horizontal overriding checkpoints: such as if statements that explicitly compare data attribution fields, for example if (!account.getEnterpriseId().equals(currentUser.getEnterpriseId())).
[0057] ③ Vertical privilege escalation checkpoints: such as checking user role annotations, for example: @PreAuthorize("hasRole('ADMIN')") or conditional statements, for example: if (!currentUser.getRole().equals("OPERATOR")).
[0058] ④ Business rule verification points: such as querying the whitelist table, verifying transaction limits, checking account status, etc. These operations reflect specific business constraints.
[0059] (4) Point-by-point comparison and missing identification The privilege escalation vulnerability detection software compares the actual permission verification points along the code execution path with the permission constraints for the data entities involved in the current operation in the permission benchmark library constructed in step S103, point by point. The core of the comparison is to check whether there is a corresponding verification point on the actual code path for each constraint required in the permission benchmark library. If it exists, it is marked as "satisfied"; if it does not exist, a "missing permission verification point" is marked at that location.
[0060] For example, if the permission benchmark library requires "account ownership must be verified after querying an account", but no comparison logic for enterprise_id is found in the actual code path after the account query operation, the system will mark a missing horizontal privilege escalation check point at this point.
[0061] This step automatically compares implicit permission design intent with explicit code implementation, accurately identifying horizontal and vertical privilege escalations and missing business rule validations. The missing permission validation points it outputs serve as direct material for subsequent vulnerability reports, demonstrating high accuracy and interpretability.
[0062] Step S105: Based on the missing permission verification point, generate a vulnerability report containing the vulnerability location, vulnerability type, and remediation suggestions.
[0063] The ultimate goal of vulnerability detection is to fix vulnerabilities. If unauthorized vulnerability detection software merely tells developers "there is a vulnerability here," developers still need to spend a significant amount of time understanding the vulnerability, locating the problem, and finding a fix. This step, by generating a detailed report that includes the location, type, attack steps, and remediation recommendations, greatly reduces the cost and time required for vulnerability remediation.
[0064] Specifically, the privilege escalation vulnerability detection software summarizes all missing permission verification points identified in step S104, enriches and structures them, and generates the final user report. For each missing permission verification point, the system performs the following operations: (1) Locating the vulnerability Record the file name, class name, method name, and line number of the missing permission verification point so that developers can quickly locate it.
[0065] (2) Determine the vulnerability type Based on the nature of the missing permission verification points, they are categorized as horizontal privilege escalation, vertical privilege escalation, or abuse of business rules. Furthermore, the system can match a predefined privilege escalation classification knowledge base, providing more specific type numbers and names. Examples are shown in the table below: (3) Generate vulnerability description Describe the potential security risks of missing information using natural language. For example: failing to verify account ownership after querying the outgoing account could allow any user to designate another company account as the transferor.
[0066] (4) Provide steps to reproduce the attack. Simulates the attacker's perspective, providing specific and actionable attack steps. For example: logging in using Company A's account, constructing a POST request, and setting the fromAccountId parameter to Company B's account ID, allows funds to be transferred from Company B's account.
[0067] (5) Provide repair suggestions Specific code fixes are provided for missing permission verification points.
[0068] For example: immediately add ownership verification logic after querying the account from which the transfer was made: if (!account.getEnterpriseId().equals(currentUser.getEnterpriseId())) {throw newAccessDeniedException();}.
[0069] The report output by this step is not only a list of vulnerabilities, but also a remediation guide. It enables security and development teams to respond to security risks quickly and accurately, reducing the average vulnerability remediation time from hours or even days to minutes.
[0070] To make the technical solution of the present invention clearer and easier to understand, the following uses a specific transfer scenario in a banking business system as an example to illustrate the complete application process of the present invention in detail.
[0071] Step 1: Code Analysis and Key File Location Enter the code repository address of the bank's corporate online banking project (e.g., https: / / github.com / xxbank / corporate-banking.git) into the privilege escalation detection software to pull the complete Java project code. After scanning the project structure, it automatically identifies the key files related to the target business function of fund transfer: ① The transfer controller file, TransferController.java, is located in the controller layer.
[0072] ②The account service file AccountService.java is located in the business logic layer.
[0073] ③ The JWT filter file JwtFilter.java is located in the security layer.
[0074] ④ The Enterprise User model file, EnterpriseUser.java, is located in the data model layer.
[0075] ⑤ The account mapping file AccountMapper.xml is located in the data access layer.
[0076] The above five files constitute the set of permission rule files for subsequent analysis.
[0077] Step 2: Extracting the Authentication and Authorization Architecture The system conducts an in-depth analysis of the above documents: (1) Analysis of JwtFilter.java reveals that it extracts the JWT token from the Authorization field of the HTTP request header, verifies the signature using the HS256 algorithm, and stores the user information in the SecurityContext after parsing. This confirms that the system uses the JWT stateless authentication mechanism.
[0078] (2) Analyzing EnterpriseUser.java, the user model is extracted, which includes userId (unique user identifier), enterpriseId (enterprise identifier), role (role, value can be ADMIN, OPERATOR or VIEWER), and departmentId (department identifier). Based on this, it is determined that the system adopts a hybrid authorization model that combines RBAC and data ownership control.
[0079] (3) Analysis of AccountMapper.xml revealed that the account table defines an enterprise_id field to identify the enterprise to which the account belongs. Therefore, the target business data belongs to the enterprise_id field.
[0080] Step 3: Establish data entities and ownership relationships The privilege escalation detection software uses enterprise_id as the key field and scans all data entities containing this field across the entire project.
[0081] (1) The account table entity was scanned and found to contain the fields account_id, account_no, balance, enterprise_id and status. Based on the field semantics and the authorization model in the second step, the system deduced the permission constraint for the account entity: "The account's enterprise_id must be equal to the current user's enterpriseId for the user to operate the account."
[0082] (2) The transaction log table entity was scanned and found to contain the fields from_account, to_account, amount, and enterprise_id. The system deduced the permission constraint for the transaction log entity: "The enterprise_id of the transaction log must be equal to the enterpriseId of the current user for the user to view the transaction log."
[0083] (3) The enterprise whitelist table entity was scanned and found to contain enterprise_id (this enterprise) and partner_enterprise_id (partner enterprise). Based on common business sense, the system deduced the business rule for cross-enterprise transfers: "The enterprise_id of the receiving account is either equal to the current user's enterpriseId or exists in the partner_enterprise_id of the enterprise_whitelist table".
[0084] At this point, the system has built a permission benchmark library that includes the above three data entities and their corresponding permission constraints.
[0085] Step 4: Perform operation path reasoning for each API The system iterates through the API interfaces related to the transfer function, focusing first on the POST / api / transfer interface.
[0086] (1) Analyze the operation intention By using the POST request method, the path / api / transfer, and the parameters fromAccountId, toAccountId, and amount, the unauthorized access detection software determined that the API's intent was to perform a fund transfer.
[0087] (2) Tracing the code execution path Start tracing from the entry point of the TransferController.transfer() method.
[0088] First step: Call getCurrentUser() to retrieve the current user (userId=10086, enterpriseId=9988, role=OPERATOR) from the SecurityContext. The system marks this as an authentication checkpoint.
[0089] The second step involves calling `accountService.findById(fromAccountId)` to query the account from which the transfer originated. After the query, the system scanned the subsequent code and found no logic comparing the account's `enterprise_id` with the current user's `enterpriseId` (9988). The system marked this as a missing horizontal privilege escalation checkpoint.
[0090] The third step involves calling `accountService.findById(toAccountId)` to query the receiving account. Similarly, the system found no verification of the receiving account's `enterprise_id` after the query, nor any logic for querying the `enterprise_whitelist` table. The system marks this as a missing business rule verification point (whitelist verification).
[0091] Fourth step: The system calls `accountService.doTransfer()` to execute the transfer. The system checks this method and its call chain and finds no validation logic for the current user's role (such as the `@PreAuthorize` annotation or role determination). The system marks this as a missing vertical privilege escalation checkpoint.
[0092] (3) Vulnerability Confirmation The verification points on the actual path (only the authentication checkpoint at the first station) were compared with three rules in the permission benchmark library, and three violations were confirmed.
[0093] Step 5: Outputting the vulnerability report The system summarizes the above-mentioned missing points and generates a structured vulnerability report: (1) Vulnerability of arbitrary account transfer (horizontal privilege escalation). Location: TransferController.java:45, after the call to accountService.findById(from A c countId).
[0094] Description: Failure to verify the ownership of the account after querying the outgoing account may result in cross-company fund transfers.
[0095] Reproduction: Log in to Company A's account, construct a request, and set fromAccountId to Company B's account ID.
[0096] Fix: Add an if statement after the query to compare account.getEnterpriseId() with currentUser.getEnterpriseId().
[0097] (2) Vulnerability of arbitrary account transfer (horizontal privilege escalation + abuse of business rules) Location: TransferController.java:47, after the call to accountService.findById(toAccountId).
[0098] Description: After checking the account to which the funds were transferred, the ownership and whitelist were not verified, and the funds may have been transferred to an illegal account.
[0099] Fix: Add double verification. First, check if they are from the same company, then check the whitelist table.
[0100] (3) Role-based access control bypass vulnerability (vertical privilege escalation) Location: TransferController.java:42, at the declaration of the transfer method.
[0101] Description: The method is missing a role annotation. A VIEWER user may be able to execute the transfer by directly calling it.
[0102] Fix: Add the `@PreAuthorize("hasAnyRole('OPERATOR', 'ADMIN')")` annotation to the method.
[0103] Thus, this embodiment fully demonstrates the entire implementation process of the present invention, from code acquisition to outputting a specific vulnerability report.
[0104] Example 2 See Figure 2 Another embodiment of the present invention provides a business system privilege escalation vulnerability detection device 200, including a code parsing module 201, an authentication and authorization analysis module 202, a permission baseline construction module 203, a permission verification missing identification module 204, and a vulnerability output module 205. This business system privilege escalation vulnerability detection device 200 is capable of executing the business system privilege escalation vulnerability detection method described in the method embodiment.
[0105] Specifically, the business system privilege escalation vulnerability detection device 200 includes: The code parsing module 201 is used to obtain the project code of the business system, parse and identify the permission rule files related to the target business function; The authentication and authorization analysis module 202 is used to analyze the permission rule file to determine the user identity authentication mechanism, business operation authorization mechanism, and target business data ownership field; wherein, the target business data ownership field is used to identify the subject to which the target business data belongs; The permission benchmark construction module 203 is used to obtain all data entities in the project code that contain the target business data attribution field, and determine the permission constraints that users must meet when accessing or operating the data entities based on the user identity authentication mechanism, the business operation authorization mechanism and the target business data attribution field, and construct a permission benchmark library using the permission constraints corresponding to all data entities. The permission verification missing identification module 204 is used to track the code execution path of each API interface related to the target business function based on the permission benchmark library, and mark all actual permission verification points on the code execution path; compare the permission verification points with the permission constraints of the corresponding data entities in the permission benchmark library point by point, and identify the missing permission verification points on the code execution path. The vulnerability output module 205 is used to compare and match the missing permission verification points with a predefined privilege escalation classification knowledge base, determine the privilege escalation vulnerability type, and generate vulnerability remediation suggestions.
[0106] It should be noted that the technical solutions corresponding to the business system privilege escalation vulnerability detection device 200 provided in this embodiment, which can be used to execute various method embodiments, have similar implementation principles and technical effects to the methods, and will not be repeated here.
[0107] Example 3 See Figure 3 This embodiment also provides a structural schematic diagram of an electronic device 300, which is used to implement the business system privilege escalation vulnerability detection method in the method embodiment. The electronic device 300 in this embodiment may include a smart terminal, a PC, a laptop computer, a server, etc. Figure 3 The electronic device 300 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.
[0108] like Figure 3As shown, the electronic device 300 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes to implement the methods of the embodiments described herein, based on a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing device 301, ROM 302, and RAM 303 are interconnected via a bus 305. An input / output (I / O) interface 304 is also connected to the bus 305.
[0109] Typically, the following devices can be connected to I / O interface 304: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.
[0110] The above description is merely a preferred embodiment of the present invention. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to the specific combination of the above-described technical features, but should also cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.
Claims
1. A method for detecting privilege escalation vulnerabilities in a business system, characterized in that, Includes the following steps: Obtain the project code of the business system, parse and identify the permission rule files related to the target business function; Analyze the permission rule file to determine the user authentication mechanism, business operation authorization mechanism, and target business data ownership field; wherein, the target business data ownership field is used to identify the subject to which the target business data belongs; Obtain all data entities in the project code that contain the target business data attribution field. Based on the user authentication mechanism, the business operation authorization mechanism, and the target business data attribution field, determine the permission constraints that a user must meet when accessing or operating the data entity. This includes: obtaining the user identity identifier based on the user authentication mechanism; determining the permission determination logic based on the business operation authorization mechanism; generating the permission constraints that must be met when accessing or operating the data entity based on the field name, field annotation, field context, correspondence with the user identity identifier, and the permission determination logic of the target business data attribution field; and constructing a permission baseline library using the permission constraints corresponding to all data entities. Based on the permission benchmark library, the code execution path of each API interface related to the target business function is traced, and all actual permission verification points are identified and marked on the code execution path. This includes: parsing the request method, request path, and request parameters of each API interface related to the target business function to determine the operation intent of the API interface; tracing the code execution path from the entry point of the API interface, identifying and marking all actual permission verification logic related to the current user identity, permission role, and / or data ownership at the key operation points of the code execution path as the permission verification points; and comparing the permission verification points with the permission constraints of the corresponding data entities in the permission benchmark library point by point to identify the missing permission verification points on the code execution path. The missing permission verification points are compared and matched with a predefined knowledge base for unauthorized privilege classification to determine the type of unauthorized privilege vulnerability and generate vulnerability remediation suggestions.
2. The method for detecting privilege escalation vulnerabilities in a business system according to claim 1, characterized in that: The permission rule file includes a JWT filter file, an enterprise user model file, and a target business data access mapping file; The steps of analyzing the permission rule file to determine the user authentication mechanism, business operation authorization mechanism, and target business data attribution field include: Analyze the JWT filter file to obtain the user authentication mechanism based on the JWT token extraction method, the algorithm for signing and verifying the JWT token, and the storage location of the user information after successful verification. Analyze the enterprise user model file and extract the user identity identifier field. The user identity identifier field is a core data field used to uniquely identify the user's identity and the permission subject to which the user belongs. The user identity identifier field includes a field name, field annotation, and field context. Based on the field name, field annotation, and field context of the user identity identifier field, the business operation authorization mechanism is obtained through semantic reasoning. Analyze the target business data access mapping file and extract the corresponding target business data attribution fields.
3. The method for detecting privilege escalation vulnerabilities in a business system according to claim 1, characterized in that, The permission verification points include horizontal unauthorized access verification points, vertical unauthorized access verification points, and business rule verification points.
4. A device for detecting privilege escalation vulnerabilities in a business system, characterized in that, include: The code parsing module is used to obtain the project code of the business system, parse and identify the permission rule files related to the target business function; The authentication and authorization analysis module is used to analyze the permission rule file to determine the user identity authentication mechanism, business operation authorization mechanism, and target business data ownership field; wherein, the target business data ownership field is used to identify the subject to which the target business data belongs; The permission baseline construction module is used to obtain all data entities in the project code that contain the target business data attribution field, and determine the permission constraints that a user must meet when accessing or operating the data entity based on the user authentication mechanism, the business operation authorization mechanism, and the target business data attribution field. This includes: obtaining a user identity identifier based on the user authentication mechanism; determining permission judgment logic based on the business operation authorization mechanism; generating permission constraints that must be met when accessing or operating the data entity based on the field name, field annotation, field context, correspondence with the user identity identifier, and the permission judgment logic of the target business data attribution field; and constructing a permission baseline library using the permission constraints corresponding to all data entities. The permission verification missing identification module is used to trace the code execution path of each API interface related to the target business function based on the permission benchmark library, and identify and mark all actual permission verification points on the code execution path. This includes: parsing the request method, request path, and request parameters of each API interface related to the target business function to determine the operation intent of the API interface; tracing the code execution path from the entry point of the API interface, identifying and marking all actual permission verification logic related to the current user identity, permission role, and / or data ownership at key operation points in the code execution path as permission verification points; and comparing the permission verification points with the permission constraints of the corresponding data entities in the permission benchmark library point by point to identify missing permission verification points on the code execution path. The vulnerability output module is used to compare and match the missing permission verification points with a predefined knowledge base of unauthorized privilege classifications, determine the type of unauthorized privilege vulnerability, and generate vulnerability remediation suggestions.
5. The business system privilege escalation vulnerability detection device according to claim 4, characterized in that: The permission rule file includes a JWT filter file, an enterprise user model file, and a target business data access mapping file; The authentication and authorization analysis module is further used for: Analyze the JWT filter file to obtain the user authentication mechanism based on the JWT token extraction method, the algorithm for signing and verifying the JWT token, and the storage location of the user information after successful verification. Analyze the enterprise user model file and extract the user identity identifier field. The user identity identifier field is a core data field used to uniquely identify the user's identity and the permission subject to which the user belongs. The user identity identifier field includes a field name, field annotation, and field context. Based on the field name, field annotation, and field context of the user identity identifier field, the business operation authorization mechanism is obtained through semantic reasoning. Analyze the target business data access mapping file and extract the corresponding target business data attribution fields; The permission rule file includes the JWT filter file, the enterprise user model file, and the target business data access mapping file.
6. The business system privilege escalation vulnerability detection device according to claim 4, characterized in that, The permission verification points include horizontal unauthorized access verification points, vertical unauthorized access verification points, and business rule verification points.