schlm3 commented on PR #26: URL: https://github.com/apache/commons-jxpath/pull/26#issuecomment-1473547243
Like most of the JXPath users community, I also think that this is a security issue because of JXPath's default configuration. However, it seems that the mitigation approach taken by @kyakdan will not make it into the official code. The question for me now is, how all the usages of JXPath out there could be secured without having the project responsibles to change code in the project. But for all those concerned about having that security issue in their apps, there is (as far as I could find out) a secure way to get rid of the problem. You need to set the default "Functions" implementation to YOUR default instead of silently using the default from JXPathContext (which is JXPathContext.GENERIC_FUNCTIONS ). All you have to do is adding the following line for each instance of JXPathContext in your Application: `context.setFunctions(new org.apache.commons.jxpath.FunctionLibrary());` Of course, you will loose any way of using direct Java Class functions. But the approach also offers the possibility to add your own, secured implementation of the JXPath's PackageFunction, which could be one with a "whitelist" approach like proposed in this thread. Many usages of JXPath however won't even require the Package Functions if they only need to traverse graphs of objects. You could even provide your own JXPathContextFactory to your Application VM such that any Usage of JXPathContext.newContext() will return a secured context by default. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
