10:37 p.m.
Hello Neil,
Wouldn't it possible to just avoid adding the token when the application is
inside of a portlet environment?
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter:
jsfcentral
+1 203-404-4848 x3
Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17
On Tue, Sep 21, 2010 at 4:20 PM, Neil Griffin <neil.griffin(a)portletfaces.org
wrote:
#1 is probably not compatible with portlets. Portals are in full
control of
creation of URLs in general, and it is not possible to simply append
"&javax.faces.Token=XYZ" to a portal's ActionURL and expect it to
work.
#2 is compatible with portlets, but it would be best to have the hidden
field namespaced. Otherwise it would be like javax.faces.VIEW_ID which is
not namespaced, and can cause problems in portals.
Neil
On Sep 21, 2010, at 1:15 PM, 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