[jira] [Commented] (MYFACES-4164) Unexpected behavior when javax.faces.ViewState is set to "stateless" in a State view
[ https://issues.apache.org/jira/browse/MYFACES-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16220730#comment-16220730 ] Eduardo Breijo commented on MYFACES-4164: - I have uploaded a new patch that throws a FacesException. If no objections I will commit this patch. > Unexpected behavior when javax.faces.ViewState is set to "stateless" in a > State view > > > Key: MYFACES-4164 > URL: https://issues.apache.org/jira/browse/MYFACES-4164 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.12, 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo > Attachments: MYFACES-4164.patch, ProtectedViewStateless.war > > > 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. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4164) Unexpected behavior when javax.faces.ViewState is set to "stateless" in a State view
[ https://issues.apache.org/jira/browse/MYFACES-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16220533#comment-16220533 ] Thomas Andraschko commented on MYFACES-4164: +1 for throwing a exception. it's not a default case, so therefor its ok > Unexpected behavior when javax.faces.ViewState is set to "stateless" in a > State view > > > Key: MYFACES-4164 > URL: https://issues.apache.org/jira/browse/MYFACES-4164 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.12, 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo > Attachments: MYFACES-4164.patch, ProtectedViewStateless.war > > > 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. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4164) Unexpected behavior when javax.faces.ViewState is set to "stateless" in a State view
[ https://issues.apache.org/jira/browse/MYFACES-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16220516#comment-16220516 ] Eduardo Breijo commented on MYFACES-4164: - Maybe, instead of just setting the view = null, I can just throw new FacesException ("unable to create view \"" + viewId + "\"", e); > Unexpected behavior when javax.faces.ViewState is set to "stateless" in a > State view > > > Key: MYFACES-4164 > URL: https://issues.apache.org/jira/browse/MYFACES-4164 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.12, 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo > Attachments: MYFACES-4164.patch, ProtectedViewStateless.war > > > 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. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4164) Unexpected behavior when javax.faces.ViewState is set to "stateless" in a State view
[ https://issues.apache.org/jira/browse/MYFACES-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216995#comment-16216995 ] Eduardo Breijo commented on MYFACES-4164: - I believe the case where the view.isTransient() && viewStateFromResponse != stateless is already covered. From the sample app I provided, there is a page that is transient=true, and if I change the javax.faces.ViewState to something different from "stateless", we get a VEE which is fine. > Unexpected behavior when javax.faces.ViewState is set to "stateless" in a > State view > > > Key: MYFACES-4164 > URL: https://issues.apache.org/jira/browse/MYFACES-4164 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.12, 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo > Attachments: MYFACES-4164.patch, ProtectedViewStateless.war > > > 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. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4164) Unexpected behavior when javax.faces.ViewState is set to "stateless" in a State view
[ https://issues.apache.org/jira/browse/MYFACES-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216598#comment-16216598 ] Thomas Andraschko commented on MYFACES-4164: I think it would do something like this: if (view.isTransient() && viewStateFromResponse != stateless) {throw new ...Exception()); and if (!view.isTransient() && viewStateFromResponse == stateless) {throw new ...Exception()); > Unexpected behavior when javax.faces.ViewState is set to "stateless" in a > State view > > > Key: MYFACES-4164 > URL: https://issues.apache.org/jira/browse/MYFACES-4164 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.12, 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo > Attachments: MYFACES-4164.patch, ProtectedViewStateless.war > > > 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. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4164) Unexpected behavior when javax.faces.ViewState is set to "stateless" in a State view
[ https://issues.apache.org/jira/browse/MYFACES-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213014#comment-16213014 ] Paul Nicolucci commented on MYFACES-4164: - How severe of an issue is this from a app security standpoint? > Unexpected behavior when javax.faces.ViewState is set to "stateless" in a > State view > > > Key: MYFACES-4164 > URL: https://issues.apache.org/jira/browse/MYFACES-4164 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.12, 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo > Attachments: MYFACES-4164.patch, ProtectedViewStateless.war > > > 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. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4164) Unexpected behavior when javax.faces.ViewState is set to "stateless" in a State view
[ https://issues.apache.org/jira/browse/MYFACES-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16211471#comment-16211471 ] Eduardo Breijo commented on MYFACES-4164: - I have uploaded a solution for this issue. [~lu4242] Can you verify the patch and provide any feedback? > Unexpected behavior when javax.faces.ViewState is set to "stateless" in a > State view > > > Key: MYFACES-4164 > URL: https://issues.apache.org/jira/browse/MYFACES-4164 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.12, 2.3.0-beta >Reporter: Eduardo Breijo > Attachments: MYFACES-4164.patch, ProtectedViewStateless.war > > > 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. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4164) Unexpected behavior when javax.faces.ViewState is set to "stateless" in a State view
[ https://issues.apache.org/jira/browse/MYFACES-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209837#comment-16209837 ] Leonardo Uribe commented on MYFACES-4164: - Strange, I remember there was a check in some place for that condition (stateful view with stateless view state). > Unexpected behavior when javax.faces.ViewState is set to "stateless" in a > State view > > > Key: MYFACES-4164 > URL: https://issues.apache.org/jira/browse/MYFACES-4164 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.12, 2.3.0-beta >Reporter: Eduardo Breijo > Attachments: ProtectedViewStateless.war > > > 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. -- This message was sent by Atlassian JIRA (v6.4.14#64029)