TomaHost/Chamilo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

upgrade

Browse Source
This commit is contained in:
Xes
2025-08-14 22:37:11 +02:00
parent 1c9e806972
commit fb6d5d5926
14 changed files with 24674 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

290
documentation/security.html Normal file
View File

@@ -0,0 +1,290 @@
<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> &gt; 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>
&lt;?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>
&lt;Directory /var/www/URL/app/cache&gt;
php_admin_value engine Off
&lt;/Directory&gt;
&lt;Directory /var/www/URL/app/courses&gt;
php_admin_value engine Off
&lt;/Directory&gt;
&lt;Directory /var/www/URL/app/home&gt;
php_admin_value engine Off
&lt;/Directory&gt;
&lt;Directory /var/www/URL/app/logs&gt;
php_admin_value engine Off
&lt;/Directory&gt;
&lt;Directory /var/www/URL/app/upload&gt;
php_admin_value engine Off
&lt;/Directory&gt;
&lt;Directory /var/www/URL/app/Resources/public/css>
php_admin_value engine Off
&lt;/Directory&gt;
&lt;Directory /var/www/URL/main/default_course_document/images&gt;
php_admin_value engine Off
&lt;/Directory&gt;
&lt;Directory /var/www/URL/main/lang&gt;
php_admin_value engine Off
&lt;/Directory&gt;
&lt;Directory /var/www/URL/web/css&gt;
php_admin_value engine Off
&lt;/Directory&gt;
</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>
<p>The inline editor in Chamilo 1.11 requires
the Content Security Policy (CSP) headers to include 'unsafe-inline' and 'unsafe-eval'. This is because the
editor includes a number of complex features that require those accesses. This means that your Chamilo install
will probably not validate as an "A+" score in standard CSP tests. We have no solution for this except to
prevent users from using the inline editor, which would remove a considerable level of usability from Chamilo.</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>