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="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 mose...@hank.org
_______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/