Analysis of Vulnerabilities in College Web-Based System

Abstract

Web-based systems are used extensively in Korea because web standards have been adapted by the law (e.g., Electronic Government Act). Users can easily access web-based systems if they are connected to the Internet. However, distinguishing between malicious and benign access is very difficult and many potential vulnerabilities exist. In this study, we attempt to leak the information of other users without permission using a non-encrypted API and web source code analysis in a college web-based system. An experiment demonstrates that the information (e.g., other students’ course grades) can be leaked and abnormal data can be embedded in the request. In addition, we discuss methods for preventing such vulnerability attacks.

1. Introduction

Web-based systems are commonly used to manage large amounts of data in government offices and universities in Korea. In universities, web-based systems are used for student attendance, records, and grade management. Web-based systems can be accessed by students and employees, as well as by outsiders such as applicants. Web standards have been adapted by the law (e.g., the Electronic Government Act) in Korea since 2020 [1]. Therefore, these systems do not depend on a platform and can be accessed whenever the Internet is available.

However, distinguishing malicious requests that are sent by attackers using source code analysis tools or debuggers from benign requests is difficult. For example, in 2023, at a university in Korea, a system was developed to send all parameters in a request without using role-based access control. If these parameters were modified, attackers could obtain the data of other students without any proper privileges [2].

Such vulnerabilities can be identified through the entire system and dynamic analyses. First, the entire system can be analyzed to determine the correlations between system components. Second, new vulnerabilities can be identified through debugging. A new vulnerability that is identified can also affect other systems [3].

Nexacro is a commonly used platform in college web-based systems in Korea [4]. In this study, we analyze a web-based system using Nexacro, identify three vulnerabilities, and obtain leaked data using the vulnerabilities, as shown in Figure 1. An attacker without legitimate privileges can obtain the data of other users using such vulnerabilities. In addition, we found that the vulnerabilities can affect other subsystems. When an attacker uses these vulnerabilities, the requests are regarded as benign. We experimentally demonstrate that data can be leaked from other users in this manner.

The contributions of this study are as follows. First, we describe two vulnerability analysis methods. Second, we present the three vulnerabilities identified in the target system using Nexacro. Third, we provide two methods for preventing these vulnerabilities.

The remainder of this paper is organized as follows. In Section 2, we introduce the related studies. The two vulnerability analysis methods are presented in Section 3. In Section 4, we outline the three identified vulnerabilities. Methods for preventing these vulnerabilities are discussed in Section 5. Finally, Section 6 concludes the paper.

2. Background and Related Work

2.1. Background

2.1.1. Web-Based Systems

Web-based systems are business process systems that enable users to process and access tasks online. Users can access a web-based system from any location provided that they have web browsers and are connected to the Internet. Many existing systems have become web-based systems in recent years. These systems support multiple users and save time and costs through distributed processing [1].

For example, in a university setting, professors can check whether students attend classes when they log on to a web-based system. In addition, because attendance records are updated automatically by the system, it can save the instructor’s efforts.

2.1.2. Web Source Code Analysis

If vulnerabilities exist, important information may be leaked from the system to an attacker. Therefore, a web source code analysis, which analyzes the source code of web-based systems and identifies their vulnerabilities, is crucial [5].

According to CVE, approximately 90,000 vulnerabilities have been detected since 1999. A total of 14,518 vulnerabilities were identified in 2017 alone. In particular, SQL injection, cross-site script (XSS), remote command execution, and file upload attacks are widely used and difficult to prevent [6].

Entire system and dynamic analyses are required to identify and eliminate these vulnerabilities. Static analysis tools such as WAS [7] or RIPS [8] can be used for the entire system analysis. As of recently, potential vulnerabilities can be identified using ESLint [9]. In addition, vulnerabilities can be identified when the system is running using a debugger or the Burp Suite [10].

2.2. Related Work

Two types of attacks can be carried out on web-based systems: denial of service (DoS) and the use of vulnerabilities through a source code analysis.

2.2.1. DoS Attacks

DoS attacks are used to induce a DoS state in the system by tampering with packets or using a large amount of network traffic. In 2023, Himanshu et al. proposed the Winguardian system [11]. Their work prevented HTTP DoS attacks using firewall filtering and improved false positive rates using dynamic fuzzy reasoning. However, this method is limited to Windows systems and requires significant system adaptation because many large systems use separate firewalls.

2.2.2. Web Vulnerability Attacks

Web vulnerability attacks include XSS, non-encrypted API, and random debugging attacks. In 2023, Muralidharan et al. proposed the W3BnNr system [12]. Their work analyzed the vulnerabilities, collected information, and used automated attacks. However, adaptation is challenging because firewalls can block it. Conversely, our method is considered benign and is not prevented by firewalls.

2.2.3. Differences between the Existing Work and Ours

If a vulnerability occurs in the main web-based system, the subsystems can also be affected, and important information may be leaked. Thus, in this study, in addition to using the attack methods, we analyzed the vulnerabilities affecting other systems.

3. Vulnerability Analysis

In this section, we describe the vulnerability analysis of the target system. In Section 3.1, we explain the Nexacro system, which we used as our target. In Section 3.2, we introduce two methods for analyzing vulnerabilities.

3.1. Nexacro System

We analyzed the college web portal system Nexacro [6], as shown in Figure 2. This system is used extensively by many universities in Korea and includes many subsystems for students and employees. Students can receive lecture content and check their course grades, and professors can assign grades to their students using the system.

As the main system is connected to various subsystems, its vulnerability has a significant impact on the subsystems. In addition, owing to the widespread use of Nexacro in universities across Korea, newly identified vulnerabilities can help to improve the security of many college web portal systems.

As shown in Figure 3, the unified environment is supported by the Nexacro framework. A unified environment does not depend on the operating system and provides a set of libraries to guarantee the same operation. The framework comprises two parts: the form for the GUI and the manager for interaction with the web browser engine.

First, the form loads an XML file (form.xfdl). It manages the attributes of each component, binding, and event information. It assigns styles and themes to the view engine of the web browser. Second, the manager assigns the dataset and libraries that are commonly used for interactions to the processing engine of the web browser. We analyzed the Nexacro libraries that are commonly loaded, and libraries used by developers in the manager.

3.2. Analysis Methods

A full system analysis and precise analysis of each function are required to identify vulnerabilities. We outline the respective analyses in the following subsections.

3.2.1. Entire System Analysis

An entire system analysis investigates the relations among the system components [13]. The libraries used in the source code and which systems use the libraries need to be determined to obtain the system information. For this purpose, automated source code analysis tools (e.g., SonarQube [14]) can be used or the full system structure can be understood from the development documents provided by the company.

First, we investigated the libraries used in the HTML code to understand the system operation. As shown in Figure 4, a library (nexacro14lib) exists that loads the entire page after it loads the other library (jbnuNexacroLibLoad.js). We found that it loads the unified libraries as well as the libraries selected by the developer.

3.2.2. Dynamic Analysis

A dynamic analysis involves debugging a system in real time. A penetration test can be performed during debugging [15] to analyze the target that is running dynamically. Thus, we analyzed the operation of the system to understand the real-time procedures and data flow.

The intercept function of the Burp Suite [10] is used to analyze the login web page, as shown in Figure 5. Using the intercept proxy of the Burp Suite, the request and response between the browser and web server can be modified. In addition, the system can easily be analyzed using a web spider.

As shown in Figure 6, the Nexacro library is obfuscated and only data requested by the client are provided. However, because the developer library is not obfuscated, as shown in Figure 7, and is widely used in other parts, the data can be modified. The results of the analyses are presented in the following section.

4. Analysis Results

We identified the three vulnerabilities outlined in this section using the analysis methods presented in Section 3. We describe the vulnerability from a non-encrypted API in Section 4.1, the vulnerability from the library in Section 4.2, and the vulnerability affecting other systems in Section 4.3.

4.1. Non-Encrypted API

The first vulnerability is the non-encrypted API. A browser uses a protocol such as the REST API to communicate with the web server for a web service. If encryption is not used, an attacker can obtain the data between the browser and server. In Figure 8, the request and response packets are not encrypted.

As shown in Figure 9, an attacker can log in as a different user by modifying the data of the packet to perform an overflow attack by adding a part requesting other data. As the request packet is not encrypted and no packet verification part exists in the server, the modified packets can be sent to the server. For example, data for which an attacker does not have privileges can be obtained by modifying the packet data using the Burp Suite.

4.2. Library Vulnerability

The second problem concerns library vulnerability. Web source codes, such as HTML and JavaScript, are transmitted to the browser and can easily be analyzed by an attacker if they are not encrypted. The attacker can then perform an injection, XSS, or upload attack as well as negatively affect the system by analyzing it.

As shown in Figure 10, various HTML, CSS, and JavaScript files are always loaded in our target system. In addition, the client-side rendering (CSR) method [16] is used to create a web page dynamically according to the request of the user.

In the CSR method, the server sends data only to the browser to save the network bandwidth, and the browser creates a web page for the user. The browser obtains the libraries that are required from another server (for example, cdn.*.ac.kr), as shown in Figure 11, and loads the Nexacro libraries in addition to them.

Subsequently, the browser requests the necessary libraries to the server to render a login web page. The source code can be viewed if it is not obfuscated, as illustrated in Figure 12.

When the source code is not obfuscated, a breakpoint that is supported by the web browser can be used for debugging, as shown in Figure 13. Because it can stop or skip the program before it, its effects on the system can be tested. This analysis method is considered as a normal activity by the server.

Some companies provide protection solutions to prevent these types of analyses. However, they are limited in that they cannot support various operating systems or platforms [17].

As indicated in Figure 14, we found that a variable (useYn) and function (conditionCheck) have injection vulnerabilities. This function sends a query to the server and is based on the other function (gfnTransaction) that is provided by the Nexacro system. However, because the parameters are not encrypted, their meaning can be obtained.

The variable (byUserSystemIntent) refers to the database name, and the variable (byUserSystemQuery) refers to the query. An attacker can send a forged query by modifying these variables.

However, the server sends a token to the browser to determine the legitimacy of the browser. Subsequently, the browser sends a request with the token. When the token is the same, the server sets the variable (useYn) to true and proceeds to the next step. The same token can be used and the variable (useYn) set to true to bypass this procedure, after which the request can be modified accordingly. This is the second vulnerability of the system that we identified.

As shown in Figure 15, we wrote script code to exploit this vulnerability. After checking whether the token was the same, we set the variable (useYn) to true. We added a new function (gbvUniCallback) to lines 20–25 to modify the grade table name. Finally, we could view the course grades without permission, as indicated in Figure 16.

4.3. Vulnerability Affecting Other Systems

In this section, we describe a new attack method that affects the subsystems by bypassing the user privilege verification using the vulnerability introduced in Section 4.2. This vulnerability can affect other subsystems and is difficult to detect.

We investigated whether the vulnerability affects the learning management system (LMS). In the LMS, the browser obtains user information from the main system. Students, professors, and employees have access to special information tokens.

The LMS can distinguish students from professors or employees using the special tokens. For example, students can only modify their information during the semester, whereas professors and employees can modify the information at any time.

Therefore, we modified the source code on the client side to change the privileges using the tokens.

As shown in Figure 17, the script code checks whether the lecture exists in line 14. If it does not, the token is obtained in line 18. In line 24, the attacker obtains the privilege of the professor.

As shown in Figure 18 and Figure 19, we modified the attendance records to indicate that all classes had been attended, even if the classes were not actually taken.

5. Discussion

In this section, we introduce two methods for preventing the vulnerabilities described in Section 4: web vulnerability scanning tools and secure coding.

5.1. Web Vulnerability Scanning Tools

Many web vulnerability scanning tools do not depend on programming languages or platforms. However, these tools analyze only well-known vulnerabilities [18]. As these tools cannot integrate new vulnerabilities, identifying vulnerabilities in specific modified systems is difficult. [19] Therefore, a specific tool should be used to analyze such modified systems and integrate new vulnerabilities [20].

For example, a web vulnerability scanning tool such as Acunetix [21] can identify vulnerabilities defined by security analysts and can perform a dynamic analysis using the analysis workflow engine. Using this method, we identified a non-encrypted API and cross-origin resource sharing in our target system, as shown in Figure 20.

Furthermore, fuzzing tests are useful for identifying vulnerabilities as shown in Figure 21. Schemathesis was used to perform the fuzzing test [12]. When we tested the web system by using Schemathesis, it showed that there are two vulnerabilities: exceeding-column-size and improper-input-type-handling. We believe that using the fuzzing test will help develop the system more efficiently and securely.

5.2. Secure Coding

Secure coding should be adopted to prevent attacks such as SQL injection, XSS, or random resource attacks. Secure coding is used to develop more secure software by eliminating vulnerabilities [22]. Input data verification, exception handling, and API misuse prevention can be used for secure coding. We show that library vulnerabilities can be prevented using input data verification.

As mentioned in Section 4, SQL injection and random resource attacks were performed because the input data were not verified. The source codes should be obfuscated, and SQL queries should be verified to prevent these attacks. Therefore, abnormal input data must be avoided.

In the target system, the attacker can easily modify the SQL queries because they are not obfuscated. However, as shown in Figure 22, if input verification and obfuscation are implemented, analyzing the source code is difficult and the modified input is filtered in the input verification.

5.3. HTTPS Communications

As shown in

Table 1. Comparison.

Vulnerability	HTTP	HTTPS
Non-encrypted API	O	X (Attack failed)
Library vulnerability	O	△ (Attack partially failed)
Vulnerability affecting other systems	O	O (Attack success)

, we used HTTPS to test for vulnerabilities. First, we could not use Burp Suite to modify the packets in the non-encrypted API because of the encrypted packet headers. Second, because the request contained encrypted headers, attacks against the library vulnerability occasionally failed. Finally, the attacks were successful in the third vulnerability because the token was not encrypted. Using HTTPS improved security in some cases. However, the attacker could exploit other vulnerabilities in other cases.

6. Conclusions

We have presented the vulnerabilities that were analyzed and identified in a target system using Nexacro: a non-obfuscated API, a library vulnerability, and a vulnerability affecting the other subsystems. We demonstrated that important information can be leaked using these vulnerabilities. First, the attacker could log in to the system as the other user using the non-obfuscated API. Second, the attacker could obtain other students’ course scores without authorization by exploiting the library vulnerability. Third, attackers could change the class attendance records by exploiting the vulnerability that affects the other subsystems. In addition, we discussed methods for preventing these vulnerabilities, namely web vulnerability scanning tools and secure coding.

Web portal systems are used extensively because many users can easily obtain information. However, excessive private information may be leaked if these systems are not securely managed. In future work, we will attempt to identify additional vulnerabilities in other domains such as software-defined vehicles and industrial control systems.