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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev