myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Stöckli (JIRA) <>
Subject [jira] [Commented] (MYFACES-4133) Don't deserialize the ViewState-ID if the state saving method is server
Date Fri, 18 Aug 2017 14:42:00 GMT


Peter Stöckli commented on MYFACES-4133:

I propose following steps:
# Don't serialize/deserialize ViewState-IDs
# If you say the ViewState encryption should never be disabled then don't allow the ViewState
to be disabled! Remove the param {org.apache.myfaces.USE_ENCRYPTION} or better: throw an exception
at start up if that param is set to false with a message like: "You must not disable ViewState
encryption/auth! Assume all systems that had ViewState encryption disabled to be breached!"
# Upgrade the default encryption and HMAC algorithms.

> 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