1

During a pentest we identified some indications of XPath injection, meaning we were able manipulate the HTTP request parameters with single quotes and logic (i.e. appending and 2=2) to derive various server responses.

This software stack consists of two components - client side and service side. The server side component uses access controls and can be configured to present only specific type of data based on authorization. When informed about this XPath vulnerability, software provider informed us that client-side component can never be trusted, so it's not a problem that we can modify XPath queries. Most important that server side component has correct access controls in place. In theory this makes sense to me, however looking at recommendations for XPath injection prevention, it is usually input validation, parametrized queries, and just sanitizing user input in general.

During our exploitation we could not obtain any interesting data since server-side component indeed had proper access controls.

My question - does the above explanation from the provider makes sense and the model is secure? In my view, even though indeed client side is not to be trusted, the user should still not be able to manually inject code into the HTTP parameters like ...aaa?x=123' and 2=2.

user1880405
  • 263
  • 1
  • 4
  • 14
  • Is the XPath injection occurring client-side or server-side? – paj28 Jan 03 '23 at 10:52
  • @paj28 injection is done on client side by modifying HTTP request, but the XPath query itself is constructed on the server side. – user1880405 Jan 03 '23 at 11:26
  • Ok, and what evidence do you have that you are injecting into XPath queries? – paj28 Jan 03 '23 at 12:11
  • @paj28 because when I inject additional commands I get predictable result. For example equals condition (x=x) results in one server response, and non equals (x=y) results in a different one. – user1880405 Jan 03 '23 at 14:49
  • XPath injections are mitigated exactly like SQL injections with the simplification that you use XML escaping in case you cannot do a prepared XPath query. The fact that the client is not to be trusted is THE reason the server must be secure under any input. We cannot tell you if the application is secure, it's even hard to understand where this injection is taking place and what it entails. I would not tolerate an injection unless it client-side and only affects the user trying to exploit it. – Margaret Bloom Jan 03 '23 at 21:11
  • @MargaretBloom indeed, so essentially their protection relies on configuring correct access controls on the server. However, you can still escape and inject code on client side which will be parsed by server. It's the same as if you would protect SQL injection by making sure SQL server has least privilege and has bare minimum authorization. Sure you won't be able to exploit anything at that moment, but to me it still seems insecure to be able to tinker and make your own SQL statements on client side. – user1880405 Jan 04 '23 at 08:54

0 Answers0