[Owncloud] Cross-site request forgery protection

[Thomas Müller]

FYI: 
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project

https://github.com/foxbunny/CSRF4PHP

Tom



Frank Karlitschek <frank at owncloud.org> schrieb:

>
>On 08.06.2012, at 20:47, Matthew Dawson <matthew at mjdsystems.ca> wrote:
>
>> On June 8, 2012 04:42:22 PM Frank Karlitschek wrote:
>>> Hi everybody,
>>> 
>>> we have to do something in ownCloud against the CSRF thread. We have some
>>> protection in some areas already but I think we need a general solution
>>> here. We have to check if a GET request, form POST or Ajax request really
>>> comes from the user and ownCloud itself or if it was triggered by an evil
>>> JS script of flash applet from an remote site.
>>> 
>>> Read here for more information:
>>> http://en.wikipedia.org/wiki/Cross-site_request_forgery
>> Sounds good!  Remember though, CSRF's are blind (as mentioned in the wiki 
>> article) so it only matters for requests with side-effects (ie 
>> creating/modifying/deleting data).  A simple request to get information isn't 
>> important.
>
>True.
>
>> 
>>> 
>>> I thought about simpler solutions but they all have problems so I think we
>>> have to do the real thing which means a lot of changes in ownCloud.
>> Well true, maybe there could be some generic measures taken to help protect 
>> against simple mistakes?  Things like checking the Referrer header would help 
>> prevent several drive-by attacks (ie using images).  Its not perfect, but it 
>> would be a good to have for "defence in depth".
>
>I played with this idea too. The problem is that the referrer can be faked if
>the attack comes from a flash applet.
>
>> 
>>> 
>>> 
>>> We have to register every possible ajax call or form submit or button press
>>> on the page where this call could happen with a special function. This
>>> functions returns a token. This token has to be included in the GET or POST
>>> request.
>> <snip functions>
>> Looks good.  It would work for the base pieces.  It might be nice to add one 
>> other function to easily output a hidden input element with the name/value 
>> set, to allow easy integration.
>
>good idea.
>This depends on the way it is integrated. It´s sometimes in JS, sometimes in a template, ..
>So I´m mot sure if it´s worth the effort.
>
>> 
>>> 
>>> Opinions? Does this make sense?
>> I haven't looked at OwnCloud's ajax system, so I'm sorry if this isn't easily 
>> implemented, but the javascript double-cookie check (mentioned in the 
>> Wikipedia article) would be good to use too.  If you can intercept the ajax 
>> outgoing calls, you can restash the PHP session id into the request as a 
>> get/post parameter, and then re-check that the session is correct.  This could 
>> be largely automated, making the protection that much more effective.
>> 
>
>Hmm. not sure I understood this completely. I think the only really save way is to store the token in the session and also transmit it via GET/POST and compare it after the request.
>
>
>I added two helper calls.
>https://gitorious.org/owncloud/owncloud/commit/344299a074e135140262d051531f723be69c786f
>
>Does this make sense?
>
>Feedback is very welcome. And help to port the existing ajax call of course. ;-)
>
>
>Frank
>
>
>_______________________________________________
>Owncloud mailing list
>Owncloud at kde.org
>https://mail.kde.org/mailman/listinfo/owncloud