A method and system for detecting privilege-escalation vulnerabilities in a Java web system

Abstract

The present application relates to the field of computer network security, and particularly relates to a kind of Java Web system's privilege breach detection method and system.The present application proposes a kind of Java Web system's privilege breach detection method, its steps include: obtaining Java Web application code to be detected;Soot framework is used to convert the code to be detected into JIMPLE IR;Based on the JIMPLE IR and the prior rule library, each authentication related function and each sensitive function in the code to be detected are obtained;Based on whether the function call point of each authentication related function can reach one or more sensitive functions, each authentication exit of the authentication related function is obtained;The authentication path of the structure of each authentication exit is analyzed to detect whether there is privilege breach.This application can detect the authentication logic code with defects existing in API internally, not just stay at the configuration level.At the same time, by introducing the reasoning ability of large language model, it can detect deeper and more complex privilege breaches.

Description

TECHNICAL FIELD

[0001] The application relates to the field of computer network security, in particular to a Java Web system out-of-bound vulnerability detection method and system. BACKGROUND

[0002] The out-of-bound vulnerability refers to a vulnerability existing in an access control strategy of a Web application, and the access control strategy aims to limit the user so that the user cannot perform operations beyond the expected permissions. Incorrect access control can cause information leakage, data modification and destruction, command execution and other consequences, forming serious harm. According to the Top 10 security vulnerabilities published by OWASP (Open Web Application Security Project) in 2022, from 2017 to 2021, the number of incorrect access control vulnerabilities increased from the fifth to the first, and the incorrect access control vulnerabilities widely exist in Web applications.

[0003] The harm caused by the out-of-bound vulnerability is so huge, and the number of the out-of-bound vulnerability is so large that it cannot be ignored, and the JAVA WEB system widely exists in the network space. Therefore, it is necessary to study the out-of-bound vulnerability detection method for the Java Web API. SUMMARY

[0004] In view of the above problems, the application provides a Java Web system out-of-bound vulnerability detection method and system, which detects the out-of-bound problem in the application API based on a white-box static analysis technology.

[0005] The application provides a Java Web system out-of-bound vulnerability detection method, and the steps include:

[0006] Obtaining Java Web application code to be detected;

[0007] Converting the code to be detected into JIMPLE IR by using a Soot framework;

[0008] Obtaining each authentication-related function and each sensitive function in the code to be detected based on a priori rule library and the JIMPLE IR;

[0009] Obtaining each authentication exit of the authentication-related function based on whether the function call point of the authentication-related function can reach one or more sensitive functions;

[0010] Analyzing the authentication path of each authentication exit structure to detect whether there is an out-of-bound vulnerability.

[0011] Further, the a priori rule library includes an authentication-related function library storing the interfaces, annotation feature information of various authentication-related functions, and a sensitive function library storing the class name, function name and parameter list information of various sensitive functions.

[0012] Further, the unauthorized access vulnerability includes three types of unauthenticated, weak authenticated and missing authenticated, wherein the unauthenticated refers to that there are authentication paths in the code structure, which pass through a plurality of authentication irrelevant structures and reach the authentication exit without passing through any authentication relevant structure; the weak authenticated refers to that there are authentication paths in the code structure, which pass through a plurality of authentication relevant structures before reaching the authentication exit structure, but the plurality of authentication relevant structures include one or more weak authentication structures; and the missing authenticated refers to that there are two different authentication paths in the code structure, which reach the same authentication exit structure.

[0013] Further, the to-be-detected code includes JAVAJAR package, Class class and War package.

[0014] Further, for any authentication relevant function, the function call points in the authentication relevant function are extracted by using the SOOT framework, and whether the call path can reach one or more sensitive functions is tracked based on a graph path search algorithm, so as to obtain each authentication exit inside the authentication relevant function.

[0015] Further, for any authentication relevant function, the statements in the JIMPLE IR thereof are traversed, the conditionExpr expression in the IFstmt class statement code is extracted, and the source function of the parameter thereof is tracked, for example, if it is judged according to prior knowledge that the source function is not a suspected authentication function, the authentication type thereof is directly judged; otherwise, the authentication exit structure thereof is generated and subsequent unauthorized access vulnerability detection is performed.

[0016] Further, if it cannot be judged according to prior knowledge, whether the source function is a suspected authentication function is judged by using a large language model.

[0017] Another aspect of the present application provides an unauthorized access vulnerability detection system of a Java Web system, which comprises:

[0018] a data acquisition module, configured to acquire to-be-detected code of a Java Web application;

[0019] a data analysis module, configured to convert the to-be-detected code into JIMPLE IR by using a Soot framework; obtain each authentication relevant function and each sensitive function in the to-be-detected code based on a prior rule library and the JIMPLE IR; and obtain each authentication exit of the authentication relevant function based on whether the function call points of the authentication relevant function can reach one or more sensitive functions;

[0020] a vulnerability detection module, configured to analyze the authentication paths of each authentication exit structure, so as to detect whether there is an unauthorized access vulnerability.

[0021] The application also provides an electronic device comprising a memory and a processor, the memory storing a computer program configured to be executed by the processor, the computer program comprising instructions for executing any of the above methods.

[0022] The application also provides a storage medium storing a computer program, which, when executed by a computer, implements any of the above methods.

[0023] The application has the following advantages:

[0024] In view of the widespread existence of the Java Web overreach problem in the network space and the great harmfulness, the application designs a Java Web overreach vulnerability detection framework on the basis of in-depth analysis of the principle of overreach vulnerability generation, provides security detection services for developers and security testers, and improves application security. Moreover, the Java Web internal authentication logic code with defects can be detected, rather than being limited to the configuration level. Meanwhile, by introducing the reasoning ability of a large language model, more deep and complex overreach vulnerabilities can be detected. BRIEF DESCRIPTION OF DRAWINGS

[0025] Figure 1 The flowchart of the first aspect of the embodiment of the application.

[0026] Figure 2 The schematic diagram of the three overreach models in the embodiment of the application.

[0027] Figure 3 The structural block diagram of the overreach vulnerability detection system in the embodiment of the application. EMBODIMENT

[0028] The application will be further described in detail below with reference to the drawings, and the examples are only used to explain the application, and are not used to limit the application.

[0029] The first aspect of the embodiment of the application discloses a Java Web system overreach vulnerability detection method, and the specific flow is as shown in Figure 1 .

[0030] S1 obtains the code to be detected

[0031] The Java Web application source code package is obtained, including the JAVA JAR package, the Class class and the War package, and the code to be detected is obtained therefrom.

[0032] S2 converts JIMPLE IR

[0033] The JIMPLE IR of the code to be detected is converted by using the SOOT framework.

[0034] S3 Obtain or construct a priori rule library

[0035] By analyzing the JAVA Web development specification, the interfaces and annotation features of the authentication related functions are artificially summarized and abstracted into rules to construct an authentication related function library based on priori rules. Of course, the existing authentication related function library can also be directly used.

[0036] By collecting sensitive functions in JAVA syntax, including command execution related classes, SQL operation classes, file read-write classes, and jndi query classes, the class name, function name, and parameter list of the sensitive functions are artificially summarized to construct a sensitive function library based on priori information.

[0037] S4 Mark Target functions and Sink functions

[0038] Class information extraction is performed on the code to be detected using the SOOT framework. In the extraction process, the information in the two function libraries in S3 is matched, and the functions that match successfully are marked as Target functions and Sink functions, respectively.

[0039] S5 Mark auth_out structure

[0040] A function call graph CFG of the code to be analyzed is created by analyzing JIMPLE IR. The function call points in the Target functions are extracted using the SOOT framework, and the function call points are used as the starting point of the call graph CFG. Based on the graph path search algorithm, it is tracked whether the call path can reach the Sink function, so as to mark the sink call logic points inside the Target function and obtain the auth_out structure.

[0041] S6 Establish an unauthorized model

[0042] Three kinds of unauthorized models existing in JAVA WEB API are established, including no authentication, weak authentication, and missing authentication, as shown in Figure 2

[0043] No authentication (no auth): The program structure passes through a number of authentication-independent structures without passing through any authentication-related structure to reach the authentication exit. It is an unauthorized model without authentication.

[0044] Weak authentication (weak auth): The program structure passes through a number of authentication-related structures before reaching the authentication exit structure, but one or more weak authentication structures exist, which is a weak authentication unauthorized model.

[0045] ​Miss auth: there are two authentication paths to the same auth_out structure in the program structure, one of which passes through the authentication structure ABC and the other of which passes through the authentication structure AC, which is a missing authentication privilege model.

[0046] Among them, the authentication-independent structure is several code features in the program, including the IF structure irrelevant to the judgment condition and the permission check, the IF structure without auth_out structure inside, and any number of continuous non-auth_out structure statement blocks. The authentication-dependent structure is several code features in the program, including the IF structure with auth_out structure inside, and the IF structure with return statement inside. The weak authentication structure is an authentication-dependent structure with a defective judgment condition.

[0047] S7 detects privilege leakage

[0048] Traverse the statements in the JIMPLE IR, judge whether the statement type is IFstmt, if not, skip, if IFstmt, continue to analyze. By extracting the conditionExpr expression of IFstmt, trace the source function of its parameters, directly judge the authentication type of the function based on the existing authentication rule library (and the authentication type of the source function has been collected in the existing authentication rule library, which can be directly queried) and output, if it cannot be judged, use the large language model to judge whether it is a suspected authentication function, if yes, use the large language model to extract the auth_out structure and add it to the analysis queue.

[0049] Traverse the auth_out structure of the analysis queue, match from the three privilege models according to the current authentication path, judge whether there is a privilege leakage based on the matching result and output.

[0050] The second aspect of the embodiment of the application discloses a privilege leakage detection system of a Java Web system, as shown in Figure 3 .

[0051] The data acquisition module is used to acquire Java Web application code to be detected;

[0052] The data analysis module is used to convert the code to be detected into JIMPLE IR by using a Soot framework; obtain each authentication-dependent function and each sensitive function in the code to be detected based on a priori rule library and the JIMPLE IR; obtain each authentication exit of the authentication-dependent function based on whether the function call point of the authentication-dependent function can reach one or more sensitive functions;

[0053] The vulnerability detection module is used to analyze the authentication path of each authentication exit structure to detect whether there is a privilege leakage.

[0054] The third aspect of the present application discloses an embodiment of the method of the present application, which is illustrated by the detection process of CVE-2024-27764 JEEWMS privilege escalation vulnerability.

[0055] [S1] Obtain the war package jeewms.war after compiling the jeewms source code, which is a file with a size of 141.8 MB.

[0056] [S2] Convert the JIMPLE IR of jeewms.war by using the SOOT framework.

[0057] [S3] Construct the authentication-related function library and the sensitive function library.

[0058] [S4] Extract the class information of jeewms.war by using the SOOT framework, and when extracting the information of the class org.jeecgframework.core.interceptors.AuthInterceptor, match the rule information of the above-mentioned authentication-related function library (the class implements the org.springframework.web.servlet.HandlerInterceptor interface), and mark the preHandle function as the target function.

[0059] [S5] Analyze the marked preHandle function JIMPLE IR, perform graph path search on the CFG, and mark the auth_out structure return 1 in it.

[0060] [S6] Establish three kinds of privilege escalation models existing in JAVA WEB API.

[0061] [S7] Traverse the JIMPLE IR of org.jeecgframework.core.interceptors.AuthInterceptor preHandle function, run to the first JIFSTMT, trace its ConditionExpr function as java.lang.String: int length, hit the irrelevant function rule in the existing authentication rule library, mark as authentication irrelevant structure. Run to the second JIFSTMT, trace its ConditionExpr function as java.lang.String: boolean equals (java.lang.Object), hit the weak authentication function rule in the existing authentication rule library, mark as weak authentication structure. When running to return 1, hit the marked auth_out structure, output the authentication path state at this time as passing through a weak_auth authentication structure, judge as existing privilege escalation vulnerability, output.

[0062] The present application is further compared with the prior art in the specific embodiments. According to the method of the present application, the mainstream commercial static analysis tool Fortify SCA 20.2.2.0003 version is compared.

[0063] The test set is CVE-2023-41578, CVE-2023-6307, CVE-2023-34660, CVE-2023-34659, CVE-2023-41599, CVE-2022-27960, CVE-2018-20094, CVE-2022-28945, CVE-2018-18434.

[0064] The results are that the present application detects all these historical privilege escalation vulnerabilities CVE, while Fortify does not. According to the results, it can be shown that the present application has better functions than the prior art.

[0065] The above embodiments are only used to illustrate the technical solutions of the present application and not to limit them, and the ordinary skilled in the art can modify or equivalently replace the technical solutions of the present application without departing from the spirit and scope of the present application, and the protection scope of the present application should be subject to the description of the claims.

Claims

1. A method for detecting privilege-escalation vulnerabilities in a Java Web system, comprising the steps of: obtaining Java Web application code to be detected; converting the code to be detected into JIMPLE IR using a Soot framework; obtaining authentication-related functions and sensitive functions in the code to be detected based on a priori rule library and the JIMPLE IR; obtaining authentication exits of each authentication-related function based on whether the function call point of the authentication-related function can reach one or more sensitive functions; for any authentication-related function, extracting the function call point in the authentication-related function using the SOOT framework, and tracing the call path based on a graph path search algorithm to determine whether the call path can reach one or more sensitive functions to obtain authentication exits within the authentication-related function; for any authentication-related function, traversing the statements in the JIMPLE IR of the authentication-related function, extracting the conditionExpr expression in the IFstmt class statement code, and tracing the source function of the parameters; if the source function is determined to be a non-suspected authentication function according to prior knowledge, the authentication type is directly determined; otherwise, the authentication exit structure is generated and subsequent privilege-escalation vulnerability detection is performed; if the source function cannot be determined according to prior knowledge, a large language model is used to determine whether the source function is a suspected authentication function; authenticating the authentication path of each authentication exit structure to detect whether there is a privilege-escalation vulnerability; the privilege-escalation vulnerability includes three types of unauthenticated, weakly authenticated, and missing authentication, wherein unauthenticated means that there is an authentication path in the code structure that reaches the authentication exit through several authentication-independent structures without passing through any authentication-related structure; weakly authenticated means that there is an authentication path in the code structure that reaches the authentication exit structure through several authentication-related structures, but the several authentication-related structures include one or more weakly authenticated structures; missing authentication means that there are two different authentication paths in the code structure that reach the same authentication exit structure.

2. The method of claim 1, wherein the Java Web system's privilege-escalation vulnerability detection method is characterized by, The a priori rule library includes an authentication-related function library that stores the interfaces, annotation feature information of various authentication-related functions, and a sensitive function library that stores the class name, function name, and parameter list information of various sensitive functions. The code to be detected includes JAVAJAR packages, Class classes, and War packages.

3. The method of claim 1, wherein the Java Web system's privilege-escalation vulnerability detection method is characterized by, 4.A system for detecting privilege-escalation vulnerabilities in a Java Web system, comprising: a data acquisition module configured to obtain Java Web application code to be detected; ​ The data analysis module is configured to convert the code to be detected into JIMPLE IR by using a Soot framework; obtain each authentication-related function and each sensitive function in the code to be detected based on a priori rule library and the JIMPLE IR; obtain each authentication exit of the authentication-related function based on whether a function call point of the authentication-related function can reach one or more sensitive functions; for any authentication-related function, extract the function call point in the authentication-related function by using the SOOT framework, and track whether a call path can reach one or more sensitive functions based on a graph path search algorithm to obtain each authentication exit inside the authentication-related function; for any authentication-related function, traverse a statement in the JIMPLE IR of the authentication-related function, extract a conditionExpr expression in an IFstmt class statement code, and track a source function of a parameter; if it is determined according to prior knowledge that the source function is not a suspected authentication function, the authentication type is directly determined; otherwise, an authentication exit structure is generated and subsequent privilege-escape vulnerability detection is performed; if it is impossible to determine according to prior knowledge, a large language model is used to determine whether the source function is a suspected authentication function; The vulnerability detection module is configured to analyze an authentication path of each authentication exit structure to detect whether a privilege-escape vulnerability exists; the privilege-escape vulnerability includes three types of unauthenticated, weakly authenticated, and missing authentication, wherein the unauthenticated refers to an authentication path that reaches an authentication exit through a plurality of authentication-independent structures without passing through any authentication-related structure in a code structure; the weakly authenticated refers to an authentication path that reaches an authentication exit structure through a plurality of authentication-related structures in a code structure, but the plurality of authentication-related structures include one or more weakly authenticated structures; and the missing authentication refers to two different authentication paths that reach the same authentication exit structure in a code structure. 5.An electronic device comprising a memory and a processor, the memory storing a computer program configured to be executed by the processor, the computer program comprising instructions for performing the method of any one of claims 1-3. 6.A storage medium storing a computer program, the computer program being executed by a computer to implement the method of any one of claims 1-3.

Images