Note: You are currently viewing documentation for Moodle 3.3. Up-to-date documentation for the latest stable version of Moodle is probably available here: Security overview report.

Security overview report: Difference between revisions

From MoodleDocs
(report available in 1.8.9)
(formatting, links to further documentation)
Line 1: Line 1:
{{Moodle 1.8}}Location: ''Administration > Reports > Security overview''
{{Moodle 1.8}}Location: ''Administration > Reports > Security overview''


The security overview report is available in Moodle 1.8.9 and 1.9.4 onwards.
The security overview report is available in Moodle 1.8.9 and 1.9.4 onwards.
[[Image:Security overview.png|thumb|right|Security overview]]
[[Image:Security overview.png|thumb|right|Security overview]]
===Register globals===
register_globals is a PHP setting that must be disabled for Moodle to operate safely.
===Insecure dataroot===
The dataroot is the directory where Moodle stores user files.  It should not be directly accessible via the web.
===Displaying of PHP errors===
If PHP is set to display errors, then anyone can enter a faulty URL causing PHP to give up valuable information about directory structures and so on.
===No authentication===
Use of the "no authentication" plugin can be dangerous, allowing people to access the site without authenticating.
===Allow EMBED and OBJECT===
Allowing ordinary users to embed Flash and other media in their texts (eg forum posts) can be a problem because those rich media objects can be used to steal admin or teacher access, even if the media object is on another server.
===Enabled .swf media filter===
Even the flash media filter can be abused to include malicious flash files.
===Open user profiles===
User profiles should not be open to the web without authentication, both for privacy reasons and because spammers then have a platform to publish spam on your site.
===Open to Google===
Allowing Google to enter your site means that all the contents become available to the world.  Don't use this unless it's a really public site.
===Password policy===
Using a password policy will force your users to use stronger passwords that are less susceptible to being cracked by a intruder.


===Email change confirmation===


You should generally always force users to confirm email address changes via an extra step where a confirmation link is sent to the user.
*[[report/security/report security check globals|Register globals]]
:register_globals is a PHP setting that must be disabled for Moodle to operate safely.


===Writable config.php===
*[[report/security/report security check unsecuredataroot|Insecure dataroot]]
:The dataroot is the directory where Moodle stores user files.  It should not be directly accessible via the web.


The config.php file must not be writeable by the web server process.  If it is, then it is possible for another vulnerability to allow attackers to rewrite the Moodle code and display whatever they want.
*[[report/security/report security check displayerrors|Displaying of PHP errors]]
:If PHP is set to display errors, then anyone can enter a faulty URL causing PHP to give up valuable information about directory structures and so on.


===XSS trusted users===
*[[report/security/report security check noauth|No authentication]]
:Use of the "no authentication" plugin can be dangerous, allowing people to access the site without authenticating.


Make sure that you trust all the people on this list: they are the ones with permissions to potentially write XSS exploits in forums etc. See the Using Moodle discussion [http://moodle.org/mod/forum/discuss.php?d=115805 How to fix XSS trusted users problem] for further details.
*[[report/security/report security check embed|Allow EMBED and OBJECT]]
:Allowing ordinary users to embed Flash and other media in their texts (eg forum posts) can be a problem because those rich media objects can be used to steal admin or teacher access, even if the media object is on another server.


===Administrators===
*[[report/security/report security check mediafilterswf‎|Enabled .swf media filter]]
:Even the flash media filter can be abused to include malicious flash files.


Review your administrator accounts and make sure you only have what you need.
*[[report/security/report security check openprofiles|Open user profiles]]
:User profiles should not be open to the web without authentication, both for privacy reasons and because spammers then have a platform to publish spam on your site.


===Registered user role===
*[[report/security/report security check google|Open to Google]]
:Allowing Google to enter your site means that all the contents become available to the world.  Don't use this unless it's a really public site.


This checks that the registered user role is defined with sane permissions.
*[[report/security/report security check passwordpolicy|Password policy]]
:Using a password policy will force your users to use stronger passwords that are less susceptible to being cracked by a intruder.


===Guest role===
*[[report/security/report security check emailchangeconfirmation‎|Email change confirmation]]
:You should generally always force users to confirm email address changes via an extra step where a confirmation link is sent to the user.


This checks that the guest role is defined with sane permissions.
*[[report/security/report security check configrw|Writable config.php]]
:The config.php file must not be writeable by the web server process.  If it is, then it is possible for another vulnerability to allow attackers to rewrite the Moodle code and display whatever they want.


===Frontpage role===
*[[report/security/report security check riskxss|XSS trusted users]]
:Make sure that you trust all the people on this list:  they are the ones with permissions to potentially write XSS exploits in forums etc.


This checks that the frontpage user role is defined with sane permissions.
*[[report/security/report security check riskadmin|Administrators]]
:Review your administrator accounts and make sure you only have what you need.


===Default course role (global)===
*[[report/security/report security check defaultuserrole‎ |Registered user role]]
:This checks that the registered user role is defined with sane permissions.


This checks that the default course role globally is defined with sane permissions.
*[[report/security/report security check guestrole|Guest role]]
:This checks that the guest role is defined with sane permissions.


===Default roles (courses)===
*[[report/security/report security check frontpagerole‎|Frontpage role]]
:This checks that the frontpage user role is defined with sane permissions.


This check alerts you if any courses are using an odd default course role.
*[[report/security/report security check defaultcourserole|Default course role (global)]]
:This checks that the default course role globally is defined with sane permissions.


*[[report/security/report security check courserole‎|Default roles (courses)]]
:This check alerts you if any courses are using an odd default course role.


==See also==
==See also==

Revision as of 14:40, 16 February 2009

Template:Moodle 1.8Location: Administration > Reports > Security overview

The security overview report is available in Moodle 1.8.9 and 1.9.4 onwards.

Security overview


register_globals is a PHP setting that must be disabled for Moodle to operate safely.
The dataroot is the directory where Moodle stores user files. It should not be directly accessible via the web.
If PHP is set to display errors, then anyone can enter a faulty URL causing PHP to give up valuable information about directory structures and so on.
Use of the "no authentication" plugin can be dangerous, allowing people to access the site without authenticating.
Allowing ordinary users to embed Flash and other media in their texts (eg forum posts) can be a problem because those rich media objects can be used to steal admin or teacher access, even if the media object is on another server.
Even the flash media filter can be abused to include malicious flash files.
User profiles should not be open to the web without authentication, both for privacy reasons and because spammers then have a platform to publish spam on your site.
Allowing Google to enter your site means that all the contents become available to the world. Don't use this unless it's a really public site.
Using a password policy will force your users to use stronger passwords that are less susceptible to being cracked by a intruder.
You should generally always force users to confirm email address changes via an extra step where a confirmation link is sent to the user.
The config.php file must not be writeable by the web server process. If it is, then it is possible for another vulnerability to allow attackers to rewrite the Moodle code and display whatever they want.
Make sure that you trust all the people on this list: they are the ones with permissions to potentially write XSS exploits in forums etc.
Review your administrator accounts and make sure you only have what you need.
This checks that the registered user role is defined with sane permissions.
This checks that the guest role is defined with sane permissions.
This checks that the frontpage user role is defined with sane permissions.
This checks that the default course role globally is defined with sane permissions.
This check alerts you if any courses are using an odd default course role.

See also

Retrieved from "https://docs.moodle.org/33/en/index.php?title=Security_overview_report&oldid=50985"
Powered by MediaWiki