[ https://issues.apache.org/jira/browse/MYFACES-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16135942#comment-16135942 ]
Thomas Andraschko commented on MYFACES-4133: -------------------------------------------- [~lu4242] I had a look at it but not sure. IMO the code in DefaultStateTokenProcessor should be moved to ServerSideStateCacheImpl/ServerSideStateCacheImpl. The impl can easily decide if StateUtils#construce or reconstruct needs to be called. The DefaultStateTokenProcessor is IMO a little bit to much of abstraction and could be better moved into *StateCacheImpl. Would be great if you could take care of this issue. You know this part very good. > Don't deserialize the ViewState-ID if the state saving method is server > ----------------------------------------------------------------------- > > Key: MYFACES-4133 > URL: https://issues.apache.org/jira/browse/MYFACES-4133 > Project: MyFaces Core > Issue Type: Bug > Components: General > Affects Versions: 2.2.12 > Reporter: Peter Stöckli > > Currently the ViewState-ID provided by the user is deserialized via Java > deserialization even when the {{javax.faces.STATE_SAVING_METHOD}} is set to > {{server}} (the default). > The deserialization in this case is unecessary and most likely even slower > than just sending the ViewState Id directly. > If a developer now disables the ViewState encryption by setting > {{org.apache.myfaces.USE_ENCRYPTION}} to {{false}} (against the [MyFaces > security advice|https://wiki.apache.org/myfaces/Secure_Your_Application]) he > might have unintentionally introduced a dangerous remote code execution (RCE) > vulnerability as described > [here|https://www.alphabot.com/security/blog/2017/java/Misconfigured-JSF-ViewStates-can-lead-to-severe-RCE-vulnerabilities.html]. > This has been discussed before on [Issue > MYFACES-4021|https://issues.apache.org/jira/browse/MYFACES-4021]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)