Operating System: All
cat2 frame size_medium importance_large cat3 draft
This is a very common web application problem
(http://www.javajunkies.org/index.pl?lastnode_id=3361&node_id=3355) – avoiding
double submits. Struts had built-in support for this. JSF-related implementations:
Spring Web Flow, Struts 2, and Grails 1.1
(http://www.grails.org/1.1+Release+Notes) also support this natively.
I'd really like to see this in JSF 2.1 at the very latest.
Move to 2.1. Also make this handle Dan's concern here:
DA> It's crucial that the enablement of this feature be accompanied by a
DA> secure token being exchanged in the case of server-side state
Prepare to delete "spec" subcomponent.
Move these to unscheduled because we need to target them correctly. 2.next isn't
Transaction token has been requested many times over the years.
I've got some code I wrote for a client based on Shale's token that I can clean up and submit as a
prototype. If you're interested, just let me know when it's time.
These are targeted at 2.1.
GlassFish 3.1 M6 at the latest.
Security related, target for GlassFish 3.1 M3
Hey Kito -
It's time. Let's see what you have. If you can also submit a proposal that
would be helpful as well.
This could probably reside in the core namespace - like f:token ?
Roger, please take a look at https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=812 for more
Ahh yes - thanks for the pointer. Apparently there are many ways to skin this
Created an attachment (id=255)
Sample CSRF Solution (JSF 1.2)
Created an attachment (id=256)
Sample CSRF Solution (JSF 1.2) – the other file is for avoiding double submits
I have attached two samples:
The source for both is in the WEB-INF/classes directory.
The token approach uses a standard JSF component that outputs a hidden field in the form. The hidden
field is created based on a server-generated secret key plus other information, such as the current view
id. What's a little different is that a phase listener decodes the component before Apply Request Values.
The goal here was to check the token before any other decoding takes place. Also, the token isn't
released until after Invoke Application to ensure that application processing has occurred.
For JSF 2, I think either enhancing UIForm, providing an alternate UIForm, or using a ClientBehavior
might be a better option than a separate component. Using UIForm would avoid the need to handle
decoding in the PhaseListener.
The CSRF approach is a little different. It still generates a special token based on a server-generated
secret key, but it does so based on the session, not on the view. It then appends the token to every JSF-
generated request through ViewHandler.getActionURL(). It uses a PhaseListener to ensure that every
incoming request has a valid token.
It's possible to combine these approaches, but I like the way the CSRF approach doesn't require anything
on the part of the developer. The caveat is that since it's session-based, it's probably not secure as a
form-based approach. Also, a form-based variant is required to avoid double-submits.
I'm not familiar with back button solutions, so I can't comment on how this code is applicable.
We should also consider the Seam <s:token> approach
(http://seamframework.org/Community/NewComponentTagStokenAimedToGuardAgainstCSRF). This is
component-based approach by Dan Allen with two key artifacts:
This approach also uses a cookie to ensure the requests are coming from the same browser, which is a
nice feature (but it should be optional). It also has explicit support for client-side state saving, which
my solution does not.
I've created a separate spec issue for CSRF:
as it solves a different problem.
This issue has remained untouched since mid-Sept of 2010. Is this still being targeted for development or is there a recommended 3rd-party utility that can be used with Mojarra?