WHASOLS includes many features to help keep your data safe, but you can simple additional steps to secure your WHASOLS installation further.

Secure the Writeable Directories

We recommend moving all writeable directories to a non-public location to prevent web based access. There are three required writeable directories: public, attachments, downloads and templates_c

You must specify the new location of the writeable directories in WHASOLS. This is done in two places:

File Storage
You can move the attachments and downloads storage directories to a local location, or you can store them remotely on compatible Third-party service. If you are unfamiliar with the Third-party service, we recommend using the local storage option.

To do this:

Create the storage location. This could be either:
  • A writeable directory on your server above the web root.
  • A non-public Third-party compatible storage bucket.
Navigate to Configuration  > Storage Settings.
Use the interface to add the secure storage locations and switch to them.
For step-by-step guidance using this interface, see Storage Settings.

Templates Cache
You can use the templates cache (templates_c) to improve performance of templated pages and emails.

To do this:

Create a templates_c directory in the desired location (a non-public location above your web root).
Edit the .env file and specify the path to the new location by adding a new line:
WS_STORAGE_PATH=storage/

If you are running suPHP or PHP suEXEC, chmod 755 should be sufficient permissions to make the directories writeable. This is the highest permission available for both folders and files when running in that condition.

Secure the .env File

We recommend adjusting the permissions for the ".env" file in your WHASOLS root directory. This file contains sensitive data that you can't recover without a backup of the file. To avoid accidentally overwriting, editing or deleting the file, change the permission setting of this file to 400. This provides the system with read-only access and prevents anyone else from reading, editing or executing the file.

To change the permissions on this file, you can run the following command while in your WHASOLS root directory:

chmod 400 .env

Attention!
Some systems may require you to set the permission to 440 or 444, depending on the server's configuration. Usually, 400 should suffice, but if you encounter an error loading the application after setting the permission to 400, try 440 and then 444.


Restrict Access by IP

For increased protection, if your staff uses fixed IP addresses, you can restrict access to a specific set of IPs. To do this, create a file with the name .htaccess in your WHASOLS admin directory with the following content:

Apache 2.2
order deny,allow
allow from 12.34.5.67
allow from 98.76.54.32
deny from all
Apache 2.4
Require ip 12.34.5.67
Require ip 98.76.54.32
You can specify as many different allow from or Require ip lines as you require. You can allow entire IP subnets by specifying just the first part of an IP address (for example, 12.34.). This is .htaccess IP restriction.

Change your WHASOLS Admin Folder Name

Optionally, customising the URL of your WHASOLS Admin Area can make it harder for bots and malicious users to find it. For steps, see Customising the Admin Directory.

Restrict Database Privileges

Disable any unneeded database privileges.

Most tasks only require the following database privileges:

  • DELETE
  • INSERT
  • SELECT
  • UPDATE
  • LOCK TABLES
Installation, upgrades, and activating and deactivating modules require the following additional privileges:

  • ALTER
  • CREATE
  • DROP
  • INDEX

Enable SSL

As a billing application that handles customer data, there is often private and sensitive data passing between WHASOLS and end user's browsers. Having a valid SSL certificate that enables the use of HTTPS and encrypted communication is essential.

After you configure an SSL certificate, enter the https://-enabled URL in the WHASOLS System URL text box in the General tab at Configuration  > General Settings to ensure that the system uses it.

If you do not have an SSL certificate, purchase one.

Vendor Directory
We distribute WHASOLS with a vendor directory ("/vendors"). This is a common directory for advanced scripts and applications, such as WHASOLS, and includes various common libraries. However, web servers should not serve file requests directly from this path. Only the controlling script or application should load these libraries in order to ensure appropriate context and prevent unexpected behavior.

Apache is the recommended web server software platform on which to run WHASOLS. If you are using Apache, the .htaccess file that WHASOLS distributes in the /vendors directory should suffice. If you are running Apache and files remain accessible, investigate whether your Apache configuration has disabled the use of .htaccess files or there is a parent configuration that is negating the directive in the provided .htaccess file.

While we don't officially support other web server technologies, we understand that some users do wish to run WHASOLS in environments other than Apache. To do this, you must ensure that your web server configuration does not serve files within the /vendors directory.

If you are using NGINX as your web server, see Nginx Directory Access Restriction.

<< Back to Installation Overview

Defending Against Clickjacking
Clickjacking is a type of attack where the attacker commonly uses iframes and styling to load an external page (such as the WHASOLS client area) and attempts to trick the user into performing an action that may, unknowingly to the user, give the attacker access to their information. Detailed information on how this type of attack works, the potential effects, and how to defend against it at the server-level by sending the proper Content Security Policy (CSP) frame-ancestors directive response headers that instruct the visitor's browser to not allow framing from other domains can be found in the OWASP Clickjacking article.

Server Hardening
In addition to the above, it is always recommended to perform a general server hardening to help mitigate any possible server security issues, such as preventing unauthorized access.

For help in implementing best security practices, see Security Best Practices and Security Misconfiguration.

Any questions or concerns regarding server security, or items beyond the above, are best addressed to a qualified system administrator. They will be best positioned to review the server, assess the installed software and configuration, and provide tailored recommendations and assistance based on that.