[seam-dev] XSRF and JSF2

Shane Bryzak shane.bryzak at jboss.com
Thu Oct 2 23:12:36 EDT 2008


Christian Bauer wrote:
>
> On Oct 03, 2008, at 03:31 , Shane Bryzak wrote:
>
>>> Because it's a random value that is generated for each form 
>>> instance. A good random. Shane, you know what the JSF view 
>>> identifier for server-side state saving is and how it is propagated 
>>> onto the client and validated on the server? That's the XSRF 
>>> protection. I'm wondering if you have the same in Seam Remoting and 
>>> if in general, the randomness of the JSF identifier is good enough.
>>
>> So, for this token to actually work, it must be propagated with every 
>> single request that is sent to the server - included as a request 
>> parameter with every single link, form submission, basically every 
>> single GET and POST request that is made must include the token, right?
>
> Every POST, definitely. GET is supposed to be idempotent and safe, not 
> to modify resource state. So if you abuse it to be non-safe, then yes 
> it needs the same XSRF protection.
>
> And sometimes you have POSTs that are also "safe", like a login form. 
> That's the stateless view we were talking about.

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".


> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev




More information about the seam-dev mailing list