Web applications are more and more popular, more and more used, and, in consequence, more open to abuse than in past years. Tricks like XSS and CSRF are begining to spread rapidly, at least in rumor, in specialized networks. All live web applications need to verify they have basic protections against such abuses if they intend to provide a trustworthy work environment.
Jun0 brought attention to the vulnerability of tikiwiki to the CSRF trick. After some examination and work, a commando patch operation added basic protection in tikiwiki. 1.7.5, under test right now, was created to meet the security needs of the community, and will be released in next hours/days. If security is vital to your activities, upgrade now to cvs version; branches 1.7, 1.8, and HEAD are patched. We need your help to track possible side effect of the patch, then we can release without fear of regression.
Here is the mail I recently sent to a small number of tikiwiki developers explaining the whole story...
Here is a mail I sent some days ago to some tikidevelopers for recruiting some help with patching...'
yo That is a very long mail, about a complicated but important topic concerning security. In such matter, information spreading has to be cautious before action is reazdy to be done, that's why we restricted that announce, in a first wave, to a restricted number of mature tiki developers. Jun is a japanese developer that worked on postnuke and xoops, especially on some security issues about XSS and CSRF vulnerabilities. He rush on irc and yelled silently to us that tikiwiki is very vulnerable to "Sea Surfing". After long nights of talking with damian and redflo, I prepared a step forward that is not final but has advantage of being possible to implement fast. I dled tiki 1.0 and tried to find a way to fix it that could be used on any version. My idea is that rewriting all links and forms is not very easy and is a huge amount of work we would have to conduct at least twice (1.7 and 1.8 branches). So the principle is to setup an area session variable in sensitive zone to substitue to the referer check that is no trustable. There is some flaws in that choice, I wish we can discuss about it more deeply. Registered flaws: * each page in edit mode has to be free of possible user-input links, because protection is granted by the editmode. Possible user-input links can occur : - in shoutbox, the auto-linking is optional, imho, it should be forbidden. - mod-directory_top_sites.php and mod-directory_top_sites.php We can setup a flag that is called $enable_user_links that would be tested befor displaying or using links in those modules. - featured links module is concerned too, but probably used by admin only and not by users. - user_bookmarks maybe would require some good attention so it don't get hacked and CSRF links are not included there. All other modules only contain script-generated links that should be safe. * There is some cases where the form and the display are in the same page with no test on a variable. In such case, if the display contains a user link, the page is vulnerable to actions. Those ones maybe would require an auth-id in links and forms : - all pages with lists that propose a delete action. They have no confimration step and it make them vulnerable to a delete link included in one content (can't be done everywhere, but uin many places) -> we have to setup confirm steps for delete actions, then the delete will be protected by the session trick. - tiki-view_forum_thread.php can be abused with links to actions on this page, like deleting or changing things. - tiki-faq_questions.php should strip html from question and answer, maybe. Right now it can be abused with a forged link to approve or delete a Q/A.. * comments are special cases. there can be links there. But usually they are not displayed with edit_forms. * I thought it would be possible to patch everything automatically, but there is too much diversity in tiki, and manual operation would be required. But with the use of only session it's 2 lines to insert at each feature to protect, it can be handled rather fast on each branch. My guess is that one version can be patched in some hours by a couple of people that know tiki very well. I included an email alert in the function for debug, but that can be useful to leave it there afterwards. The 2 weak points are : deleting without confirmation steps, and forums views that melt display and edit. They have to get a solution that imho can't be applied instantly. Confirmation steps could be handled like errors with a generic message that setup the proper area ticket and dies so it's fast to display. About forums, maybe if delete protection is done, a test on _POST rather than _REQUEST could be enough maybe. I attached lib/tikiticket.php that contains instructions of use. what do you think ? Would you help on a rush to fix 1.7.5 then we delay it some days ? cheers, mose, for the tikiwiki admins group
Here are some pieces of background for your personnal knowledge :
(excerpt from many mails from Jun Moriya )
Jun 13, 2001 bugtraq at securityfocus.com
Cross Site Request Forgeries (CSRF, pronounced "sea surf")
2003/07 php conference at oscon 2003
PHP Under Attack
Contribute any relevant information to TikiSecurity !