The Web application is vulnerable to XPATH injection

2
Our application is tested for security (pen test) and one the issues is the following: "The Web application is vulnerable to XPATH injection" This vulnerability allows a malicious user to modify an existing xpath query by submitting specially crafted input parameters to the system. In XPATH injection, the attacker creates input parameters that affect the structure of the XPATH query. This is possible where user-induced input is being incorporated into XPATH queries without the proper controls and validation. A successful attack will open a privileged access to the database, and can enable (depending on the privileges of the application in the database) an attacker to extract arbitrary data from the database, bypass authorization and authentication checks, and modify or erase information in the database. We are using Xpath constraints on objects. Their recommendations: 1 Use parameterized queries in order to extract, modify, delete or insert data to the database 2 String concatenation should never be used to create dynamic XPATH queries. 3 Apply validation, escaping and sanitation on any and all input used for database queries. Validation based on white-list (rather than black-list) is recommended. 4 Protect the database by implementing permissions according to the “Least Privilege” principle. Number 4 is done, but we would like to know if the Xpath queries are sanitized. (1,2 and 3) by the Mendix framework? Anybody has expertise on this level? Thanks!
asked
4 answers
7

If you just use the standard Mendix fuctionality, you are safe from XPath injection as far as I know. User input will be escaped when inserted into an XPath query that is generated by the framework, and all instance access will be applied to the query as well. Even if you manage to send a custom XPath retrieve request to the Mendix server, entity access will still be applied and it is not possible to retrieve any data you are not authorized to see (if you have configured entity access properly). The same reasoning goes for updates and deletes.

Of course, if you are generating XPath queries in custom Java in an insecure way (i.e. string concatenation without escaping), this does not apply. In that case, you are responsible for the security yourself.

If (despite the above) you have a demonstrable testcase of an attack where data can be illegally retrieved or modified, you should file a support ticket or contact your partner manager ASAP.

answered
2

Also a good best practice is to keep all entities manipulated (or even read-only) by the "Anonymous" users in-memory (non-persistable), else it could be possible to (XPATH) query those entities via XHR call manipulation.

answered
1

Although the Mendix Business Server to some extent provides a number of layers of security (such as SQL Injection) X-Path injection should be avoided by setting X-Path constraints.

answered
0

It is fine if users are able to alter the xpath queries, that shouldn't cause any harm as long as your domain model security is setup properly to make sure no non accessible results are returned.

answered