XPath (XML Path Language) is a specialized query language used for node selection and operations in XML type documents. Just as SQL language allows processing in specific databases, it enables querying in XML documents similar to XPath but with limited possibilities.
If an application uses the XPath query in an XML document without filtering the user’s input, XPath Injection vulnerability will occur similar to SQL Injection.
By deliberately sending malformed information to the application, the attacker can determine how XML data is structured or access data that would otherwise not be accessible. If the XML file is used for authentication on a website, it can elevate its privileges.
See Also: What is SQL Injection and How to Prevent It?
XPath is a standard language; the representation/syntax is always implementation-independent, meaning that the attacker can manipulate the Xpath syntax data, regardless of the language used in the application.
Since the level access control is not in Xpath queries, it is possible to access the entire document. As we know from SQL attacks, no limitations are encountered.
PCI DSS Requirement 6.5.1 requires that your organization’s applications are not affected by injection flaws, especially SQL injection. Malicious people commonly use injection defects to compromise applications.
What is XPath Injection Vulnerability?
XPath is a language that allows us to make simple queries on XML documents. Many areas are used due to their structure—for example, XQuery and XSLT. We can say that exactly what it does is to search and find locations within the XML document.
In web applications, data can be stored on the database server in various ways. The data storage format on the server can be in formats such as RDMBS (Relational Database Management System), LDAP (Lightweight Directory Access Protocol), or XML (Extensible Markup Language).
The application creates queries from the data the user enters in the data entry fields and sends it to the server. As a result of the query running on the server, the returned data is presented to the user.
In XPath injection attacks, the attacker must command the Xpath query language, XML database, and the programming language in which the application was written.
In storing data in XML structure, there are no different access levels for access to nodes and different users. If the appropriate precautions are not taken, an XPath query may access an entire XML document. This means that if there is an XPath vulnerability in the application, the attacker can take over the entire XML database.
Both the software developer and the system administrator should know the conditions, techniques, and consequences of the attack that cause this attack method and take the necessary measures for the system’s security.
The following scenario can be considered as an example for Xpath injection:
Let’s set a username and password for Bob below and take action accordingly.
User Name = admin - Password = admin1
The query/user [username = “admin” and password = “admin1”] is created by the application and sent to the server. At the end of this query, (true and true) = TRUE will return to us, and Bob will be logged into the system.
With the Xpath injection attack, our user can bypass this authorization phase. If there is an Xpath injection vulnerability in the system, the attacker will write to the login forms,
If the username but not the password is identified by the attacker:
User Name = Bob "or" 1 "=" 1
Password = Anypassword
The query to be sent to the server with values will be in the form of = / user [username = “Bob” or “1” = “1” and password = “Pass1”] and its logical operation will be as follows:
It will be True or (True and False) -> True or False = TRUE, and we will be logged in with Bob privileges.
In the XPath query, the comment line is written between “<>” tags. As in SQL Injection, the value False, which is written after the characters “-“, for example, cannot be converted into a comment line and eliminated due to an unknown password.
Instead, using a “True” expression such as “1 = 1”, the “and” operation is processed before the “or” operation, and the False password value is eliminated. In this way, we log into the system.
If our attacker does not know the username, he can log in as follows.
User Name = anyusername or "1" = "1" or "1" = "1
Password = Anypassword
When the above values are entered / * [1] / user [username = “anyusername” or “1” or “1” = “1 and password =” Pass1 “], the logical operation in this query is False or True or (False and True). True or False = TRUE and this operation will run the first node in the XML file and the first user will be logged into the system.
What Are The Ways To Avoid Xpath Attack?
In the application developer code section, restrictions should be imposed by filtering the entries so that the characters entered in the fields where the user allows data entry does not constitute an Xpath query.
By filtering out characters that are likely to enter instead of characters that the user should not have to enter, some precaution is taken against future zero-day attacks.
Xpath function names should also be strictly blocked as input. Limitations should be made on the client-side with the software, and on the server-side, they should be controlled by firewall rules, and measures should be taken.
Parameterized queries should be used. Instead of using user inputs directly at run time in a parameterized query, they are used by compiling beforehand. This prevents code execution at runtime.
- User input such as quote (‘) must be sterilized, “& apos;” can be replaced with. Validation must be added on both client and server-side.
- You can use parameterized queries (such as Prepared Expressions in SQL) where queries are precompiled, and user input is passed as parameters instead of statements.
- Appropriate error pages should be used that do not disclose any information in the event of an error that may benefit the attacker.
When developing software, your team should make sure they are not affected by XPATH injection. Be sure to write test scripts for XPATH injection as part of your secure code development process.
To verify compliance with PCI DSS Requirement 6.5.1 and protection from injection errors, an assessor will review your policies and procedures regarding application development and interview responsible personnel.
There are many useful articles on Owasp’s website, such as weaknesses in web applications, how vulnerabilities occur, how to exploit and prevent these vulnerabilities. You can get more detailed information about XPATH Injection from the links below.
