On Mon, Sep 27, 2010 at 9:31 PM, Roger Kitain <span dir="ltr"><<a href="mailto:roger.kitain@oracle.com">roger.kitain@oracle.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
Can you please explain how the "BOTH" config option will work?</div></blockquote><div><br>This would use both algorithms -- hidden field and appending the token to the URL. To simplify things, we could probably use the same mechanism for generating the token internally for both, but that should probably be up to the implementation.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000"><div><div></div><div class="h5"><br>
<br>
On 9/27/10 5:12 PM, Kito Mann wrote:
<blockquote type="cite">On Tue, Sep 21, 2010 at 1:15 PM, Roger Kitain <span dir="ltr"><<a href="mailto:roger.kitain@oracle.com" target="_blank">roger.kitain@oracle.com</a>></span>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
There are two proposals for enhancing CSRF attacks in JSF. We
need to pick one.<br>
</blockquote>
<div><br>
Why? I think it's actually safer to allow both: <a href="http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL" target="_blank">http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL</a>.
According to this, appending the token works better when you
can't guarantee that a server-side operation is occurring only
through POST. Especially with the new capabilities of JSF 2
for parsing view parameters, I don't think we can make this
guarantee.<br>
<br>
Also, the rewriting approach is what they're using for the
generic filter in Tomcat 7: <a href="http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL" target="_blank">http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL</a>.
I was talking to Mark Thomas, the guy working on this feature,
about this at JavaOne. As you can see, it doesn't even look
like they're using the hidden field approach (probably because
it'd be very hard to implement in a generic fashion). <br>
<br>
So, I think we should provide both features, but give the
users to turn off either algorithm, with a context parameter
such as:<br>
<br>
javax.faces.CSRF_ALGORITHM=NONE | FORM | URL | BOTH (or ALL)<br>
<br>
Thoughts?<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Proposal 1: Form Action URL Approach (Approach provided by
Kito Mann)<br>
<br>
This approach does the following: - Token is generated on
the server consisting (minimally) of a randomly generated
"secret key<br>
(stored in session).<br>
- ViewHandler.getActionURL method must include the token
parameter<br>
named "javax.faces.Token", and whose value is the token
value.<br>
- At render time this token will be included in Form's
action URL - and it will be<br>
posted back to the server.<br>
- Restore View Phase processing compares the incoming token
request parameter value<br>
with the token value generated from the secret key in the
session.<br>
<br>
Spec Document Modifications:<br>
<br>
Section 7.5.1:<br>
<br>
getActionURL:<br>
<br>
"The URL must contain the parameter constant defined by
ResponseStateManager.VIEW_TOKEN_PARAM<br>
The value of this parameter must be a cryptographically
produced value minimally consisting<br>
of a "secret key". The "secret key" is a random generated
value that was stored in the session<br>
(preferably around session creation time). Implementations
may also choose to combine other<br>
values with the secret key to produce a more complex token."<br>
<br>
Section 2.2.1<br>
<br>
"Verify the "javax.faces.Token" request parameter value is
the same as the token value generated<br>
from the "secret key" stored in the session. If the values
do not match, throw a meaningful<br>
exception."<br>
<br>
<br>
Proposal 2: Form Hidden Field Approach<br>
<br>
This approach is similar to Approach 1, except a Form hidden
field "javax.faces.Token"<br>
is used instead of appending to the Form's Action URL.<br>
<br>
Spec Document Modifications:<br>
<br>
Standard RenderKit Docs<br>
<br>
- Form Rendering<br>
<br>
"Render a hidden field named "javax.faces.Token" using the
ResponseStateManager.VIEW_TOKEN_PARAM<br>
constant. The value of this hidden field is a
cryptographically produced value that must at least<br>
consist of a "secret key". The "secret key" is a random
generated value that was stored in the<br>
session (preferably around session creation time).
Implementations may also choose to combine<br>
other values with the secret key to produce a more complex
token."<br>
<br>
Specification Document<br>
<br>
Section 2.2.1<br>
"Verify the "javax.faces.Token" request parameter value is
the same as the token value generated<br>
from the "secret key" stored in the session. If the values
do not match, throw a FacesException.<br>
<br>
<br>
For both approaches see:<br>
<br>
<br>
[1] <a href="https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=869" target="_blank">https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=869</a><br>
<br>
Look at the two latest change bundles attached to the issue.<br>
<br>
Please review by COB Friday as we have no time left for 2.1.<br>
<br>
Kudos to Kito Mann for helping out with the implementation.<br>
<font color="#888888">
<br>
-roger<br>
</font></blockquote>
</div>
<br>
</blockquote>
<br>
<br>
</div></div><font color="#888888"><pre cols="72">--
<a href="mailto:roger.kitain@oracle.com" target="_blank">roger.kitain@oracle.com</a>
<a href="https://twitter.com/rogerk09" target="_blank">https://twitter.com/rogerk09</a>
<a href="http://www.java.net/blogs/rogerk" target="_blank">http://www.java.net/blogs/rogerk</a> </pre>
</font></div>
</blockquote></div><br>