[Catalyst] Re: REST - like uri design for CRUD

[Christopher Laco]

Christopher Laco wrote:
> Aristotle Pagaltzis wrote:
>> * Peter Karman <peter at peknet.com> [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=3D"/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


------
Prevention

For 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.

-=3DChris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20080122/ad3b=
a3fd/signature.pgp