You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
285 lines
15 KiB
285 lines
15 KiB
<html lang="en">
|
|
<head>
|
|
<meta charset="utf-8" />
|
|
<title>Chamilo Security Guide</title>
|
|
<link rel="stylesheet" href="../web/assets/bootstrap/dist/css/bootstrap.css" type="text/css" media="screen,projection" />
|
|
<link rel="stylesheet" href="default.css" type="text/css" media="screen,projection" />
|
|
<link rel="shortcut icon" href="../favicon.ico" type="image/x-icon" />
|
|
</head>
|
|
<body>
|
|
<div class="container">
|
|
<h1>Chamilo LMS: Security Guide</h1>
|
|
|
|
<a href="index.html">Documentation</a> > Security Guide
|
|
|
|
<p>We recommend you don't take security issues too lightly. Chamilo is security-audited at least once a year,
|
|
but you're never too sure. This list is a work in progress. Feel free to recommend additional measures by
|
|
sending us an e-mail at info@chamilo.org.</p>
|
|
|
|
<h2><b>Contents</b></h2>
|
|
<ol>
|
|
<li><a href="#1.Disclosing-server-info">Disclosing server info</a></li>
|
|
<li><a href="#2.Keeping-up-to-date">Keeping up to date</a></li>
|
|
<li><a href="#3.Using-safe-browsers">Using safe browsers</a></li>
|
|
<li><a href="#4.Moving-config-file">Moving your configuration file out of the web directory</a></li>
|
|
<li><a href="#5.Files-permissions">Restricting files permissions</a></li>
|
|
<li><a href="#6.HSTS">HTTP Headers Security</a></li>
|
|
<li><a href="#7.Direct-web-access">Direct web access to files</a></li>
|
|
<li><a href="#8.Disable-webservices">Disable webservices</a></li>
|
|
<li><a href="#9.Change-password-first-login">Change password on first login</a></li>
|
|
<li><a href="#10.Hide-breadcrumb">Hide breadcrumb on unauthorized page load</a></li>
|
|
<li><a href="#11.SVG-and-XSS">SVG and XSS</a></li>
|
|
</ol>
|
|
|
|
<h2><a id="1.Disclosing-server-info"></a>1. Disclosing server info</h2>
|
|
<p>
|
|
It is considered a safer behaviour not to disclose server information from your Chamilo page. In order to avoid
|
|
both web server and PHP information disclosure, you might want to take the following actions:
|
|
</p>
|
|
<ul>
|
|
<li>Locate the <i>ServerTokens</i> setting inside your Apache configuration and set it to "Prod"</li>
|
|
<li>Locate the <i>ServerSignature</i> setting inside your Apache configuration and set it to "Off"</li>
|
|
<li>Locate the <i>expose_php</i> setting inside your PHP configuration and set it to "Off"</li>
|
|
<li>Reload Apache</li>
|
|
</ul>
|
|
|
|
<h2><a id="2.Keeping-up-to-date"></a>2. Keeping up to date</h2>
|
|
<p>
|
|
Make sure you check <a href="https://support.chamilo.org/projects/chamilo-18/wiki/Security_issues">our security
|
|
issues page</a> from time to time.
|
|
You can also follow our security Twitter feed: <a href="https://twitter.com/chamilosecurity">https://twitter.com/chamilosecurity</a>.
|
|
</p>
|
|
|
|
<h2><a id="3.Using-safe-browsers"></a>3. Using safe browsers</h2>
|
|
<p> Additionally to lacking the implementation of features that really improve the quality of your browsing the
|
|
Internet, older browsers tend to have many unresolved security flaws. Using an old browser, you put in danger the
|
|
security of your computer and the data it contains, but you can also put others in danger by letting crackers take
|
|
control of it and attacking others.</p>
|
|
<p>To avoid being a risk to yourself and others, you should download and install a recent browser. We recommend
|
|
<a href="https://www.getfirefox.com" target="_blank" rel="noopener noreferrer">the latest stable version of Firefox</a>.</p>
|
|
|
|
<h2><a id="4.Moving-config-file"></a>4. Moving your configuration file out of the web directory</h2>
|
|
<p>It is considered unsafe to leave the configuration file inside the app/config/ directory, as it will be directly
|
|
accessible for all users, which could lead crackers to download it, uninterpreted, and read through your
|
|
configuration, which could lead to illicit
|
|
access to your database if that one isn't well protected and many other stuff we'd prefer to avoid. To secure it,
|
|
move the configuration file out of your web directory. If your Chamilo installation is in /var/www/, move your
|
|
configuration to /etc/chamilo/configuration.php, for example. Then create a new app/config/configuration.php
|
|
file, open it, and write the following:</p>
|
|
<pre>
|
|
<?php
|
|
require '/etc/chamilo/configuration.php';
|
|
</pre>
|
|
<p>
|
|
This will prevent direct access to your settings and make it seem totally the same to Chamilo.
|
|
</p>
|
|
|
|
<h2><a id="5.Files-permissions"></a>5. Restricting files permissions</h2>
|
|
<p>Making all the Chamilo files world-writable will help you install quickly, and it solves many
|
|
issues for people without much admin experience. However, it's more
|
|
secure to make a distinct user owner of all the chamilo files and folders,
|
|
and only give read access to the web server to all files, and write access
|
|
only to the directories previously mentioned.</p>
|
|
<p>This way, these files need
|
|
only be readable and writable by the Apache process owner, not by the
|
|
entire world. It would also be advisable to make all writable directory
|
|
refuse the interpretation of PHP files (except for the root of the courses
|
|
directories).</p>
|
|
<p>Don't hesitate to hire an experienced administrator to do that,
|
|
it might be a bit more expensive now, but you'll be happy not to have to lose
|
|
all of your data to a hacker who attacked your site.</p>
|
|
<p>Only the following directories have required (or optional) write
|
|
permissions from the web server:<br />
|
|
<ul>
|
|
<li>app/cache/</li>
|
|
<li>app/courses/</li>
|
|
<li>app/home/</li>
|
|
<li>app/logs/</li>
|
|
<li>app/upload/</li>
|
|
<li>main/default_course_document/images/</li>
|
|
<li>main/lang/ (optional, only for sublanguages)</li>
|
|
<li>web/css/ (optional, only for switching CSS through the web)</li>
|
|
</ul>
|
|
<br />
|
|
Because these directories have "write by the web server" permissions,
|
|
it is important to prevent the execution of PHP scripts from those
|
|
directories (because a specially-crafted attack could end up allowing
|
|
the upload of a PHP script to one of these). To do that, taking into
|
|
account we authorize overrides through .htaccess, we need to set
|
|
something that a .htaccess file cannot revert, and we need to set it
|
|
for each of those directories. This can be done as follows inside
|
|
your VirtualHost definition in Apache, where "/var/www/URL/" is the path of your VirtualHost web root:<br />
|
|
<pre>
|
|
<Directory /var/www/URL/app/cache>
|
|
php_admin_value engine Off
|
|
</Directory>
|
|
<Directory /var/www/URL/app/courses>
|
|
php_admin_value engine Off
|
|
</Directory>
|
|
<Directory /var/www/URL/app/home>
|
|
php_admin_value engine Off
|
|
</Directory>
|
|
<Directory /var/www/URL/app/logs>
|
|
php_admin_value engine Off
|
|
</Directory>
|
|
<Directory /var/www/URL/app/upload>
|
|
php_admin_value engine Off
|
|
</Directory>
|
|
<Directory /var/www/URL/app/Resources/public/css>
|
|
php_admin_value engine Off
|
|
</Directory>
|
|
<Directory /var/www/URL/main/default_course_document/images>
|
|
php_admin_value engine Off
|
|
</Directory>
|
|
<Directory /var/www/URL/main/lang>
|
|
php_admin_value engine Off
|
|
</Directory>
|
|
<Directory /var/www/URL/web/css>
|
|
php_admin_value engine Off
|
|
</Directory>
|
|
</pre>
|
|
|
|
For Nginx, this would look like the following rules. However, do
|
|
remember that Nginx interprets rules in order of appearance, so these
|
|
rules would have to be at the top of your location rules to take the
|
|
highest priority:
|
|
<pre>
|
|
location ~ ^/app/(cache|courses|home|logs|upload|Resources/public/css)/.*\.ph(p[3457]?|t|tml|ar)$ {
|
|
deny all;
|
|
}
|
|
location ~ ^/main/default_course_document/images/.*\.ph(p[3457]?|t|tml|ar)$ {
|
|
deny all;
|
|
}
|
|
location ~ ^/main/lang/.*\.ph(p[3457]?|t|tml|ar)$ {
|
|
deny all;
|
|
}
|
|
location ~ ^/web/css/.*\.ph(p[3457]?|t|tml|ar)$ {
|
|
deny all;
|
|
}
|
|
</pre>
|
|
<br />
|
|
<hr />
|
|
<h2><a id="6.HSTS">HTTP Headers Security</a></h2>
|
|
<p>A relatively recent development in web security, HTTP headers can be modified either
|
|
from the web server or from the application (like Chamilo) to increase the security
|
|
of your visitors.</p>
|
|
<p>These implies several aspects, from simple to complex, to deal with, from stuff like
|
|
indicating which websites you say media or libraries can be loaded from, to adding
|
|
extra info about your SSL certificate to make sure a hacked certification authority
|
|
will not immediately make your certificate useless.</p>
|
|
<p>In Chamilo 1.11.6, we have added several parameters, together with recommendations,
|
|
to main/install/configuration.dist.php, that you are free to use or ignore,
|
|
depending on the level of security you want to achieve.</p>>
|
|
<p>To check your portal for possible improvements in terms of headers security,
|
|
we highly recommend the <a href="https://securityheaders.io/">securityheaders.io</a>
|
|
website. If you want to read more about CSP and all related headers
|
|
security techniques, check <a href="https://scotthelme.co.uk/">Scott Helme's blog</a>.
|
|
</p>
|
|
<p>As per reported vulnerabilities #175 and #176 on
|
|
<a href="https://github.com/chamilo/chamilo-lms/wiki/security-issues">our Security Issues page</a>,
|
|
we highly recommend setting <em>$_configuration['security_content_policy']</em>, in particular for
|
|
elements like 'script-src', 'style-src' and 'form-action' to 'self' or to a limited number of trusted URLs.<br>
|
|
In particular, the social wall and the course chat spaces could be abused by some users to trick others
|
|
into filling forms that will send personal data to external sites. Letting users edit HTML is useful
|
|
but dangerous if you cannot trust people using these features. These features cannot be used by anonymous
|
|
users, but portals allowing for open registration could be particularly vulnerable.
|
|
</p>
|
|
<br />
|
|
<hr />
|
|
<h2><a id="7.Direct-web-access">Direct web access to files</a></h2>
|
|
<p>If .htaccess is enabled or the .htaccess rules are translated into the
|
|
web server vhost configuration (see installation guide for that), Chamilo
|
|
will do some natural files access protection.<br />
|
|
<br />
|
|
This protection is executed through redirections of some URLs to make the
|
|
request go through some kind of permissions validation script. For
|
|
documents, this means going through the main/document/download.php script,
|
|
but there are some more specific rules (see .htaccess for details).<br />
|
|
<br />
|
|
While this does a great job to avoid access by unprivileged users, this
|
|
also creates an efficiency issue, whereby some files, in version 1.11, can
|
|
take up to 5 times the load time when it goes through the permissions
|
|
validation.<br />
|
|
<br />
|
|
Because of that, we have taken some decisions to reduce the impact in a
|
|
reasonable way. For example, static files in SCORM content
|
|
(in courses/[code]/scorm/) like CSS, JS, PNG, JPG and GIF are *not* scanned
|
|
this way (there is an exception for that). We believe that these resources
|
|
do not contain confidential information. If you *DO* have confidential
|
|
information in images, CSS or JavaScript files, you will need to update
|
|
these rules to suit your needs.<br />
|
|
<br />
|
|
<h3>Access to "personal" files</h3>
|
|
In Chamilo 1.*, it is possible to upload files to one's "personal" folder
|
|
through the social network page, or through any upload popup that allows
|
|
you to choose the file destination (and you select your personal folder).<br />
|
|
<br />
|
|
Due to the development background in Chamilo, these files are then directly
|
|
accessible by anonymous users, which can lead to personal data leaks. This
|
|
has been left in this mode by default because many teacher users had used
|
|
this option to share common images between different courses and blocking
|
|
the feature would have meant public courses would not have shown the given
|
|
images.<br />
|
|
<br />
|
|
To avoid this issue and make files accessible *only* to authenticated users,
|
|
please set the following option to 'true' in configuration.php:<br />
|
|
<br />
|
|
<pre>
|
|
$_configuration['block_my_files_access'] = true;</pre>
|
|
This will prevent anonymous access, but will not prevent access from other
|
|
authenticated users.
|
|
</p>
|
|
|
|
<h2><a id="8.Disable-webservices">Disable webservices</a></h2>
|
|
<p>
|
|
In order to disable webservices add the configuration below:
|
|
<pre>
|
|
$_configuration['disable_webservices'] = true;
|
|
</pre>
|
|
</p>
|
|
|
|
<h2><a id="9.Change-password-first-login">Change password on first login</a></h2>
|
|
<p>
|
|
To force users to change their password on their first login, add the configuration below:
|
|
<pre>
|
|
$_configuration['force_renew_password_at_first_login'] = true;
|
|
</pre>
|
|
and add the 'ask_new_password' checkbox extra field to users.
|
|
</p>
|
|
|
|
<h2><a id="10.Hide-breadcrumb">Hide breadcrumb on unauthorized page load</a></h2>
|
|
<p>
|
|
To hide the breadcrumb on pages with the "not allowed" error message, add the configuration below:
|
|
<pre>
|
|
$_configuration['hide_breadcrumb_if_not_allowed'] = true;
|
|
</pre>
|
|
</p>
|
|
|
|
<h2><a id="11.SVG-and-XSS">SVG and XSS</a></h2>
|
|
<p>
|
|
SVG files and HTML files containing inline SVG are vulnerable to XSS attacks. This is a general fact, not
|
|
immediately related to Chamilo, but that can affect it.<br />
|
|
As a general rule of thumb, you should not let your portal open to unauthenticated people, and you should not
|
|
allow unknown or unreliable people to upload content to your portal.<br />
|
|
But in case you do, or accesses of reliable people get stolen and abused, you might want to take precautions to
|
|
avoid as much as possible giving the tools to crackers, to damage your portal's reputation.<br />
|
|
The following are a series of measures you can take to reduce the risk to the maximum when talking about the
|
|
combination of SVG and XSS.<br />
|
|
<ul>
|
|
<li>Disable the SVG editor, in the platform settings</li>
|
|
<li>In the security section of the platform settings, filter the SVG extension (either through putting it in the blacklist or removing it from the whitelist)</li>
|
|
<li>Make sure <em>$_configuration['course_introduction_html_strict_filtering'] = true;</em> is commented or is set to true in your configuration.php file</li>
|
|
<li>Do not make courses "public" if they include student-contributed content</li>
|
|
<li>Define some Content Security Policies ('security_content_policy') in your configuration.php file</li>
|
|
<li>Define some XSS Protection clause ('security_xss_protection') in your configuration.php file</li>
|
|
</ul>
|
|
</p>
|
|
|
|
<h2>Authors</h2>
|
|
<ul>
|
|
<li>Yannick Warnier, Chamilo Project Leader, Zend Certified PHP Engineer, BeezNest Belgium SPRL,
|
|
<a href="mailto:yannick.warnier@beeznest.com">yannick.warnier@beeznest.com</a></li>
|
|
</ul>
|
|
</div>
|
|
</body>
|
|
</html>
|
|
|