One of the most prevalent problems when developing secure applications is the correctness of user input validation. Bugs in string operations are common, which often result in erroneous program behavior and security vulnerabilities that malicious users can exploit. In this article, we dive into the problem of input validation and sanitization, by showing how it serves as a gateway to vulnerabilities such as XPath injection. We will also highlight CVE 2019-0370 before walking you through some effective methods for preventing XPath injections.
The danger of improper input validation
When a program fails to validate user input correctly, an attacker can modify the data flow or control flow to yield unexpected results. This lays the ground for malicious activity such as arbitrary code execution or control of resources. This shows how input validation plays a major role in most vulnerabilities- from simple program misuse to critical security bugs exploited in web applications and distributed systems. According to the Ultimate Security Vulnerabilities database, improper input validation leads the pack when it comes to vulnerability exposure, accounting for over 7669 different security vulnerabilities at the time of writing.
In the simple Java Code snippet below, for instance, you can see how improper output validation leads to erroneous execution in a shopping interaction.
As you can see, the user specifies the number of items purchased and the total cost calculated. However, the program has no control over the price input, so if a user specifies a negative value as the price, then the program would credit the account instead of debiting. This is just a simple illustration of how improper input validation can introduce weaknesses in different phases of application development. The scope and level of impact differ depending on how the weakness is exploited.
Vulnerability severity and metrics:
CVSS Score 6.4
Confidentiality impact: Leads to considerable information disclosure
Integrity impact: Possible modification of information or file systems
Authentication: Not required to exploit the vulnerability
Vulnerability type: Input validation leading to XPath injection
Affected Versions: cpe:2.3:a:sap:financial_consolidation:10.0:*:*:*:*:*:
CVE 2019-0370 is vulnerability uncovered in SAP Financial Consolidation, where lack of proper input validation could enable an attacker to interfere with query structures using specially crafted input, eventually leading to XPath Injection.
CVE 2019-0370 was also closely related to CVE 2019-0370. The latter involved SAP Financial Consolidation versions not sufficiently encoding user-controlled inputs, hence allowing an attacker to upload and execute malicious scripts, which in turn exposes the system to cross-site scripting vulnerabilities.
Mitigating CVE 2019-0370 and other xPath Injection Vulnerabilities
For CVE 2019-0370 and CVE 2019-0369, the German software maker released a patch to fix these two related vulnerabilities. Regardless of the type of bug or vulnerability you’re dealing with, it is important to keep an eye on security updates. This is because a subsequent product or framework releases provide fixes for the bugs.
XPath injection attacks can be mitigated in the same way as typical code injection attacks i.e., by ensuring applications only accept legitimate input. The three most effective prevention methods are:
- Strong input validation – It involves validating all user-controllable input to check for illegal characters that may be executed in the context of XPath expressions. This includes characters such as operators (|) and (&), single quotes (‘), and more. If these cannot be eliminated, then they must be properly filtered to avoid the possibility of interpreting the characters as part of your XPath expression.
Below is a non-compliant code sample that does not validate user input, thereby opening our program to injection attacks.
In the compliant solution for the code sample above, we validate both inputs from the user as follows:
- Parameterization – Using parameterized XPath queries restrict user input to certain domains such as integers or strings. Any input outside the specified domains is considered as invalid. Like in SQL PreparedStatements, queries are precompiled so that input passed as parameters as opposed to expressions.
Using custom error pages – Error pages can disclose the nature of queries, especially if they contain descriptive information. It is, therefore, a good practice to ensure error messages do not disclose information about your application or database.