Hi Frank, the same thing Tom wrote I also wanted to give you. And I want to announce myself as a volunteer on the implementation.
I am a student of IT-Security and I have worked to some degree on protection (or discovering unprotected calls) so I could be of some help. I will get back to you as soon as I have gathered more details on this, though my time is limited right now. Regards, Florian On 09.06.2012 15:51, Thomas Müller wrote: > 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 <[email protected]> schrieb: > >> >> On 08.06.2012, at 20:47, Matthew Dawson <[email protected]> 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 >> [email protected] >> https://mail.kde.org/mailman/listinfo/owncloud > _______________________________________________ > Owncloud mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/owncloud _______________________________________________ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
