[seam-issues] [JBoss JIRA] Commented: (SEAMFACES-26) Implement global protection against XSRF attacks via incremental token-based form fields

[Lincoln Baxter III (JIRA)]

    [ https://jira.jboss.org/browse/SEAMFACES-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12534771#action_12534771 ] 

Lincoln Baxter III commented on SEAMFACES-26:
---------------------------------------------

Details of the initial implementation:
http://seamframework.org/Documentation/CrossSiteRequestForgery

Calling for a global solution:
http://seamframework.org/Community/NewComponentTagStokenAimedToGuardAgainstCSRF

> Implement global protection against XSRF attacks via incremental token-based form fields
> ----------------------------------------------------------------------------------------
>
>                 Key: SEAMFACES-26
>                 URL: https://jira.jboss.org/browse/SEAMFACES-26
>             Project: Seam Faces
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Lincoln Baxter III
>             Fix For: 3.0.0.Alpha4
>
>
> I'd like to see a way to implement this for ALL pages, not requiring a custom tag.
> I believe this could be done easily using the PreRenderViewEvent to add a hidden form field to store the token in all outbound forms, in combination with a cookie that is sent to the browser, storing a unique private key for that browser session. 
> Next, use a phase-listener after Restore_View, comparing the request parameter to the restored component value or session. Very similar to the <s:token> component, but as a global solution that could be enabled/disabled via XML config.
> The token value increments on each subsequent form submission, and includes a hashed version of the browser's signature (and corresponding public key for the browser's cookie-assigned private key.) The token is compared to either a value stored in ViewState (insecure if using client-side state-saving) or a value stored in the user's session as (an ordered list that can detect repeat or invalid requests.)
> Question: how does this affect the back-button?
> Note: In order for any cookie-based public key to be assigned to the browser, one MUST assume that the server/client are speaking HTTPS, otherwise any communication of public/private keys will be vulnerable to man-in-the-middle attacks.
> "1. When rendered, it assigns a unique identifier to the browser using a cookie that lives until the end of the browser session. This is roughly the browser's private key. The <s:token> tag is used inside of an <h:form> and generates a hidden form field named javax.faces.FormSignature. The form signature is calculated as follows: "

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira