1. Introduction
Exploits to manipulating data or compromising personal information are becoming widespread. Former researchers have found poor awareness of cyber security and lacking adequate time to test and QA web applications that both contribute to XML injection attacks, but they did not clearly illustrate how vulnerabilities could be exploited over real operating systems. [1] These attacks can be on the Application layer or deeper at the O/S level. Once infiltrated, the hacker can effectively work through the entire system leaving their mark that could be time bombed or dominant until an action is taken by an Input/output device. Our research will start with a translation tool commonly used on web applications and move to other areas of the system that can be exploited. There is a cost trade-off between securing data in a computer system and processing speed of transactions. This balance is consistently under scrutiny for program effectiveness, user expectations, and privacy breaches. As of late, there have been several data breaches published involving personal information. Man-in-the-middle attacks are quite prevalent where a hacker injects malicious code within the system and can exploit Admin information, including password information, and then use that information to look at files and stored customer information.
2. Types of XML Attacks
Server or client-side attacks can look benign at the surface, however digging deeper, it can be uncovered that the attacker has compromised the core of the operating system, which could influence processing speed, temperature, and shared resources. Unix, Linux, Windows, cloud-based systems, and hosted environments are all vulnerable to attacks, the most prevalent attack being brute-force which is an injection attack or Denial of Service (DOS) that denies services from the system and can attack the operating system rendering it useless. [2] Operating system security is vital but hard to achieve. Operating systems mainly run processes and allocate resources. Generally, one does not think about having an operating system compromised, but it can occur. When it does the novice user probably would not notice, and detection systems would have to be used to determine compromises. [3]
There are different types of XML attacks. First of all, if there is a file that has contents in the external entity and responds to an application request, this would be defined as retrieving documents by exploiting the XML external entity (XXE) injection attack. Secondly, when an intruder retrieves some sensitive data from performing a server-side request forgery attack, this way could be classified as making HTTP requests to some seriously vulnerable URLs that the application server could access to exploit an XML external entity vulnerability in a back-end targeted system. Thirdly, if a hacker could be able to exploit blind XML external entity injection attack for exfiltrating confidential information that is mainly transferred from an application server to a system which is controlled by the attacker, we could define this to be exploiting blind XML external entity exfiltrating data out-of-band. The final one is an attacker launches blind XXE vulnerability for triggering an XML parsing error message which includes some of the sensitive information that the attacker wants to retrieve. [4] (Figure 1)
3. Vulnerable Functions
Demonstration of a compromised system using a Linux virtual machine, we used a commonly used web application developers’ tool; Extensible Markup Language (XML) to illustrate how easy it is to inject malicious code into the translation process. XML itself is quite outdated but is still widely used by developers for clients who would like to customize their information on invoices, reports, and web pages. There are already documented vulnerabilities with XML including two XML Billion Laughs (BIL), this vulnerability is known for inserting thousands of LOL messages into the system each time a line of code runs it exponentially adds LOL into the system compromising the CPU utilization and resources until the system is rendered useless. This is an example of a code injection in the web application however quickly affecting the processor speed and resources of the CPU. [5]
To retrieve data from a file system in the server-side application, an attacker needs to make modifications to the submitted XML via two different methods. The first one is the attacker editing a DOCTYPE element to define an external entity which includes the path to the targeted file. the other one is to exploit defined XXE when introducing an information value of an XML, which is used to make a returned response in the application server.
For instance, assuming a sugar application checks for the production level of a product by using the below XML to the MySQL database server:
e n c o d i n g = ”UTF 8”?>
128
The MySQL database in the bWAPP application server does not have specific defenses against XML external entity attacks so hackers could have the ability to exploit this kind of vulnerability to retrieve various root passwords such as Linux root password and Apache password.
We could see how to submit XXE payload for retrieving Linux root passwords from two different file paths including /etc/password and
/etc/shadow below:
SYSTEM ” f i l e : / / / e t c / shadow”> ]>
&xxe ;
[
” f i l e : / / / e t c / passwd”> ]>
&xxe ;
Because XML external entity injection attack has defined xxe to point to the targeted value of file contents in either /etc/password or
/etc/shadow and take especial entity within a defined value of productid. Therefore, the bWAPP application server could have responded to the following file contents:
Invalid product ID: root:x:0:0: root:/root:/bin/bash
daemon:x:1:1:daemon:
/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin
/ n o l o g i n , , , , , ,
As captured request and response in Figure 2.
There have been instances where people have explored the potential vulnerabilities associated with Extensible Markup Language (XML) and its use in translation processes. Florian as a PhD student discovered an accidental XML injection attack on his blog which he could hack a web server of the University via XML code injection. His personally identifying information had been displayed along with similar data of other users by simply deleting one number from the ID field of the applicant. There are some vulnerable surfaces’ examples including applications that rely on XML-based protocols, applications that store XML documents in a database, and applications that support XML-based document formats and data import, etc. XML injection study found that a threat actor could bypass web app authentication measures of a user, read an organization’s stored sensitive data, modify XML files of a user, and carry out XML-based denial of service attacks. [1]
4. Exploiting an XML Attack
In our project, we use two different ways to perform an XML attack. The first is
![]()
Figure 2. The XML external entity injection attack [4] .
using Bee-box software and bWAPP web application to exploit a typical XML attack which is always launched by an attacker to verify that manipulation is possible. Bee-box software mainly offers kind of ways to hack and deface the bWAPP website and we would conduct various penetration tests for people to discover and prevent web vulnerabilities. [6] After successfully collecting the IP address for a targeted hostname, the attacker could be able to launch an XML injection attack. During this process, I will be going to explain step-by-step instructions with clear screenshots to show our project’s results. Our XML attack needs to get an IP address for a database server or web application server so that we select Bee-box software which has a pre-installed bWAPP database server on the virtual Linux operating system and do not need to figure out some of the configuration files for the Linux VM machine to connect to the bWAPP database server. On the other hand, Bee-box allows us to explore all bWAPP vulnerabilities and hack the bWAPP website to get root access. To make XML attack work on the bWAPP website, we will need to set the security level to be “low” mode on the login page of the bWAPP website which could keep itself an insecure web environment and automatically turn off some mitigation mechanisms of their website.
Now let’s start our XML external entity attack towards the first virtual Linux OS machine. The first step is to select a low-security level on the login page of the bWAPP website. At the same time, we could run a specific command ¡ifconfig¿ to get an IP address for the targeted hostname as shown in Figure 3.
Next, we are going to log in bWAPP website by using the default credentials as Figure 4 shown: After having successfully logged in bWAPP website at http://localhost/bWAPP/login.php, we could choose one of the XML attacks from dropdown options of various vulnerabilities as Figure 5.
As we mentioned earlier, Bee-box as a Linux VM machine has pre-installed with bWAPP so that we could directly use it to hack the bWAPP website to get root access by exploring one of the above specific XML external entities vulnerabilities.
![]()
Figure 3. An IP address for the targeted hostname.
![]()
Figure 4. Default credentials for logging in bWAPP website.
![]()
Figure 5. The XML external entity injection attack from Bee-box VM machine.
The second way is we think using XAMPP-VM software with the bWAPP tool in the MAC operating system because XAMPP is a crossing platform, which provides kind of local database, application, and web servers such as Apache, MySQL, PHP, and Perl on our current physical computer. What’s more, it has automatically disabled some security features for different people like penetration testers or students to work on their PC works without accessing to internet. [8] . (Figure 6)
From Figure 7, we could use XAMPP to automatically assign an IP address for our local host at 192.168.64.2 and then click on Volumes tap to go directly inside of configuration location for resetting kind of PHP files before trying to communicate with the bWAPP website as Figure 8.
![]()
Figure 6. XAMPP tool for setting up a local database server (bWAPP) [7] .
![]()
Figure 7. XAMPP tool for assigning an IP address for a local host.
![]()
Figure 8. XAMPP tool for setting up a local database server (bWAPP).
To connect to the bWAPP database local server on the MacOS computer, we have to first reset some of the PHP configuration files that are used for matching our local bWAPP database information including database username, database password, database hostname, and database name.
Figures 9-12 show updated configuration files before successfully logging in to the bWAPP website on the MacOS. [9]
Once above all configuration files have been correctly reset, we can open the bWAPP website at http://192.168.64.2/bWAPP/login.php.
Like the first XML exploiting method we mentioned before, we could enter the same default credentials to log into the bWAPP website as Figure 13. Then, we go to select one of the XML attack options after logging in bWAPP portal as Figure 14 shows.
From Figure 14, we can observe bWAPP website is an insecure web application server on the local machine when having the security level set to low mode since there is an insecure alert message at the top of the URL address bar and the security level information is listed at the top right corner of bWAPP main page. The bWAPP website has over 100 vulnerabilities which could be used for testing security issues in the different hosts supported by XAMPP. (Figure 14)
5. XML Exploitation Results
To analyze XML exploitation results, we could use a professional web vulnerability scanner, which is called Burp Suite Free Edition. [10] The main reasons are explained below: [11] .
1) Attacking web application or web services tool B. Doing penetration testing on the targeted web application C. Capturing requests and responses after launching an XML attack D. Scoping our targeted application properly E. Having the ability to trigger potential security vulnerability toward a vulnerable operating system F. Digging deep into exploitation results and validating our findings After having the Burp suite free edition installed on our current MacOS, we could use an intruder tool to carry out an automated XML attack against web applications. Next, we manually manipulate and reissue an individual HTTP request and analyze the corresponding application by selecting the repeater tool from it. (Figures 15-18)
To decode the targeted application information, we could use the Decoder feature which is one of Burp suite free edition tools as below in Figure 16.
We have found a document type definition (DTD) contained in the XML documents that enables definition functioning in the XML entities via offering a substitution string in generating a URL. The XML parser accessed the contents of the URL and transformed them back into the XML documents for further processing. During submission of an XML file which may have defined an external entity with a path location of a file, a hacker could first make a processing application to read the contents of a local file and then force the application to generate outbound requests to web servers that the hacker is unable to reach directly but could be able to bypass firewall restrictions or hide the source of XML
![]()
Figure 9. Modified configuration file in install.php for bWAPP (database).
![]()
Figure 10. Modified configuration file in config.inc.php for bWAPP (database).
![]()
Figure 11. Modified configuration file in the connecti.php for bWAPP (database).
![]()
Figure 12. Modified configuration file in Settings.php for bWAPP (database).
![]()
Figure 13. Using the same Default credentials for bWAPP website login page at http://192.168.64.2/bWAPP/login.php on MacOS machine.
![]()
Figure 14. The XML external entity injection attack from XAMPP-VM machine with bWAPP installed on the local MacOS.
![]()
Figure 15. The XML injection payloads inserted into the web-based request on the intruder tool in the Burp Suite Free Edition.
![]()
Figure 16. Decoding application information on the decoder tool in the Burp Suite Free Edition.
![]()
Figure 17. Manual manipulating HTTP request and application responses analyzing via the Repeater tool in the Burp Suite Free Edition.
![]()
Figure 18. Application responses analyzing on the Repeater tool in the Burp Suite Free Edition.
attacks to make application response with sensitive data in the returned error message. The hacker uses XML injection to exploit vulnerabilities in the processing application and deploys malicious payloads to get unauthorized access to sensitive stored data which allows the hacker to construct queries to modify XML documents based on the XML-enabled database. What’s more, the hacker takes advantage of entering improperly formatted queries on the application’s front end so that the unvalidated input would trick the web system into passing the information onto web servers. [1]
On the other hand, due to insecure web environments, limited access to system resources may have been decreased which could cause too many resources could be accessed by attackers, such as memory, network connections, CPU, or access points. A hacker would be able to use XML injection to add themselves to the table of a user database of the web application. The hacker uses the web application to build a node that would be added to the XML-enabled database that offers the hacker access to read whatever data are accessible to the profile which has been given administration privileges. One known vulnerability has been posted by the National Institute of Standards and Technology (NIST) as CVE-2022-25251. The hacker could send XML messages to a specific port when they bypass the web application’s authentication for reading the targeted web system’s configuration data. [1] Finally, a degradation of the quality of authentication could be triggered by weaknesses of limitation of accessing web applications or web services if originally not addressed in designing or deploying a secure architecture of system resources.
When an XML external entity reference is not properly restricted, the XML parser may consume excessive CPU cycles or fixed memory via a URL that directs to a big-size file. If the file referred to by the URL includes too many nested or recursive entity references, it could make the parsing process very slow due to too much resource consumption in the CPU and memory.
6. Mitigating and Detecting XML Attacks
Before diving into mitigation strategies and the detection of XML attacks it is prudent to understand the basics of a computer security model strategy. A computer security model should always have three main goals that need to be achieved: Confidentially-personal data needs to be held in strict confidence and not compromised to others. Integrity of system operations, expected results of processes should be accurate; when requesting a system process the results should be accurate; and should not collide with other processes running concurrently. Availability - the system resources should be available for use when the system is needed. This includes but is not limited to having the CPU not dominated by one resource or process. Through scheduling the proper prioritization should be given to each of the processes to run the system efficiently with minimal resources and power. [3] When one of the components of the security model is compromised the main goal of the computer is jeopardized. Proper mitigation techniques and detection components are crucial to have a system that has integrity, is available, and can be used with confidence. Mitigation techniques can be viewed as cost avoidance and embarrassment. Quite often an exploit is found through code that is open to the general public, unsecured, and without proper restrictions. The exploitation described above can be mitigated if the developer is aware of the logistics of the translator tool commonly used in web application development. As described and demonstrated with the XML exploitation above, the XML External Entities (XXE). [5]
Using Extensible Stylesheet Language Translator (XSLT) methods can target production systems halting daily operations. It is a web security vulnerability that allows a hacker to interfere with an application’s processing of XML data. Accessing external entities allows hackers to modify references in the parsers and obtain personal information. Disabling the use of external style sheets and inserting the style sheets locally would prevent this from happening. Other options to mitigate the risks of an XML attack would be to
1) Avoid user-provided XML translation documents, 2) Do not generate translation documents from untrusted input. If there is a variable that is needed then include the variable in the data file and not have it inputted manually, 3) Disable all dangerous functionality implemented by the translation library, which includes embedded scripting extensions that allow reading or writing external files. [12]
One instance of revealing password information can be avoided by eliminating the external references within the files. This sample code from the vpnmentor.com blog
/ / / e t c / p a s s w d >]>&xxe ;
( vpnmentor . com ) is an example
where user or Administrator password information can be divulged. Disabling the document type definition (DTD) is one way to protect against an XML attack. The DTD can be declared inside an XML document and does not have to use an external reference thereby eliminating the potential vulnerability. Another way to eliminate the EEX vulnerability is to upgrade the parser to a more modern library that does not have known vulnerabilities.
A denial of Service (DOS) attack a “Billion Silent Laughs” mentioned above a well-documented XML vulnerability where an XML blob is used to create an entity called “LOL” and uses entity expansion to consume a large amount of memory and CPU power or could bring down the entire system. A mitigation strategy is to define a maximum length size on the XML local entity expansion, prohibiting the server from consuming too many resources by using XML parsing. Even though we are speaking of a 3GB file it can still slow the server and CPU speed down considerably, and it did not find the file can continue to expand rendering the computer useless. Penetration testing is commonly used in many types of industries and can avoid or elevate putting insecure code into production environments. Unfortunately, Penetration testing can be expensive and smaller companies opt out of such endeavors. Knowing the most significant vulnerabilities and testing for those is better than the absence of testing. Watching for spikes in CPU memory load or an increase in memory utilization would be key to discovering an exploit. Targeting encapsulated code; and elimination of external references and libraries; which would prohibit the exploit from happening would be the goal.
7. Detecting an XML Attack using Modern Techniques
Detecting an XML attack before it happens would be ideal. Recently, there has been development work in the area of signature-based detection systems, which evaluate the payload and identify an attack through contexts. Indirect attacks on the CPU happen when Web Applications are attacked and exploited. Prevention of application attacks intrinsically helps protect the operating system. Most attacks begin with receiving untrusted XML information. A good remediation strategy to avoid XML attacks would be to not accept untrusted, unverified XML information. Although easy to say hard to institute, as inexperienced developers unknowingly accept untrusted information. In a recently published article by MicroSoft professionals, they described and demonstrated how client-side XML exploitations can occur. In the same article, they recommended three configurations to avoid attacks. [13] 1) Disable DTD processing, and configure the parser to not process DTD’s. By default, this setting in a .net framework should be DTD-prohibited. 2) Tighten up Error Handling and ensure exception messages are clear. In general application error should be handled by the application itself and return a generic message to the user. If the error message returns explicit instructions the attackers have enough information to exploit the system in other ways. 3) Set Content-Disposition for XML Downloads. If uploading and downloading using XML is a must for the application set the HTTP Content-Disposition response header. The header forces the user to download the needed file instead of having the browser access the file directly. [13]
7.1. Automated Testing Tools for XMLi
Thorough testing of XML applications will prohibit attacks but cannot guarantee that that will not happen. In a published document on the automatic tests to Exploit XML injection vulnerabilities, the authors go through extensively how to test the XML code to validate there are no weaknesses in the accessing of libraries or external entities with the Service Oriented Architecture that is generally used to manipulate files on the backend of the web application. [5] XML uses several modular tools, one of them is a Services Oriented Architecture (SOA) that moves or manipulates files. Web applications receive input from users on the front end and manipulate data by calling on other services such as SOA to translate data. The user data has to be properly validated to prevent XML attacks. This is very time-consuming for the processor and takes vital resources if each file external to the web application has to be verified by the processing of that file. [5]
7.2. Strategy Based Detection Systems
As we demonstrated there is potential to generate an attack on XML web applications that could influence system resources and utilization. These are detrimental to systems that are running constantly. One was to protect Web services applications through a signature-based detection system. This approach uses a signature on the payload that identifies an attack through a context. These signatures are known to have a low rate of false positives and can alert a system Administrator of a potentially fault file. However, there is a downside to using a signature-based detection model. It does not recognize unknown attacks. So, it will not help in a zero-day attack situation. [14] An alternative to signature-based detection is a knowledge-based detection system. This approach would have previously known and cataloged behavior, in which the system would access and routinely process the normal class of files. and when a detection of an abnormal file would be known, it would quarantine the file until further action could be taken. This approach can detect new attacks however, it does produce a lot of false positives. This approach would not be the best use of the system resources as it has to classify the files The authors of the signature-based and knowledge-based detection system were trying to shorten the gap between the zero-day attacks and having the detection system function appropriately, eliminating the high rate of false positives by introducing an Ontology that is composed of classes and properties. We will not go into all the details of the approach in this paper, but if the reader would like more information, it can be found in the reference section. [14] (Figure 19)
8. Conclusions
Although this paper explicitly focuses on XSLT translation tool exploits; It is worth mentioning that there are other ways to infect the system besides through the translation tool. Since XML is the most widely used web application scripting language more visibility is given to such vulnerabilities. However, if the web application has a downloadable component, a boot sector virus infection is feasible. The following description and diagram show how a virus copies a boot sector on the CPU and replaces a boot block with itself, the virus is soon replicated, this is known as a logic block bomb and can proliferate quickly before any system detection software can act. This system boot virus decreases physical memory and attaches itself to a disk read-write interrupt. [15]
The paper explored one aspect of web applications, as mentioned if more time was placed on security upfront there might be fewer exploits. However, security architecture comes with a price of higher cost more consumption of resources, and potentially slower processing speed. There is an inverse relationship between security and fast processing time.
As web applications continue to more prevalent with increased functionality, the security architecture of the application must be considered before investing resources into the application that might be insecure. The paper explored what happens to the system when a scripting language with known vulnerabilities uses external entities and translation tools for data conversion. As web applications get more sophisticated a strategy-based approach is needed to keep the integrity, confidentiality, and availability of applications intact. Continued research on this topic should be considered as systems advance and computers even handheld ones are used for daily transactions.
9. Future Work
Detection systems can discover known vulnerabilities but have a shortfall in zero-day attacks. Factors in place of having a detection system alert for an attack would be to have monitoring tools on the hardware to alert if a system’s behavior is inappropriate. Although detection systems are available today, it was mentioned in our research that they produce a lot of false positives leading to unnecessary investigations. Advanced monitoring tools from the server side in a complex network and the client side would allow system administrators time to react before the system is breached. A spike in core speed, temperature, or GPU usage might alert the operating system to quarantine processes and inform the user of unexpected processing behavior would be a research project worth exploring. Exploring intruder detection systems on Operation systems would be a consideration for future work. Additionally, an analysis of cost, processing speed, and security architecture should be considered when looking at the intruder detection strategy. There could be a factor of AI that would help grow the knowledge-based techniques that learn user behaviors.
Author Contribution
This research paper was a collaborative effort of both authors, after agreeing on a topic to explore the work was divided to optimize the background of each team member. Xueying focused on the actual injection attack using web-based tools and researched how the code could be injected maliciously. Sharon focused on how to detect and mitigate the injection and also researched what injections would do to the overall system and related components. The future works and the detection of malicious code was included in the research.