[seam-dev] XSRF and JSF2

Christian Bauer christian.bauer at gmail.com
Fri Oct 3 06:51:39 EDT 2008


On Oct 03, 2008, at 05:12 , Shane Bryzak wrote:

> The problem that I can see with securing Seam Remoting from XSRF  
> attacks is that every single other request (both GET and POST) sent  
> in the application is going to require the added protection of this  
> token, otherwise I can see an obvious security flaw.  Also, I'm  
> wondering how page refreshes should be handled, and not to mention  
> bookmarkable URLs?  Each of these things seems to be a vector into  
> which an XSRF attack can occur as they are both "unprotected".

Depending on the level of protection you want, the unique value of the  
token can have the scopes:

- SESSION: Really just an additional session identifier that is NOT  
automatically submitted by the browser (like the session cookie) but  
must be included in any POST (or unsafe GET) request.

- PAGE: All POSTs of that view (may be several forms on it) will  
include that token. That is what the view identifier value in JSF is  
supposed to do. However, it seems that at least the Sun RI generates  
only an incremental value: <input type="hidden"  
name="javax.faces.ViewState" id="javax.faces.ViewState" value="j_id1" / 
 >. You can guess that secret easily and submit a form from a  
different website, as long as the user is logged in.

- Form: Each <s:form> gets its own hidden field with a unique token  
value. It's validated in RESTORE VIEW against the stored value. This  
is how the Struts taglib does it AFAIK.





More information about the seam-dev mailing list