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
