Security

Main Page > Administrator manual > Security

AtoM implements current web application best practice for Security, but creating a fully secure system requires secure practices to be observed at three levels:

1. Web application (AtoM) security
2. Client-side (web browser) security
3. Server-side security

Application security

AtoM's built-in security features include:

• User passwords are hashed using the SHA-1 hashing algorithm with a randomly generated salt
• Protection against SQL Injection attacks via the PHP PDO database interface

Security settings in ICA-AtoM

In Release 1.3 three new security settings were added to AtoM:

• require_ssl_admin: see TLS for more details

• require_strong_passwords: enhance login validation to force use of strong passwords. At least 8 characters long, contains characters from 3 of the following classes:
  1. Upper case letters
  2. Lower case letters
  3. Numbers
  4. Special characters

• limit_admin_ip: limit incoming requests for all administrator functionality to an IP address or an IP range. Two examples:
  1. 192.168.0.1
  2. 192.168.0.1-192.168.0.255

These options are changeable under the settings page. You must be an administrator.

Options 'require_ssl_admin' and 'limit_admin_ip' can be bypassed using the Debug mode, which can only be accessed via the server's loopback interface in the default configuration.

Client security

User authentication is cookie based, so privileged users should restrict access to a trusted network (e.g. internal LAN or encrypted WiFi network) or use Transport Layer Security (TLS) to prevent Session hijacking. See the require_ssl_admin setting above which allows forcing privileged users to use TLS access (Release 1.3 and later).

Server security

Because AtoM is a web application, it is necessary to adequately secure the web server against attacks, both at the operating system (e.g. Windows, Mac OS X, Ubuntu Linux) and web server application (e.g. Apache, IIS, nginx) level. The web server environment should be configured by an experienced systems administrator in accordance with current "best practice" standards. For developers, see the Qubit Toolkit Security documentation for more information about sensitive files within AtoM that may require extra protection.

Stay up to date

The most important security step you can take is to keep your software up to date.

We recommend our users to subscribe to the ICA-AtoM mailing list. New version announcements are always sent to the list.

Don't forget to also keep up with updates to Apache, PHP, MySQL, and any other software running on your servers – both the operating system and other web applications.

General PHP recommendations

These bits of advice go for pretty much any PHP environment, and are not necessarily specific to ICA-AtoM.

PHP configuration recommendations, for php.ini or set otherwise:

• Disable register_globals.
• Unless you require it specifically, disable allow_url_fopen.
• Set session.use_trans_sid off.

General MySQL recommendations

In general, you should keep access to your MySQL database to a minimum. If it will only be used from the single machine it's running on, consider disabling networking support, or enabling local networking access only (via the loopback device, see below), so the server can only communicate with local clients over Unix domain sockets.

If it will be used over a network with a limited number of client machines, consider setting the IP firewall rules to accept access to TCP port 3306 (MySQL's port) only from those machines or only from your local subnet, and reject all accesses from the larger internet. This can help prevent accidentally opening access to your server due to some unknown flaw in MySQL, a mistakenly set overbroad GRANT, or a leaked password.

Upload security

The main concern is: How do we prevent users from uploading malicious files?

User uploads have several implications for security:

• The directory may have to be world-writable, or else owned by the web server's limited user account. On a multiuser system it may be possible for other local users to slip malicious files into your upload directory.
• While PHP's configuration sets a filesize limit on individual uploads, ICA-AtoM doesn't set any limit on total uploads. A malicious (or overzealous) visitor could fill up a disk partition by uploading a lot of files.

Our advice is to disable server-side execution of PHP scripts (and any other scripting types you may have) in the uploads directory (/uploads).

For instance, the following code for Apache/mod_php will do the trick:

<Directory "/var/www/icaatom/uploads">
   # Ignore .htaccess files
   AllowOverride None
   
   # Serve HTML as plaintext, don't execute SHTML
   AddType text/plain .html .htm .shtml .php
   
   # Don't run arbitrary PHP code.
   php_admin_flag engine off
   
   # If you've other scripting languages, disable them too.
</Directory>

---

This document is partially based on the excellent MediaWiki security page, it is strongly recommended to read that too.