yasserzamani commented on pull request #483:
URL: https://github.com/apache/struts/pull/483#issuecomment-831193561
Hi @JCgH4164838Gh792C124B5 thanks! :)
Actually it's not a feature requested, it's a security mitigation. Its main
purpose is to mitigate when developer is using %{} or ${} against end user not
validated input by mistake. It prevents it only in suspicious cases because
reevaluation is naturally needed in Struts and cannot be opt-out.
Moving on your second paragraph, I personally think it's not a new thing.
It's a "complement" for current already exist accept/exclude policy. I think
it's same and current policy had merely missed this piece. My reasoning:
Consider `<s:text name="foo[%{index}].name"/>`. It's just same as `<s:text
name="foo[0].name"/><s:text name="foo[1].name"/><s:text
name="foo[2].name"/><s:text name="foo[3].name"/>...`. My inference: To validate
that if it's ok to double evaluate `foo[%{index}].name` we just need to
validate if the result of the first evaluation is already considered as a valid
input! Do you know what I mean? I feel they aren't different, the second
evaluation is same as the first evaluation regarding validation. e.g. if in
some places we had third evaluation, then we could say the result of the second
evaluation also must be an already considered as valid before going to third
validation and so on.
So I think it's not a new concept, it merely was a missing piece in previous
impl. The only issue here is the memory. Frankly what I've never understood yet
in Struts is if e.g. OGNL exclusions or Interceptor exclusions are for security
so why developer is allowed to override them?! because otherwise I could change
current impl to singleton and solve the mem issue:)
--
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.
For queries about this service, please contact Infrastructure at:
[email protected]
