[jira] Updated: (CONTINUUM-838) Cross Site Request Forgery protection

["Brett Porter (JIRA)" <ji...@codehaus.org>]

     [ http://jira.codehaus.org/browse/CONTINUUM-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brett Porter updated CONTINUUM-838:
-----------------------------------

    Fix Version/s:     (was: Future)
                   1.x

> Cross Site Request Forgery protection
> -------------------------------------
>
>                 Key: CONTINUUM-838
>                 URL: http://jira.codehaus.org/browse/CONTINUUM-838
>             Project: Continuum
>          Issue Type: Improvement
>          Components: Web interface
>    Affects Versions: 1.0, 1.0.1, 1.0.2, 1.0.3, 1.1-alpha-1
>            Reporter: Christian Gruber
>            Priority: Critical
>             Fix For: 1.x
>
>
> XSRF vulnerabilities are very hard to fix.  More details on them at http://en.wikipedia.org/wiki/Cross-site_request_forgery with a key document found at http://isecpartners.com/documents/XSRF_Paper.pdf which outlines a solution.
> In short, an XSRFProtectionToken is passed in each form in a hidden variable, with the XSRFProtectionToken consisting of (pseudocode): 
> hash(sessionid + actionName + sitewide_secret);
> The hash can be MD5 or SHA-1 or whatever.  The important thing is that even if a user is logged on with a valid sessionId, the attacker cannot know in advance what the token will be without getting it out of an insecure browser (in which case, you have other problems).   Even if the attacker gets access to a token for one action that's less security-risky (like invoking a build), they cannot then replay that token against something more risky (such as creating a new admin user).

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