Guidelines for Writing Secure Extensions

A collection of guidelines on how to write secure extensions to Foswiki.

Organization of scripts, data & code

• Client executed software (Javascript) should not be stored in locations directly writable by the web interface. Consider creating a subdirectory below the Topic directory in pub/System so that Foswiki can't write directly into the location.

Example: Plugin MyJSPlugin accesses javacript files. Store the javascript files in pub/System/MyJSPlugin/scripts/...

• Server executed software (Perl, PHP, etc.) should never be stored in a web readable/writable location. Server code should be stored in tools/ or lib/, never pub/
• Don't assume that controls like .htaccess in Foswiki web accessible directories will work on all systems. Not all servers allow override of the server directories.
• Never use relative directory traversal, such as ../../loc/file
• Use the $Foswiki::cfg{WorkingDir}/tmp directory. Don't assume that /tmp is available.

Calling external programs

• Always use Foswiki::Sandbox for execution, never call the programs directly.
• Helper scripts should be located in tools/, never in bin/ Programs in bin/ can be directly invoked from browser input.
• Sanitize all input. Never trust the content of strings passed from browser input.

Use of Foswiki::Func

• Always interact with Foswiki using the Foswiki::Func interface. Never call other Foswiki routines directly
• Carefully read and understand the security implications of the Foswiki::Func calls.
  • For example: Foswiki::Func::readTopic states "Read topic text and meta data, regardless of access permissions." Any extension using readTopic directly to read outside of the current topic must call Foswiki::Func::checkAccessPermissions before using readTopic.
• Whenever possible, use Foswiki::Func routines for work area access.
• Don't directly access attachments using the file system. Use Foswiki::Func routines. Future releases may move to other forms of backend storage. And accessing the file system directly bypasses security checking on the attachments.
• Note that some Foswiki::Func calls can expose information that the current users would not be entitled. For example, e-mail address or particular group membership. These functions have to exist so that utilities like MailerContrib? can function. When presenting information to the user, be sure to understand whether or not the Foswiki::Func calls you are using enforce access rules.

Use of Foswiki::Meta

• Most topic and attachment interaction can be done with Foswiki::Meta as well as Foswiki::Func
• Foswiki::Meta does not check access rules. Most Foswiki::Func calls check access permission.
• If your plugin is reading or writing topic data using Foswiki::Meta be sure to verify permission first with Foswiki::Meta::haveAccess

HTTP POST versus GET

• Always use POST to send changes to Foswiki scripts. GET should only ever be used to retrieve data, never to write it.
• When writing REST handlers that write to the database, reject requests that use any method other than POST.

Plugin Configuration

• Any extension parameters that control access outside of the Foswiki environment should be limited to the bin/configure maintained LocalSite.cfg. Never code external program paths, file storage paths, etc. in Foswiki macros or in URL parameters.
• Don't use configuration settings in Plugin topics. Use global preferences instead. Global preferences can be finalised if you want to prevent them being changed. Use of plugin preferences can result in accidental overwriting when the plugin is upgraded, potentially compromising security.

Other Perl considerations

• Always validate input from the user (e.g. in files or from the browser) before using it in any eval clauses.