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.
Figure 1.
Accessing data of another user using vulnerability.
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.
Figure 2.
Various college web portal systems based on Nexacro.
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.
Figure 3.
Nexacro 17 framework.
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.
Figure 4.
Libraries used in the HTML code.
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.
Figure 5.
Burp Suite for analyzing the login web page.
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.
Figure 6.
Obfuscated Nexacro library.
Figure 7.
Non-obfuscated developer library.
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.
Figure 8.
Non-encrypted packets.
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.
Figure 9.
Login with another user’s ID by modifying the session ID.
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.
Figure 10.
JavaScript files loaded in a web page.
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.
Figure 11.
Requesting the necessary libraries from the CDN server.
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.
Figure 12.
Non-obfuscated source code for login (xfdl.js).
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.
Figure 13.
Web source code debugging using a breakpoint.
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.
Figure 14.
Functions and variables with vulnerabilities in uniUtil.xfdl.js.
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.
Figure 15.
Script code to view course grades using a bypass.
Figure 16.
Web page that leaks other students’ grades.
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.
Figure 17.
Script code for changing privileges.
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.
Figure 18.
System showing student absenteeism.
Figure 19.
Change in the student’s attendance status.
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.
Figure 20.
Scanning results by Acunetix.
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.
Figure 21.
Scanning results by Schemathesis.
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.
Figure 22.
Input verification and obfuscation.
5.3. HTTPS Communications
As shown in Table 1, 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.
Table 1.
Comparison.
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.
Author Contributions
Conceptualization, Y.N. and S.C.; methodology, Y.N.; software, Y.N.; writing—original draft preparation, Y.N. and S.C. All authors have read and agreed to the published version of the manuscript.
Funding
This research was supported by the Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education (RS-2023-00237159).
Data Availability Statement
The data are not available because of security limitations.
Conflicts of Interest
The authors declare no conflicts of interest.
References
- Jo, H.; Lee, S.-K. A study on the switching intention of the legacy data interchange system toward the portal system. e-Bus. Stud. 2011, 12, 349–370. [Google Scholar]
- Available online: https://www.dailysecu.com/news/articleView.html?idxno=150237 (accessed on 19 April 2024).
- Ma, R.; Chen, L.; Hu, C.; Xue, J.; Zhao, X. A Dynamic Detection Method to C/C++ Programs Memory Vulnerabilities Based on Pointer Analysis. In Proceedings of the 2013 IEEE 11th International Conference on Dependable, Autonomic and Secure Computing, Chengdu, China, 21–22 December 2013; pp. 52–57. [Google Scholar]
- Available online: https://docs.tobesoft.com/edu_nexacro17_basic_kr/f5e3b1075adf59da (accessed on 19 April 2024).
- Othman, M.; Ismail, S.N.; Noradzan, H. An adaptation of the web-based system architecture in the development of the online attendance system. In Proceedings of the 2012 IEEE Conference on Open Systems, Kuala Lumpur, Malaysia, 21–24 October 2012; pp. 1–6. [Google Scholar]
- Newman-Ford, L.; Fitzgibbon, K.; Lloyd, S.; Thomas, S. A large-scale investigation into the relationship between attendance and attainment: A study using an innovative, electronic attendance monitoring system. Stud. High. Educ. 2008, 33, 699–717. [Google Scholar] [CrossRef]
- WAS. Available online: https://en.wikipedia.org/wiki/Application_security (accessed on 19 April 2024).
- RIPS. Available online: https://en.wikipedia.org/wiki/RIPS (accessed on 19 April 2024).
- ESLint. Available online: https://eslint.org/ (accessed on 19 April 2024).
- Kore, A.; Hinduja, T.; Sawant, A.; Indorkar, S.; Wagh, S.; Rankhambe, S. Burp Suite Extension for Script based Attacks for Web Applications. In Proceedings of the 2022 6th International Conference on Electronics, Communication and Aerospace Technology, Coimbatore, India, 1–3 December 2022; pp. 651–657. [Google Scholar]
- Muralidharan, M.; Babu, K.B.; Sujatha, G. W3BnNr: An Automated tool for information gathering, vulnerability scanning, attacking and reporting for injection attacks on web application. In Proceedings of the 2023 Advanced Computing and Communication Technologies for High Performance Applications (ACCTHPA), Ernakulam, India, 20–21 January 2023; pp. 1–4. [Google Scholar]
- Hatfield-Dodds, Z.; Dygalo, D. Deriving Semantics-Aware Fuzzers from Web API Schemas. In Proceedings of the 2022 IEEE/ACM 44th International Conference on Software Engineering: Companion Proceedings (ICSE-Companion), Pittsburgh, PA, USA, 21–29 May 2022; pp. 345–346. [Google Scholar]
- Badih, H.; Alagrash, Y. Static Analysis Framework Based on Multi—Agent System. In Proceedings of the 2020 IEEE International IOT, Electronics and Mechatronics Conference (IEMTRONICS), Vancouver, BC, Canada, 9–12 September 2020; pp. 1–9. [Google Scholar]
- SonarQube. Available online: https://www.sonarsource.com/ (accessed on 19 April 2024).
- Scandariato, R.; Walden, J.; Joosen, W. Static analysis versus penetration testing: A controlled experiment. In Proceedings of the 2013 IEEE 24th International Symposium on Software Reliability Engineering (ISSRE), Pasadena, CA, USA, 4–7 November 2013; pp. 451–460. [Google Scholar]
- SG, N.K.; Madugundu, P.K.; Bose, J.; Mogali, S.C.S. A Hybrid Web Rendering Framework on Cloud. In Proceedings of the 2016 IEEE International Conference on Web Services (ICWS), San Francisco, CA, USA, 27 June–2 July 2016; pp. 602–608. [Google Scholar]
- Ryu, D.H.; Kim, H.J.; Um, K. Reducing security vulnerabilities for critical infrastructure. J. Loss Prev. Process Ind. 2009, 22, 1020–1024. [Google Scholar] [CrossRef]
- Bau, J.; Bursztein, E.; Gupta, D.; Mitchell, J. State of the Art: Automated Black-Box Web Application Vulnerability Testing. In Proceedings of the 2010 IEEE Symposium on Security and Privacy, Oakland, CA, USA, 16–19 May 2010; pp. 332–345. [Google Scholar]
- Ganesh, V.; Kieżun, A.; Artzi, S.; Guo, P.J.; Hooimeijer, P.; Ernst, M. HAMPI: A string solver for testing, analysis and vulnerability detection. In Proceedings of the 23rd International Conference on Computer Aided Verification, Snowbird, UT, USA, 14–20 July 2011; pp. 1–19. [Google Scholar]
- Almorsy, M.; Grundy, J.; Ibrahim, A.S. Supporting automated vulnerability analysis using formalized vulnerability signatures. In Proceedings of the 27th IEEE/ACM International Conference on Automated Software Engineering, Essen, Germany, 3–7 September 2012; pp. 100–109. [Google Scholar]
- Acunetix. Available online: https://www.acunetix.com/ (accessed on 19 April 2024).
- Anis, A.; Zulkernine, M.; Iqbal, S.; Liem, C.; Chambers, C. Securing Web Applications with Secure Coding Practices and Integrity Verification. In Proceedings of the 2018 IEEE 16th International Conference on Dependable, Autonomic and Secure Computing, Athens, Greece, 12–15 August 2018; pp. 618–625. [Google Scholar]
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content. |
© 2024 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).