[JAVASERVERFACES_SPEC_PUBLIC-559] Support for the "Synchronizer Token" pattern (avoiding double submits) Created: 05/May/09  Updated: 11/Sep/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: kito75 Assignee: kito75
Resolution: Unresolved Votes: 13
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Attachments: File jsf2csrf.war     File jsf2token.war    
Issuezilla Id: 559
Status Whiteboard:

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.

Comment by Ed Burns [ 11/Aug/09 ]

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
DA> saving.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 05/Mar/10 ]


Comment by Ed Burns [ 17/Mar/10 ]


Comment by Ed Burns [ 07/May/10 ]

Transaction token has been requested many times over the years.

Comment by kito75 [ 08/May/10 ]

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.

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 ]


Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]


Security related, target for GlassFish 3.1 M3

Comment by Ed Burns [ 30/Jun/10 ]


Comment by rogerk [ 01/Jul/10 ]

Hey Kito -

It's time. Let's see what you have. If you can also submit a proposal that
would be helpful as well.


Comment by rogerk [ 01/Jul/10 ]

This could probably reside in the core namespace - like f:token ?

Comment by Ed Burns [ 01/Jul/10 ]

Roger, please take a look at https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=812 for more
valuable information.

Comment by rogerk [ 01/Jul/10 ]

Ahh yes - thanks for the pointer. Apparently there are many ways to skin this
cat ....

Comment by kito75 [ 14/Jul/10 ]

Created an attachment (id=255)
Sample CSRF Solution (JSF 1.2)

Comment by kito75 [ 14/Jul/10 ]

Created an attachment (id=256)
Sample CSRF Solution (JSF 1.2) – the other file is for avoiding double submits

Comment by kito75 [ 14/Jul/10 ]

I have attached two samples:

  • jsf2token.war – sample UIToken component specifically for avoiding double submits (but would
    probably handle CSRF attacks too)
  • jsf2csrf.war – sample solution for handing Cross-site Request Forgery (CSRF) attacks only.

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.

Comment by kito75 [ 14/Jul/10 ]

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.

Comment by rogerk [ 22/Jul/10 ]


Comment by rogerk [ 23/Jul/10 ]

I've created a separate spec issue for CSRF:
as it solves a different problem.

Comment by rogerk [ 13/Aug/10 ]


Comment by rogerk [ 13/Aug/10 ]


Comment by rogerk [ 27/Aug/10 ]

reset priority

Comment by rogerk [ 13/Sep/10 ]

target 2.2

Comment by joshbrookes [ 18/May/11 ]

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?

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by codylerum [ 23/Mar/15 ]

While Seam is out of date, https://deltaspike.apache.org/documentation/jsf.html#_double_submit_prevention is a more current solution.

Inclusion into 2.3 would be a huge help to a common problem.

Comment by Manfred Riem [ 06/Aug/15 ]

Kito, can you take charge of this issue and look for an implementation strategy? Thanks!

Comment by kito75 [ 10/Aug/15 ]

Sure, I can.

Comment by gerhard_petracek [ 11/Sep/15 ]

DeltaSpike keeps the valid token in a window-scoped bean -> there is only one known token per window/tab -> there is no impact on the state of the component tree and it isn't possible to "reactivate" a previous key -> ds:preventDoubleSubmit just renders the current key.

Generated at Sat Nov 28 23:32:10 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.