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.