Christopher Laco wrote:
Aristotle Pagaltzis wrote:* Peter Karman <[EMAIL PROTECTED]> [2008-01-23 03:50]:In my apps, I do server-side auth checks to verify that users can't act on data they should not have access to.Peter, meet XSRF. XSRF, meet Peter. :-) My point with `<img src="/foo/delete">` was that an attacker tries to get an authenticated and authorised user to visit a page which contains that tag. Or maybe an authenticated and authorised user has software like the Google Web Accelerator installed. Regards,But surely the same is true for POST as well using a form/javascript. So what does that leave?
According to: http://en.wikipedia.org/wiki/Cross-site_request_forgery#Prevention
------ PreventionFor the web site, switching from a persistent authentication method (e.g. a cookie or HTTP authentication) to a transient authentication method (e.g. a hidden field provided on every form) will help prevent these attacks. A similar approach is to include a secret, user-specific token in forms that is verified in addition to the cookie.
An alternate method is to "double submit" cookies. This method only works with Ajax based requests, but it can be applied as a global fix without needing to alter a large number of forms. If an authentication cookie is read using JavaScript before the post is made, the stricter (and more correct) cross-domain rules will be applied. If the server requires requests to contain the value of the authentication cookie in the body of POST requests or the URL of GET requests, then the request must have come from a trusted domain, since other domains are unable to read cookies from the trusting domain. On the other hand, this method forces users to enable JavaScript, negating the only way a user has to prevent most cross-site scripting vulnerabilities from being exploited.
Using POST instead of GET does not offer protection, as JavaScript can be used to forge POST requests with ease.
Checking the HTTP referrer header to see if the request is coming from an authorized page can work, but may cause issues with browser that omit the referrer header in certain occasions or setting. (E.g., a user's privacy settings or because the referrer is a secure page.)
Although cross-site request forgery defenses typically require modifying the web application, individual users can help protect their accounts at poorly designed sites by logging off the site before visiting another.[1]
--------Trading double submit stuff and adding to POSTS makes the code more interesting than HTTP auth per request. Seems like a tradeoff in either case. And maybe XSRF isn't really an issue if the AJAX/Browser code is completely seperated form the REST interface. If clients aren't using their browser against the REST interface...than the worry of XSRF are dimished I would think.
-=Chris
signature.asc
Description: OpenPGP digital signature
_______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
