fix(rest-plugin): WW-5624 enforce @StrutsParameter in JacksonJsonHandler.toObject()

[tranquac]

Summary

JacksonJsonHandler.toObject() in the struts2-rest-plugin uses ObjectMapper.readerForUpdating(target).readValue(reader) to merge JSON request body directly into the action object. Jackson sets any field with a matching setter, completely bypassing the @StrutsParameter annotation check that ParametersInterceptor enforces for URL parameters. This enables mass assignment of unannotated properties via REST JSON request body.

Changes

• JacksonJsonHandler.java: When struts.parameters.requireAnnotations is enabled, deserialize JSON into a map first, then filter properties against the @StrutsParameter annotation on the target class's setter methods before setting them. When disabled, preserve the original readerForUpdating() merge for backwards compatibility.

Impact

Without this fix:

• URL params to unannotated setters: BLOCKED (ParametersInterceptor enforces)
• REST JSON body to same unannotated setters: BYPASSES (Jackson merge ignores annotation)

With this fix, both pathways consistently enforce @StrutsParameter.

Test

A PoC application with 9 test cases demonstrates the bypass using an OrderAction with annotated (setItemName, setQuantity) and unannotated (setUnitPrice, setDiscount, setApproved, setInternalNote) setters. JSON body sets unitPrice from 99.99 to 0.01 and approved to true before the fix.

[lukaszlenart]

Thanks for reporting this. The issue in the REST plugin looks valid: JacksonJsonHandler.toObject() currently bypasses the ParametersInterceptor checks for @StrutsParameter.

That said, I don't think this fix is sufficient as-is. In Struts, @StrutsParameter support is not only a check for an annotated setter. The core ParametersInterceptor logic also enforces nesting depth and related authorization semantics. This change currently adds only a setter-level annotation check, so it does not fully match existing Struts behavior.

My main concern is that once an annotated top-level setter is accepted, mapper.convertValue(...) can still populate the full nested subtree of a complex object without enforcing Struts depth rules. So this still looks too permissive for nested binding cases. It also changes the current Jackson update path, which may affect existing merge/deserialization behavior beyond the security fix itself.

I think the right direction is to align the REST plugin with the shared parameter-binding authorization rules used by ParametersInterceptor, instead of implementing a local setter-only check.

[tranquac]

Thanks for your feedback. I will quickly create a fullfill patch based on your comment. I will notify you when it's finished and create a new PR.