We demonstrated and explained practically XML External Entity Injection using OWASP WebGoat lab.
What is XXE?
XXE, or XML External Entity, is a vulnerability found in XML parsers. It occurs when an XML parser is either weakly configured or has poor access permissions. This misconfiguration allows an attacker to manipulate the parser into accessing and disclosing files or directories on the server.
How it Works (in Theory)
Normally, when you type a search query into an application that uses XML, the XML parser processes your request and returns a response. However, with an XXE vulnerability, an attacker can craft a malicious query. This manipulated query can then cause the parser to return responses that disclose confidential information from the server’s file system.
Demonstration Scenario (WebGoat)
The video used a WebGoat lesson as a practical example. In this scenario, an application was designed to return available flight tickets from Boston (using the airport code BOS). The key detail was that this application used an XML parser (version 1.0) to handle these flight queries, making it a perfect target for an XXE attack.
Exploitation Steps 🕵️♀️
My goal was to manipulate the request to include a malicious entity that could access local files on the server.
Step 1: Listing Directory Contents 📁
First, I prepared a crafted XML query. This query defined an entity (which I named “list” in the example) that attempted to list files in the current working directory of the server. I then replaced the original airport code in the request (which might have been ‘B’ or ‘P’) with "BOSlist". The “BOS” part was the legitimate airport code, and “list” was the name of my malicious entity.
When this modified request was forwarded, the server responded by listing the files and directories in its root directory. This confirmed that the XML parser was indeed vulnerable!
Step 2: Disclosing File Contents (Password File)
Now that the vulnerability was confirmed, I crafted a new query. This time, the entity (which I named “file”) was designed to disclose the contents of the /etc/passwd file, a common target for attackers as it contains user account information. I modified the request to use "BOSfile".
Upon forwarding this request, the server returned the entire content of the password file, showing usernames and their encrypted passwords.
Impact and Solution
Even though the passwords in the demonstration were encrypted, an attacker still gains valuable information about existing users on the system. In real-world scenarios, if passwords are unencrypted, this could lead to direct system access (e.g., via SSH login).
The primary way to fix this vulnerability is to configure the XML parser with appropriate permissions. This prevents it from returning sensitive files or directory listings based on malicious requests, effectively patching the XXE vulnerability.
