Hi Frank, I thought about CSRF protection and the general idea already stands. We should now figure out how we want to have it implemented and then I will start working on it.
What we need for it would first be a good PRNG (pseudo random number generator). I dug up some code from here: http://forums.thedailywtf.com/forums/t/16453.aspx I looked through it and it seems like a reasonable approach though its fallback is silent and we should think about any kind of user notification or removing the fallback. The important thing here is the seed and this needs to be as random as possible and no microtime or PID stuff will be random enough. The solution basically tries: - OpenSSL (very good!) - /dev/urandom (nice one as long as the maintainers keep it random, Debian already did screw up, but random enough for our needs, Unix only though) - CAPICOM (Windows, uses CryptoAPI, also not bad if we are on Windows) - Fallback to crappy microtime stuff So by this we get a rood new random number for the seed which will then be used by the wrapper for PHPs random function. I stuffed this into the OC_Util class but we could also think of some place else. The next thing will now be the question of how to keep track of the tokens generated. The general suggestion here that keeps balance between usability and security is a per-session token. My knowledge on the database and such is limited so I need to know where we could store such session information. Then I will create simple functions allowing for a token check and of course the generation. Also a wrapper will be useful that inserts a form element (so that does not get passed to the user). Another thing that needs to be discussed is in which way we want to inform developers about the existence (and importance) of such tokens, i.e. if noone knows about them we did not fix anything. The basic approach would be to write a good documentation and just leave it to the developers. Another approach would be to fail any requests if neither a token was added nor was the request marked is non-critical (in some way). I leave that decision up to you guys, I have a hard time deciding for either solution but I guess for compatibility you should just take the first approach and just spread the word. Looking forward to your thoughts, Florian On 08.06.2012 16:42, 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 > > 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. > > > 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. > > > The two needed calls could work like this: > > > /** > * Register an get/post call > */ > public static function callRegister(){ > // generate a random token. > // store the token together with a timestamp in the session. > // return the token > } > > > /** > * Check an ajax get/post call > */ > public static function callCheck(){ > // searches in the get and post arrays for the token. > // check if the token is in the user session and if the timestamp is > from the last hour. > // exit if not found and return of found. > } > > > The callRegister call has to be included on all pages with links, ajax calls > or forms. > The callCheck has to be included on all pages that are called by other pages. > > > Opinions? Does this make sense? > > And does someone volunteer to help me to implement all this? :-) > > > > 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
