myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Andraschko (JIRA)" <>
Subject [jira] [Commented] (MYFACES-4133) Don't deserialize the ViewState-ID if the state saving method is server
Date Mon, 21 Aug 2017 22:26:01 GMT


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:
>             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|])
he might have unintentionally introduced a dangerous remote code execution (RCE) vulnerability
as described [here|].
> This has been discussed before on [Issue MYFACES-4021|].

This message was sent by Atlassian JIRA

View raw message