myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leonardo Uribe (JIRA)" <>
Subject [jira] [Commented] (MYFACES-4133) Don't deserialize the ViewState-ID if the state saving method is server
Date Wed, 16 Aug 2017 13:46:00 GMT


Leonardo Uribe commented on MYFACES-4133:

Encryption should NEVER be disabled for view state token, because there is no safe way to
make it work with this disabled, but beyond that, I agree serialize the session id is not
necessary on server side state saving. 

Please note encryption also adds a Message Authentication Code (MAC) that protects the view
state token against tampering and other attacks, but this works together with the encryption.

It's more, maybe it is a good idea to change the default encryption algorithm to AES or something.

> 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