[ https://issues.apache.org/jira/browse/WW-5184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17610451#comment-17610451 ]
ASF subversion and git services commented on WW-5184: ----------------------------------------------------- Commit ddbd02e6bb4c00b647e1a8f89610d5ff3165aeb6 in struts's branch refs/heads/WW-5184-log from Lukasz Lenart [ https://gitbox.apache.org/repos/asf?p=struts.git;h=ddbd02e6b ] WW-5184 Uses debug log level when parameter value was not accepted > Add optional parameter value check to ParametersInterceptor > ----------------------------------------------------------- > > Key: WW-5184 > URL: https://issues.apache.org/jira/browse/WW-5184 > Project: Struts 2 > Issue Type: Improvement > Affects Versions: 6.0.0 > Reporter: Brian Andle > Priority: Major > Fix For: 6.1.0 > > Time Spent: 4h 50m > Remaining Estimate: 0h > > It is known that developers utilizing Struts/Freemarker should always ensure > proper sanitization to prevent OGNL/Freemarker evaluation on untrusted user > input when %{/$\{ in FTL being passed into Struts tags. > These patterns aren't always practical to resolve/find especially in legacy > code. This isn't a solely a legacy code issue of course, it's just as easy to > make a mistake in newer code as well. > The following would end up rendering 81 > Payload: > {code:java} > untrustedInput=%25%7B9%2A9%7D {code} > FTL: > > {code:java} > <@s.form theme="simple" action="${untrustedInput}" id="myForm4"> > </@s.form> {code} > > Java: > {code:java} > private String untrustedInput; > public String getUntrustedInput() { > return untrustedInput; > } > public void setUntrustedInput(String untrustedInput) { > this.untrustedInput = untrustedInput; > } {code} > > This ticket is to add an optional `params.excludeValuePatterns` so that > ParametersInterceptor can drop incoming parameter itself if the value matches > a pattern to be excluded. > > {code:java} > <param > name="params.excludeValuePatterns">.*\$\{.*?\}.*,.*%\{.*?\}.*</param>{code} > > Since this is a pattern and would be executed against the values themselves > there is the potential of a performance impact however I since it's optional > we shouldn't see any measurable impact when not enabled. > > *NOTE:* I did add a `params.acceptValuePatterns` pattern that is > null/disabled by default. This might not ever be used but mimic'd the Pattern > matcher the ParametersInterceptor/CookieInterceptor. > -- This message was sent by Atlassian Jira (v8.20.10#820010)