Description
I have encountered an issue or an unexpected behavior with a stateless value of “javax.faces.ViewState” hidden input.
Let’s say you navigate to a state view. When the value attribute of “javax.faces.ViewState” is changed manually using browser’s developer tools, the application can prevent CSRF attack by throwing a ViewExpiredException. However, if you modify the value to be “stateless”, then no ViewExpiredException is thrown.
Even if you add View Protection to the state view, and modify the value to be “stateless”, no exception is thrown.
The following JIRA issue said that this should be prevented with View Protections but it seems that’s not working.
https://issues.apache.org/jira/browse/MYFACES-3714
Comparing this behavior with Mojarra, if the you modify the value to be “stateless”, then the following exception is thrown:
javax.faces.FacesException: Unable to restore view /stateView.xhtml
com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:255)
com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:157)
javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:125)
com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:204)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
I have provided a sample app that demonstrates this behavior.
Instructions to recreate the behavior on Tomcat:
1) Deploy the app on tomcat
2) Drive a request to http://localhost:8080/ProtectedViewStateless/index.xhtml
3) Click the “Navigate to State View” link
4) Open the Browser’s Developer Tools and modify the value of “javax.faces.ViewState” to “stateless”
5) Click the “Go to Final View” button. No exception is thrown.
If you change the MyFaces bundle to a Mojarra bundle and repeat the same steps, you’ll get the exception I mentioned above.