Re: [jsr-314-open-mirror] [jsr-314-open] [Spec-869-Specify CSRF Solution] PROPOSAL(s)

Comments inline.. On 9/28/10 2:56 PM, Alexander Smirnov wrote: > The #2 approach is already here, it's JSF view state field. It would be > make even stronger by some random string added to its value, but that > doesn't require any change in spec; the format of state field is up to > implementation. > Yep - I agree that we could possibly augment the view state with some generated random value. The #1 is also available as custom view parameter, but we can make it > more convinient as implicit view parameter and metadata control > included in all ( or selected ) navigation links and views. It would > leverage already existing JSF 2.0 features. As well as view parameters > processed in the separate ExternalContext method, they are portlet-safe. > Hmm... They are probably many ways to slice and dice this problem. I think we were looking for a more automatic solution then having to introduce more burden on page authors or application developers. > > On 09/21/2010 10:15 AM, Roger Kitain wrote: > >> There are two proposals for enhancing CSRF attacks in JSF. We need to >> pick one. >> >> Proposal 1: Form Action URL Approach (Approach provided by Kito Mann) >> >> This approach does the following: - Token is generated on the >> server consisting (minimally) of a randomly generated "secret key >> (stored in session). >> - ViewHandler.getActionURL method must include the token parameter >> named "javax.faces.Token", and whose value is the token value. >> - At render time this token will be included in Form's action URL - >> and it will be >> posted back to the server. >> - Restore View Phase processing compares the incoming token request >> parameter value >> with the token value generated from the secret key in the session. >> >> Spec Document Modifications: >> >> Section 7.5.1: >> >> getActionURL: >> >> "The URL must contain the parameter constant defined by >> ResponseStateManager.VIEW_TOKEN_PARAM >> The value of this parameter must be a cryptographically produced value >> minimally consisting >> of a "secret key". The "secret key" is a random generated value that was >> stored in the session >> (preferably around session creation time). Implementations may also >> choose to combine other >> values with the secret key to produce a more complex token." >> >> Section 2.2.1 >> >> "Verify the "javax.faces.Token" request parameter value is the same as >> the token value generated >> from the "secret key" stored in the session. If the values do not >> match, throw a meaningful >> exception." >> >> >> Proposal 2: Form Hidden Field Approach >> >> This approach is similar to Approach 1, except a Form hidden field >> "javax.faces.Token" >> is used instead of appending to the Form's Action URL. >> >> Spec Document Modifications: >> >> Standard RenderKit Docs >> >> - Form Rendering >> >> "Render a hidden field named "javax.faces.Token" using the >> ResponseStateManager.VIEW_TOKEN_PARAM >> constant. The value of this hidden field is a cryptographically >> produced value that must at least >> consist of a "secret key". The "secret key" is a random generated >> value that was stored in the >> session (preferably around session creation time). Implementations may >> also choose to combine >> other values with the secret key to produce a more complex token." >> >> Specification Document >> >> Section 2.2.1 >> "Verify the "javax.faces.Token" request parameter value is the same as >> the token value generated >> from the "secret key" stored in the session. If the values do not >> match, throw a FacesException. >> >> >> For both approaches see: >> >> >> [1] >> >> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=869 >> >> Look at the two latest change bundles attached to the issue. >> >> Please review by COB Friday as we have no time left for 2.1. >> >> Kudos to Kito Mann for helping out with the implementation. >> >> -roger >> > -- roger.kitain(a)oracle.com https://twitter.com/rogerk09 http://www.java.net/blogs/rogerk