Security overview
  • 21 Jun 2022
  • 8 minutes to read

Security overview


Article Summary

The security overview report can be accessed via the Quick-access menu > Security > Security overview. It displays a report on the status of all of the key security settings from within the system, showing whether the current setting is OK. If there is a problem you will see a status of; Warning or Serious which means you should review that setting and ensure you are aware of the security risks or take necessary corrective steps. 

The Guest role is intended for non-logged-in, temporary users and therefore no risky permissions/capabilities should be given to this role.

SettingDescriptionNotes
Insecure dataroot

User files are stored by Totara in the data root. To keep it secure this should not be accessible from the web.

If the data root directory is moved then the $CFG->datarootsetting will need to be updated in the config.php file.

Displaying of PHP errors

This should be turned off for all live/production sites, as it could create a security vulnerability. If PHP is set to display errors it would allow someone to gain information such as directory structures by entering a faulty URL (prompting PHP to display details about the error and the system).

This can be changed in the php.ini file. Open the file and set display_errors to display_errors=Off.

Vendor directory

The vendor directory contains various third-party libraries and their dependencies, typically installed by the PHP Composer. It may be required for local development, such as for installing the PHPUnit framework. But it can also contain potentially dangerous code, exposing your site to remote attacks.

It is strongly recommended to remove the directory if the site is available via a public URL, or at least prohibit web access to it.

-

Node.js modules directory

The node_modules directory contains Node.js modules and their dependencies, typically installed by the NPM utility. These modules may be required for Totara's development. They are not needed to run a Totara site, and they can contain potentially dangerous code exposing your site to remote attacks.

It is strongly recommended to remove the directory if the site is available via a public URL, or at least prohibit web access to it.

-

No authentication

This setting should be turned off on live/production sites, as it would allow someone to create an account with no authentication, meaning they could even use an email address that does not exist and there is no verification required.

This can be turned off by going to Quick-access > Plugins > Authentication > Manage authentication and ensuring that it is disabled.

Allow EMBED and OBJECT

As a default security measure, normal users are not allowed to embed multimedia (like Flash) within the text using explicit EMBED and OBJECT tags in their HTML (although it can still be done safely using the mediaplugins filter). If you wish to allow these tags then enable this option in the Security settings.

To configure this go to Quick-access menu > Security > Security settings.

Enabled .swf media filter

It is not recommended to enable automatic embedding of Flash (.swf) files by default as this could enable a user to launch a Cross-Site Scripting (XXS) attack, by using a file that contains some malicious code.

You can control this by ensuring the Convert URLs into links and images setting is disabled under Quick-access menu > Plugins > Filters > Manage filters. You can also choose whether to allow Flash files in the media player settings under Quick-access menu > Plugins > Media players > Manage media players.

Open user profiles

If you leave all of the user profiles open then there is a risk these could be abused by spammers (as they would be publicly viewable). It is recommended that you only make user profiles available to logged-in users.

Control this by configuring the Force users to log in and Force users to log in for profiles settings under Quick-access menu > Security > Security settings.

Open to Google

This setting works with Guest access to allow search engines to access courses with the guest access permissions. Note that allowing Google access to your site will mean that all contents are publicly accessible, so only do this if there is no confidential or sensitive information on your site.

This is configured under Quick-access menu > Security > Security settings.

Password policy

Using a password policy helps make your site more secure by encouraging/forcing good password habits, including more complex passwords (which are harder to guess) and also more frequent changing of passwords (if they are easier to guess). Try not to make password requirements too strict or difficult though as this might lead to users forgetting their passwords or writing them down, thus negating any security benefits.

This is configured under Quick-access menu > Security > Security settings.

Email change confirmation

You can choose to force users to confirm any changes they make to their email address. It is recommended that you do this to prevent spammers from exploiting your server.

This is configured under Quick-access menu > Security > Security settings.

Username enumeration

When a user enters incorrect login credentials Totara ensures that it is vague about the reason for the unsuccessful login, so that anyone trying to attack the site cannot tell if the username or password is wrong. Username enumeration is a process that potential attackers can use to figure out what the username convention is for your Totara site so that they only need to guess the password of a user to get access.

You can disable the Self registration setting in Quick-access menu > Plugins > Authentication > Manage authentication (as potential attackers could generate their own usernames to figure out the pattern).
 
You should enable Protect username so that no hints are given to potential attackers if they click the forgotten password link. This can be done under Quick-access menu > Security > Security settings.

HTTPS protocols

As HTTP protocol is easily exploitable, it is recommended that you use HTTPS protocol on all your servers.

-

Secure cookies

You should enable Secure cookies if you are allowing HTTPS communications with your site (recommended). It is also advisable to only use HSTS headers and set up permanent redirects for any HTTP pages to HTTPS.

Secure cookies can be enabled via Quick-access menu > Security > HTTP security.

HTTP only cookies

This prevents scripts from accessing cookies sent by your server so that cookies are only accessible by actual requests. This can help reduce the risk of Cross-Site Scripting (XSS) attacks.

HTTP-only cookies can be enabled from Quick-access menu > Security > HTTP security. Note that some older browsers may not support this feature.

Persistent login

If enabled, persistent logins ignore standard session timeouts and set a permanent browser cookie. This cookie is later used to automatically re-login users after browser restart or session timeout.

This can be configured via Quick-access menu > Security > Security settings.

SCORM session keep alive

If enabled, the user session is kept alive in the SCORM player. 

Can be configured in Quick-access menu > Plugins > Activity modules > SCORM package.

Writable config.php

After you have installed your Totara site you should edit the config.php file to ensure it is set to read-only, meaning it cannot be modified by the webserver.

You will need to CHMOD the config.php file to either 644 or 444 to ensure it is read-only.

XSS trusted users

Some content, such as certain multimedia files, HTML code, JavaScript, and Flash applets can be used to attack your site using a cross-site scripting attack (XSS attack). Certain capabilities will allow roles/users within your site to add these types of content, as they can be useful for training purposes. However, it is important to make sure that you only allow trusted users to have access to these capabilities. This setting in the overview report will show a list of users with these abilities, so you can check they are all trusted individuals.

-

Administrators

It is advisable to keep the number of Site Administrators to a minimum. If users do not need all the permissions/capabilities of a Site Administrator please consider another role, such as Site Manager.

You can adjust the number of Site Administrators under Quick-access menu > Permissions > Site administrators.

Backup of user data

This setting checks for roles that have the backup:userinfo capability, as holders of this permission can back up all of the user data (including relevant user account details) when backing up a course. This could lead to a security breach if in the wrong hands. It is also recommended that you ensure a robust password policy, to protect the accounts of users with this capability.

The ability to back up user data is separate from the ability to back up course data. By default, only the manager role can back up user data.

Password policies can be set up via Quick-access menu > Security > Security settings.

Default role for all users

The default user role is normally set as Authenticated user. If you see the status of Critical then this means the role is not correctly configured, and that some risky capabilities may have been given to it. You can edit the permissions of the role by going to Quick-access menu > Users > Permissions > Define roles, then clicking on Authenticated user and browsing the permissions column to check everything is as expected.

This can be configured under Quick-access menu > Permissions > User policies.

Guest role

This can be configured under Quick-access menu > Permissions > User policies.

Frontpage role

The default frontpage role is given to all registered users for front page activities. Please ensure that no risky capabilities are allowed for this role.

It is recommended that a special role is created for this purpose and a legacy type role is not used.

Configured via Edit settings in the Administration block on the front page. 

Web cron

It is recommended that you only run cron from the command line, as running cron from a web browser risks exposing privileged information to anonymous users. Additionally, you could set a cron password for remote access.

This is configured under Quick-access menu > Security > Security settings.

Guest access

You will need to carefully consider the security risks associated with allowing access to the site without a user account (which is possible via guest access). You may wish to consider disabling the Guest login button setting.

Guest access can be managed under Quick-access menu > Plugins > Authentication > Manage authentication. 

URL downloader repository

Enabling the URL downloader can allow external users to access URLs within your internal network. You should not enable this feature if you have users who are allowed to access your site, but not allowed to access other resources within your internal network that are accessible from the server.

-

XXE risk

Some versions of LibXML and PHP potentially load external entities into XML by default, meaning the contents of local files could be obtained by a malicious user. Ensure that you are using up-to-date versions of LibXML and PHP to help prevent this vulnerability.

-

Executable paths

Allowing executable paths to be set via the Admin GUI is a vector for privilege escalation.

-

© Copyright 2024 Totara Learning Solutions. All rights reserved. Some content originally obtained via GPLv3 license and continues to be available under GPLv3. All other content is the sole copyright of Totara Learning Solutions. 


Was this article helpful?

Changing your password will log you out immediately. Use the new password to log back in.
First name must have atleast 2 characters. Numbers and special characters are not allowed.
Last name must have atleast 1 characters. Numbers and special characters are not allowed.
Enter a valid email
Enter a valid password
Your profile has been successfully updated.