Security Considerations

From Habari Project

Jump to: navigation, search

Security always involves a trade off with convenience. Habari has been designed to be as secure as possible by default, and every effort has been made to make administrators and users aware of decisions they make that might diminish the security of their Habari installation. When a user logs in to Habari, a cookie is saved onto the user's machine, allowing access to restricted pages without having to enter a username and password again. To protect accounts from unauthorised accessed, without any plugin, Habari logins timeout after non-use for session timeout period defined in php.ini.

Contents

Reporting A Security Vulnerability

If you think you have discovered a security vulnerability in Habari, please follow the steps below. We'll analyze your report and take appropriate action. If the vulnerability is confirmed, this will usually mean making and testing a fix in private, and once we're satisfied, releasing a new version of Habari and announcing the vulnerability in our release notes.

If you include contact details in your report, we'll acknowledge receipt of your email and keep you informed.

How to Report an Issue

Send the issue report to security {@} habariproject.org without the spaces and braces, with as much detail as possible.

Try to include the following information:

  • Habari version affected,
  • Steps to reproduce the issue,
  • Any sample code to reproduce the issue,
  • Any notes on the environment required to reproduce the issue.

What Happens When You Report an Issue

  • A human will confirm receipt of your report.
  • The report will be evaluated for its effect on the system by one or more Habari committers.
  • Trusted Habari engineers will consult on how best to address the issue, and produce a fix for the currently supported versions of Habari, including the in-development branch, if applicable.
  • The fix will be deployed on the habariproject.org web site, and the update beacon will be set to display a critical update on all Habari dashboards.
  • A blog post will be created to announce the update on the home page. If you reported the issue or helped to fix it, you will be credited with the fix.

General

Staying Logged In

Many systems implement "Remember me" functionality, allowing users to choose to save their login details in a cookie so that they can log in to subsequent sessions without having to enter their username and password at all. While this may be convenient, it also opens a security hole. For example, on shared workstations, forgetting to log out is a very serious security matter, and users may be unaware that their account could be compromised.

To ensure that administrators and users consider security carefully, Habari does not provide "Remember me" functionality in its core. A plugin that allows this convenience over Habari's default security is available. However, you should only install something that makes your site less secure if you really understand the ramifications. If you have further questions about security, please see the Getting Help section on the Main Page of this wiki.

SQLite

Unlike MySQL, which is a client-server database, SQLite is a simple file living in a directory on your web host. As such, it is subject to all the file permission rules that apply to any file on a computer's hard drive.

Habari attempts to improve the security of your SQLite installation by adding a Files section to your .htaccess file to deny access to your database by the web browsing public.

<Files "habari.db">
Order deny,allow
deny from all
</Files> 

habari.db would be replaced with the actual name of your database.

As long as you leave your database somewhere in Habari's directory structure and don't rename it, this section will prevent the browser from directly accessing the database.

Other approaches you take to improving the security of an SQLite installation depends on whether your host runs PHP as a CGI process or as a module of the web server.

PHP As A CGI Process

You can check if PHP is being run as a CGI process by running the phpinfo() function on the server and looking for the SERVER_SOFTWARE entry. It will have something like "PHP-CGI" in the value string. If your host runs PHP as a CGI process, PHP normally has the same permissions that you as the site's owner have. It can read the files you can read. It can write to the files you can write to. Security is fairly good. You can do one of two things to make your database even more secure, though.

First, you can move your database file completely out of your public web directory. After you install Habari, copy your SQLite database file to another directory, for example, /home/user/sqlite. Then, change your config file to tell it where to find the database. When you install Habari, it creates your SQLite database in Habari's base directory. As a result, the connection string in your config file will say something like

'connection_string'=>'sqlite:habari.db'

where habari.db is the name of your SQLite database.

When you move your database, change this connection string to read

'connection_string'=>'sqlite:/home/user/sqlite/habari.db'

If you do move your database, you can create an .htaccess file in the directory to which you move your database file, and in it place a Files directive similar to the one Habari created when it was first installed:

<Files habari.db>
Order deny,allow
deny from all
</Files> 

Replace habari.db with the actual name of your database file. This will keep visitors to your site from directly accessing your database file.

PHP As A Server Module

If your host runs PHP as a module to Apache, security is more difficult, and it is impossible to make an SQLite installation as secure as the previous situation unless the server is running mod_suphp, something over which those on shared hosts have no control.

The reason for this is that SQLite requires the directory in which the database resides to be writable by PHP. When PHP is run as a module, it generally doesn't belong to the same group that you as the site's owner belongs to, and won't have the same permissions as you. SQLite needs to be able to create a journal file in the directory in which the database file exists, so if something happens to the server your data won't be lost. As a result, you have to make the database's directory writable by the world. To minimize the security risks that this entails, you can move your database file into it's own directory and make only that directory world writable by giving it the permission 666, leaving all other directories in your public web structure at their usual permissions. Change the connection string in your config file to look for your database file in the proper place. For example, if you move the database file to

/www/sqlite/habari.db

your connection string would read

'connection_string'=>'sqlite:/www/sqlite/habari.db'

In addition, you can create an .htaccess file in the directory to which you move your database file, and in it place a Files directive similar to the one Habari created when it was first installed:

<Files habari.db>
Order deny,allow
deny from all
</Files> 

Replace habari.db with the actual name of your database file. This will keep visitors to your site from directly accessing your database file.

Personal tools