History: TikiSecurity

To allow us time to patch the system, please report the vulnerability using the bug tracking system using the category "security" but without detailing the vulnerability so it cannot be exploited. Leave your e-mail so we can contact you, or contact security at tikiwiki.org and we'll deal with your input.

Cross-Site Request Forgeries (CSRF)

Taken from PHP Under Attack:
Cross Site Request Forgery (CSRF) exploits the trust a web site has for a particular user. It involves tricking a user into unknowingly sending a HTTP request of the attacker's choosing to the vulnerable web site. The following example demonstrates CSRF:

1. A trusted user logs into http://top-secret-site.com/vulnerable.cgi
2. The user is tricked into visiting a malicious site.
3. The malicious web site sends the user the followig HTML:

< img src="http://top-secret-site.com/vulnerable.cgi?action=trusteduseraction&user=gullibledude">

The following is an article from ApacheCon - very good reading.
Secure PHP Programming: Foiling Cross-Site Attacks

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")
http://www.tux.org/~peterw/csrf.txt

2003/07 php conference at oscon 2003
http://conferences.oreillynet.com/os2003/php/

PHP Under Attack
http://conferences.oreillynet.com/cs/os2003/view/e_sess/4114

PHP Under Attack OSCON 2003 (slide)
http://talks.php.net/show/php-under-attack
http://talks.php.net/show/php-under-attack/11
http://talks.php.net/show/php-under-attack/15

Read documentation in comments of file lib/tikiticketlib.php :
http://de.tikiwiki.org/xref-head/lib/tikiticketlib.php.source.html

security bugtraq

security bugtraq

Easy DOS?

• Hitting F5 repeatedly to refresh a page can ratchet up server load easily... try it at home see what happens
• the ab command if you've got apache running... try this one at home
  • ab -n 15 http://YOURTIKISITE.com:80/tiki-index.php
    • I watched my server load climb quickly as this benchmark was run... This seems like an easy DOS tactic to me.

Content in filesystem

If well most of data in Tiki is stored in a database, some can be stored in filesystem, like file or image galleries, or backups. Those directories could be outside the web tree (but accessable from apache/php), or have some restriction in the webserver to be accessed directly, i.e. for apache servers a file named .htaccess could be put in those directories with something like

))AuthType(( Basic
))AuthUserFile(( /dev/null
))AuthGroupFile(( /dev/null
Require valid-user

This should work in any directory which content should not be accesible directly, but what happens with i.e. img/wiki_up? For those dirs in apache configuration could be made, i.e. adding a directory directive for the wiki_up directory, and inside that directive, a files ".php" directive to block the loading from that dir of php files (and could be done more for other kind of executable files that could be put there, i.e. shtml) much like the disabling of loading .htaccess files is already done in apache configuration. (this description should be heavily rewritten for clarity 😀 )