Tikiwiki and Sea Surfing

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