[Catalyst] [OT] XSS, XSRF, and REST

[Bill Moseley]

We love our acronyms.


As discussed in another recent exciting thread, I use a unique, single-use
token on forms that must be returned with a POST.  This seems to be the best
approach to prevent XSRF[1].  But, what about for a (RESTful) API where it's
common to receive a PUT or POST request without expecting that a GET was
done immediately before to fetch the token?

In those cases I cannot expect that the unique token would be provided.
 Therefore, I need a way relax the token requirement for some requests, but
only if I'm sure it's not coming from a browser that might be generated via
an XSRF attack.

Is it enough to allow the requests if a valid session is is provided in a
Cookie *plus* one of:

   - A valid token in the body parameters (as the case for a valid web
   request)
   - A valid JSON body in the request (assumes that a XSRF could not trick a
   browser into sending json, etc.)
   - A X-Requested-With: 'XMLHttpRequest header (or similar header) that
   would indicate that the request was not generated from a web browser (via
   XSRF attack) because  it included a header not normally sent by browsers.
   - Require API users to fetch a token and place it in a HTTP header or
   body for every request (that seems expensive).  Hum, if a GET can fetch a
   token could the attacker use Flash/Siverlight to accomplish the GET and =
gain
   access to the response data?

Of course, the first two won't work if there's no body (say a DELETE).  Do
(will?) browsers send a DELETE with <form method=3D"delete">?


What approach can you recommend for determining that a request is not from a
XSRF-susceptible client?



[1] A second commonly suggested approach for protecting against XSRF is to
include the session id in the POST.  Then the server can compare the session
id in the cookie (something the XSRF attacking site would not have) to the
session id sent in a body parameter.

The problem I have with this approach is then the client (the web browser)
must have access to the session id either via javascript or directly in the
markup.  I use the HttpOnly to prevent javascript access (in complying
browsers).  And I feel like providing the session ID in the markup opens up
the possibility of XSS that would send the session id to an attacker.  Of
course, a successful XSS attack and your wide open anyway.


-- =

Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100401/002f2=
61f/attachment.htm