bhmohanr-techie commented on PR #25:
URL: https://github.com/apache/commons-jxpath/pull/25#issuecomment-1282152944
> That
@0roman I'm sorry to say that I still don't agree to your statement...
In the PR #26 you are changing the default behavior of jxpath... I would
request you think from a user perspective, as a user if I move to a latest
version of jxpath, the bare minimum thing that I expect is there should be
nothing breaking in existing behavior. Having said that, with changes added in
PR #26, if I do an upgrade, jxpath will not work for me, unless I set the newly
added system property (this applies even if I'm not affected by this
vulnerability).
The next problem is that with your approach of whitelisting individual
components is not feasible for large projects. For example, if your project has
100 classes and you just want to deny access to one class you will need to set
a system property for 99 classes e.g. System.setProperty("jxpath.class.allow",
"com.example1, com.example2, com.example1, ..."); There is no hard restriction
in jxpath to this, we should be capable of supporting jxpath to any kind of
user (may it be a user allowing only a single class, or a user who allows
jxpath to access a bunch of his trusted classes)
"jxpath.class.deny=java.lang.Class" will stop exploitation of
[CVE-2022-41852](https://github.com/advisories/GHSA-wrx5-rp7m-mm49) with xpath
string "java.lang.Thread.sleep(1000000)". This is already added in my unit
test code as well which was copied in your PR #26 as well, I would request you
to check this again.
So, I still think deny list is the best approach...
As I mentioned earlier, a similar vulnerability was fixed by me in one other
opensource component, PR: https://github.com/mock-server/mockserver/pull/1466.
Over there, I had used deny list approach, which was review, approved and
merged in their main release as well. So, this is an accepted approach in other
opensource packages as well.
So, please let JXPath maintainers review the approach and decide the best
suited one. We should take their valuable suggestion/feedback. Thanks.
--
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]
