Loading...
 

Secure Coding Practice Guidelines

General Coding Guidelines

Avoid using $_REQUEST

Only when both $_GET and $_POST variables are expected should $_REQUEST be used. Post variables are not accessible to a number of attacks, so if there is no reason to accept $_GET, don't.

Creating a New File

CSRF Checks

under what conditions a check needs to be made. Basic implementation of ticket and referrer check.

XSS Filtering

Every file that can run directly (most notably the files that begin with tiki-) needs to have a $inputConfiguration declaration before tiki-setup.php is called. Each $_POST and $_GET variable should be filtered here to prevent XSS attacks. It's a tiki policy to filter every variable even if the code does not permit an XSS attack for two reasons:

  • Code modification in the future may open security issues.
  • It allows auditing of variables in the future, to double check the page is XSS safe.


Note that 'staticKeyFilters' will not work with array content, they must be placed in 'staticKeyFiltersForArrays'.

It is highly encouraged that each page also unsets all variables not filtered through $inputConfiguration. This is done by setting 'catchAllUnset' to null. This practice helps us audit pages for XSS protection and prevents accidental omission of variables. If it's not posable to unset the remaining variables, a comment should be left as to the reason why so efforts are not duplicated in securing the page.

A list of available filters and what they do may be seen here: lib/core/TikiFilter.php. In general, the best practice is to choose the filter that imposes the most strict conditions that will work in a given situation. The 'xss' and lastly 'none' filters should only ever be used if no other options are avalable.
You can read more about filtering in tiki here: Filtering Best Practices

Below is a code example that shows how variables may be filtered on a page that uses the variables: send, priority, from & taffyArray:

$inputConfiguration =	[[
	'staticKeyFilters'	=> [
		'send'			=> 'word',
		'priority'		=> 'int',
		'from'			=> 'striptags',
	],
	'staticKeyFiltersForArrays' => [
		'taffyArray'	=> 'digits',
	],
	'catchAllUnset'		=> null
]];

Feature & Permission Checks


Every file that can be run directly (most notably the files that begin with tiki-) should begin with limiting access to that file based on the user's permissions and also features enabled in tiki. If it's a feature that is always on and has no special user privileges to access, then these checks are not needed.

The following code is how tiki-calendar_import.php implements these checks:

$access->check_feature('feature_calendar');
$access->check_permission('tiki_p_admin_calendar');

Direct Access Check


Any file that is not simply a library (a file filled with a single class), and is not intended to be called directly should prevent direct access to the file with the following code:

if (basename($_SERVER['SCRIPT_NAME']) === basename(__FILE__)) {
	die('This script may only be included.');
}

Command Line Interface (CLI) Checks


Any file that is intended to be run from the command line only should restrict access to CLI only with the following code:

if (isset($_SERVER['REQUEST_METHOD'])) {
	die('Only available through command-line.');
}

Creating a New Directory

Prevent Directory Browsing

It's a convention in tiki to prevent directory browsing. The security gains may be negligible in many instances, but perhaps critical in a few. In any new directory simply drop a blank file titled: index.php into it. This prevents directory browsing under most server conditions.

Whitelisting File Types

If your directory is in the root folder, you will need to add a .htaccess file that whitelists file types that may be directly called by a browser. All subfolders take there rules from the parent folder so therefore do not need a new .htaccess. Below is an example of a .htaccess file that prevents access to all files except images, note that these files may still be read and accessed by PHP, through an include statement or otherwise:

<FilesMatch ".*">
	<IfModule mod_authz_core.c>
		Require all denied
	</IfModule>
	<IfModule !mod_authz_core.c>
		order deny,allow
		deny from all
	</IfModule>
</FilesMatch>

<FilesMatch "\.(jpe?g|png|svg|gif)$">
	<IfModule mod_authz_core.c>
		Require all granted
	</IfModule>
	<IfModule !mod_authz_core.c>
		Allow from all
	</IfModule>
</FilesMatch>

# -- Prevent Directory Browsing -- #
Options -Indexes

Adding Third Party Libraries

Remove unnecessary files

Some standard directories and files are removed in CleanVendors such as demo, docs and test etc, but other default files, especially PHP and some HTML ones, need to be removed specifically there. The clean function is run after composer update and install so the developer needs to make sure no problematic example files remain in vendors_bundled and add the code to remove any leftovers if necessary.

Update .htaccess for vendors

Sometimes possibly vulnerable files need to be included in the library for it to work, but vendor_bundled/.htaccess prevents anything apart from images, JavaScript and CSS to be accessed from the browser, so any exceptions to this should be added to this .htaccess file. This is unusual, however.

Page last modified on Sunday 15 April, 2018 10:27:29 GMT-0000

Keywords

The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.

Accessibility (WAI & 508)
Accounting
Administration
Ajax
Articles & Submissions
Backlinks
Banner
Batch
BigBlueButton audio/video/chat/screensharing
Blog
Bookmark
Browser Compatibility
Calendar
Category
Chat
Comment
Communication Center
Consistency
Contacts Address book
Contact us
Content template
Contribution
Cookie
Copyright
Credits
Custom Home (and Group Home Page)
Database MySQL - MyISAM
Database MySQL - InnoDB
Date and Time
Debugger Console
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Docs
DogFood
Draw
Dynamic Content
Preferences
Dynamic Variable
External Authentication
FAQ
Featured links
Feeds (RSS)
File Gallery
Forum
Friendship Network (Community)
Group
Help
History
Hotword
HTML Page
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Import-Export
Install
Integrator
Interoperability
Inter-User Messages
InterTiki
jQuery
Kaltura video management
Karma
Live Support
Logs (system & action)
Lost edit protection
Mail-in
Map
Menu
Meta Tag
Missing features
Visual Mapping
Mobile
Mods
Modules
MultiTiki
MyTiki
Newsletter
Notepad
OS independence (Non-Linux, Windows/IIS, Mac, BSD)
Organic Groups (Self-managed Teams)
Packages
Payment
PDF
Performance Speed / Load / Compression / Cache
Permission
Poll
Profiles
Quiz
Rating
Realname
Report
Revision Approval
Scheduler
Score
Search engine optimization (SEO)
Search
Security
Semantic links
Share
Shopping Cart
Shoutbox
Site Identity
Slideshow
Smarty Template
Social Networking
Spam protection (Anti-bot CATPCHA)
Spellcheck
Spreadsheet
Staging and Approval
Stats
Survey
Syntax Highlighter (Codemirror)
Tablesorter
Tags
Task
Tell a Friend, alert + Social Bookmarking
Terms and Conditions
Theme
TikiTests
Timesheet
Token Access
Toolbar (Quicktags)
Tours
Trackers
TRIM
User Administration
User Files
User Menu
Watch
Webmail and Groupmail
WebServices
Wiki History, page rename, etc
Wiki plugins extends basic syntax
Wiki syntax text area, parser, etc
Wiki structure (book and table of content)
Workspace and perspectives
WYSIWTSN
WYSIWYCA
WYSIWYG
XMLRPC
XMPP




Useful Tools