This project demonstrates an XPath Injection vulnerability and its mitigation in a Rust web application built with the actix-web framework.
📜 Lesson Concepts XPath (XML Path Language) is a query language for selecting nodes from an XML document. XPath Injection is a security attack that occurs when an application constructs an XPath query using unsanitized user input.
A malicious actor can supply specially crafted input to break out of the intended query structure, allowing them to see data they are not authorized to access or to bypass authentication.
This lesson implements two endpoints:
/vulnerable: Directly uses user input to build an XPath query, making it susceptible to injection.
/secure: Uses parameterized queries to safely handle user input, preventing injection.
🛠️ Setting Up the Demo Application Prerequisites Rust and Cargo installed on your system.
Step-by-Step Instructions Clone the Project or Create the Files: Create the project structure as defined above (Cargo.toml, src/main.rs, users.xml).
Install Dependencies: Navigate to the root directory of the project in your terminal and run:
Bash
cargo build This command will download and compile all the necessary crates (actix-web, serde, etc.).
Run the Application: Start the web server with the following command:
Bash
cargo run You should see output indicating the server is running:
🚀 Server starting at http://127.0.0.1:8080 Vulnerable endpoint: /vulnerable?username= Secure endpoint: /secure?username= 💥 Demonstrating the Vulnerability We will use curl to interact with our endpoints.
- Normal Query (Vulnerable Endpoint) Let's first send a legitimate request to find the role of the user alice.
Bash
curl "http://127.0.0.1:8080/vulnerable?username=alice" The server will correctly respond with alice's role:
JSON
["user"] The server log will show the executed XPath query: [Vulnerable] Executing XPath: //user[username='alice']/role/text()
- XPath Injection Attack Now, we'll inject a malicious payload. The payload is ' or '1'='1. This string is designed to close the username string comparison and add a condition that is always true.
Bash
curl "http://127.0.0.1:8080/vulnerable?username='%20or%20'1'='1" The server log shows how the injection payload has altered the query: [Vulnerable] Executing XPath: //user[username='' or '1'='1']/role/text()
Because '1'='1' is always true, the XPath expression now selects the roles of ALL users in the document, including the administrator.
The vulnerable endpoint returns all roles:
JSON
["administrator","user","user"] This is a serious data leak, as we've accessed the roles of admin and bob without knowing their usernames.
🛡️ Demonstrating the Mitigation Now, let's perform the same queries against the /secure endpoint, which uses parameterized queries.
- Normal Query (Secure Endpoint) A legitimate query works as expected.
Bash
curl "http://127.0.0.1:8080/secure?username=admin" The server responds with the correct role:
JSON
["administrator"] The server log shows that a variable was used:
[Secure] Executing XPath: //user[username=$user]/role/text() [Secure] With variable $user = admin 2. Attempted Injection Attack (Secure Endpoint) Let's send the same malicious payload to the secure endpoint.
Bash
curl "http://127.0.0.1:8080/secure?username='%20or%20'1'='1" This time, the server returns an empty array:
JSON
[] Why? The server log reveals the answer:
[Secure] Executing XPath: //user[username=$user]/role/text() [Secure] With variable $user = ' or '1'='1 The application did not change the query. Instead, it correctly treated the entire payload ' or '1'='1 as a single string to be used as the value for the $user variable. It searched for a user whose name is literally ' or '1'='1. Since no such user exists, the query correctly returned no results. The injection was successfully prevented.s
Example 1 - CWE-643: XPath Injection (Supported)
Expected to be detected.
- Source: Line 25
- Sink: Line 49