javaserverfaces-spec-public
  1. javaserverfaces-spec-public
  2. JAVASERVERFACES_SPEC_PUBLIC-559

Support for the "Synchronizer Token" pattern (avoiding double submits)

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Component/s: Lifecycle
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      559
    • Status Whiteboard:
      Hide

      cat2 frame size_medium importance_large cat3 draft

      Show
      cat2 frame size_medium importance_large cat3 draft

      Description

      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.

        Activity

        Hide
        Ed Burns added a comment -

        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.

        Show
        Ed Burns added a comment - 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.
        Hide
        Ed Burns added a comment -

        Prepare to delete "spec" subcomponent.

        Show
        Ed Burns added a comment - Prepare to delete "spec" subcomponent.
        Hide
        Ed Burns added a comment -

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

        Show
        Ed Burns added a comment - Move these to unscheduled because we need to target them correctly. 2.next isn't specific enough.
        Hide
        rogerk added a comment -

        cat2

        Show
        rogerk added a comment - cat2
        Hide
        Ed Burns added a comment -

        lifecycle

        Show
        Ed Burns added a comment - lifecycle
        Hide
        Ed Burns added a comment -

        Transaction token has been requested many times over the years.

        Show
        Ed Burns added a comment - Transaction token has been requested many times over the years.
        Hide
        kito75 added a comment -

        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.

        Show
        kito75 added a comment - 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.
        Hide
        Ed Burns added a comment -

        These are targeted at 2.1.

        Show
        Ed Burns added a comment - These are targeted at 2.1.
        Hide
        sheetalv added a comment -

        triage

        Show
        sheetalv added a comment - triage
        Hide
        Ed Burns added a comment -

        GlassFish 3.1 M6 at the latest.

        Show
        Ed Burns added a comment - GlassFish 3.1 M6 at the latest.
        Hide
        Ed Burns added a comment -

        xsrf

        Security related, target for GlassFish 3.1 M3

        Show
        Ed Burns added a comment - xsrf Security related, target for GlassFish 3.1 M3
        Hide
        Ed Burns added a comment -

        cat3

        Show
        Ed Burns added a comment - cat3
        Hide
        rogerk added a comment -

        Hey Kito -

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

        -roger

        Show
        rogerk added a comment - Hey Kito - It's time. Let's see what you have. If you can also submit a proposal that would be helpful as well. -roger
        Hide
        rogerk added a comment -

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

        Show
        rogerk added a comment - This could probably reside in the core namespace - like f:token ?
        Hide
        Ed Burns added a comment -

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

        Show
        Ed Burns added a comment - Roger, please take a look at https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=812 for more valuable information.
        Hide
        rogerk added a comment -

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

        Show
        rogerk added a comment - Ahh yes - thanks for the pointer. Apparently there are many ways to skin this cat ....
        Hide
        kito75 added a comment -

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

        Show
        kito75 added a comment - Created an attachment (id=255) Sample CSRF Solution (JSF 1.2)
        Hide
        kito75 added a comment -

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

        Show
        kito75 added a comment - Created an attachment (id=256) Sample CSRF Solution (JSF 1.2) – the other file is for avoiding double submits
        Hide
        kito75 added a comment -

        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.

        Show
        kito75 added a comment - 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.
        Hide
        kito75 added a comment -

        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.

        Show
        kito75 added a comment - 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: UIToken http://grepcode.com/file/repository.jboss.com/maven2/org.jboss.seam/jboss-seam- ui/2.2.0.GA/org/jboss/seam/ui/component/UIToken.java TokenRendererBase http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss.seam/jb oss-seam-ui/2.2.0.CR1/org/jboss/seam/ui/renderkit/TokenRendererBase.java#TokenRendererBase 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.
        Hide
        rogerk added a comment -

        re-target

        Show
        rogerk added a comment - re-target
        Hide
        rogerk added a comment -

        I've created a separate spec issue for CSRF:
        https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=869
        as it solves a different problem.

        Show
        rogerk added a comment - I've created a separate spec issue for CSRF: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=869 as it solves a different problem.
        Hide
        rogerk added a comment -

        target

        Show
        rogerk added a comment - target
        Hide
        rogerk added a comment -

        Starting

        Show
        rogerk added a comment - Starting
        Hide
        rogerk added a comment -

        reset priority

        Show
        rogerk added a comment - reset priority
        Hide
        rogerk added a comment -

        target 2.2

        Show
        rogerk added a comment - target 2.2
        Hide
        joshbrookes added a comment -

        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?

        Show
        joshbrookes added a comment - 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?
        Hide
        Ed Burns added a comment -

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

        Show
        Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.
        Hide
        Manfred Riem added a comment -

        Setting priority to Critical

        Show
        Manfred Riem added a comment - Setting priority to Critical
        Hide
        codylerum added a comment -

        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.

        Show
        codylerum added a comment - 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.

          People

          • Assignee:
            Unassigned
            Reporter:
            kito75
          • Votes:
            13 Vote for this issue
            Watchers:
            11 Start watching this issue

            Dates

            • Created:
              Updated: