Note: You are currently viewing documentation for Moodle 3.7. Up-to-date documentation for the latest stable version of Moodle may be available here: Security FAQ.

Security FAQ: Difference between revisions

From MoodleDocs
(Which versions are supported?)
(de inter-wiki link)
 
(30 intermediate revisions by 6 users not shown)
Line 1: Line 1:
==How can I report a security issue?==
{{Security}}
==How do I report a security issue?==


Please "Create a new issue" in the [http://tracker.moodle.org Moodle Tracker] describing the problem (and solution if possible) in detail. Make sure you set the Security Level accurately to make sure that the security team sees it. Bugs classified as a "Serious security issue" will be hidden from the general public until the security team (led by Petr Skoda) is able to resolve it and publish fixes to registered Moodle sites (see below).
See [[:dev:Moodle security procedures|Moodle security procedures]] in the dev docs for details on how to report a security issue.
 
Previously fixed security issues are listed in the [http://moodle.org/security/ Moodle.org Security news]. If you are unsure whether a problem has been fixed or not, it's best to report it anyway.


==How can I keep my site secure?==
==How can I keep my site secure?==


* The usual way is to update your whole Moodle to the latest stable release of the version you are using. It is very safe to go from 1.8.1 to 1.8.2+, for example, at any time. [[CVS for Administrators|CVS]] is a very easy way to do this.
It's good practice to always use the latest stable release of the version you are using. It is safe to upgrade to a more recent version on the branch you are using, say from Moodle 2.X.1 to the latest version on the 2.X branch. [[Git for Administrators|Downloading via Git]] makes it very easy way to do this.
* Many of the notices will include patch information. If you are fairly confident with editing scripts, then it may be easier for you to just patch the affected file.


==How can I keep track of recent security issues?==
==How do I keep track of recent security issues?==


* Register your [http://moodle.org/sites Moodle sites] with moodle.org (visit admin/index.php in your installation to see the registration button), making sure to enable the option of being notified about security issues and updates. After your registration is accepted, your email address will be automatically added to our low-volume securityalerts mailing list.
* [[Site registration | Register your Moodle site with moodle.org]], making sure to enable the option of being notified about security issues and updates. After your registration is accepted, your email address will be automatically added to our low-volume security alerts mailing list.


* Eventually, all important security issues are published to the general public via the [http://moodle.org/mod/forum/view.php?f=996 Moodle Security forum]. You can subscribe to the [http://moodle.org/rss/file.php/1/1/forum/996/rss.xml forum RSS feed] to automatically add new issues in your favourite feed reader or portal.
* Eventually, all important security issues are published to the general public via the [http://moodle.org/mod/forum/view.php?f=996 Moodle Security forum]. You can subscribe to the forum or [http://twitter.com/moodlesecurity follow moodlesecurity on Twitter].


==Which versions are supported?==
==Who is able to view security issues in the Tracker?==


* All versions available for download from [http://download.moodle.org/ download.moodle.org] (1.6, 1.7, 1.8 and 1.9) are supported.
Depending upon the security level of a Tracker issue, access is restricted to developers, testers or members of the security team. Specific details are available in the [[dev:Tracker guide#When_creating_an_issue|Security Level field description in the Tracker guide]].
* The latest development branch of Moodle is not intended for production use and while security problems are fixed, security announcements are not issued. If you are using the development branch for testing or evaluation, we assume that you will update your code regularly.
 
* Our security officer Petr Škoda oversees the security of the code found in the standard Moodle distribution. The security of contributed code lies with the individual maintainers.  
==Which versions of Moodle are supported?==
 
Currently supported versions are listed on [http://download.moodle.org/ download.moodle.org].
 
==My site was hacked. What do I do?==
 
See [[Hacked site recovery]].


==How can I reduce spam in Moodle?==
==How can I reduce spam in Moodle?==


See [[Reducing spam in Moodle]].
See [[Reducing spam in Moodle]].
==How can I increase privacy in Moodle?==
See [[Increasing privacy in Moodle]].
==How do I enable reCAPTCHA?==
To add spam protection to the [[Email-based self-registration]] new account form with a CAPTCHA element:
#Obtain a reCAPTCHA key from http://recaptcha.net by [https://admin.recaptcha.net/accounts/signup/?next= signing up for an account] (free) then entering a domain.
#Copy and paste the public and private keys provided into the ''recaptchapublickey'' and ''recaptchaprivatekey'' fields in the manage authentication common settings in ''Administration > Plugins > Authentication > [[Manage authentication]]''.
#Click the "Save changes" button at the bottom of the page.
#Follow the settings link for email-based self-registration in ''Administration > Plugins > Authentication > Manage authentication'' and enable the reCAPTCHA element.
#Click the "Save changes" button at the bottom of the page.
==How can I run the security overview report?==
To run the [[Security overview|security overview report]], go to ''Administration > Site administration > Reports > Security overview''.
== I have discovered Cross Site Scripting (XSS) is possible with Moodle ==
Some forms of rich content used by teachers to enhance their courses use the same technologies that malicious users can use for cross-site scripting attacks. If Moodle was solely concerned with security, it would not allow this. However, Moodle is also concerned with education and so a balance has to be struck between securing the system and supporting teachers with their needs.
In order to strike a balance between authoring rich educational content and securing the system, access to post XSS-capable content is controlled by capabilites flagged with the 'XSS risk' - see [[Risks]]. In general this means that admins and teachers can post XSS-capable content, but students can not - see [[XSS_trusted_users]].
Occasionally security bugs are discovered in Moodle's handling of XSS capable content and we are greatful to the community for reporting these through [https://docs.moodle.org/dev/Moodle_security_procedures responsible disclosure].  Before reporting an XSS bug to Moodle, please ensure that the user posting the XSS content does not have capabilities flagged with the XSS risk.


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


*[[Security]]
* Using Moodle [http://moodle.org/mod/forum/view.php?id=7301 Security and Privacy forum]


[[Category:FAQ]]
[[Category:FAQ]]
[[Category:Security]]
 
[[de:Sicherheit FAQ]]
[[es:Seguridad FAQ]]
[[fr: FAQ sur la sécurité]]

Latest revision as of 16:21, 23 January 2020

How do I report a security issue?

See Moodle security procedures in the dev docs for details on how to report a security issue.

Previously fixed security issues are listed in the Moodle.org Security news. If you are unsure whether a problem has been fixed or not, it's best to report it anyway.

How can I keep my site secure?

It's good practice to always use the latest stable release of the version you are using. It is safe to upgrade to a more recent version on the branch you are using, say from Moodle 2.X.1 to the latest version on the 2.X branch. Downloading via Git makes it very easy way to do this.

How do I keep track of recent security issues?

  • Register your Moodle site with moodle.org, making sure to enable the option of being notified about security issues and updates. After your registration is accepted, your email address will be automatically added to our low-volume security alerts mailing list.

Who is able to view security issues in the Tracker?

Depending upon the security level of a Tracker issue, access is restricted to developers, testers or members of the security team. Specific details are available in the Security Level field description in the Tracker guide.

Which versions of Moodle are supported?

Currently supported versions are listed on download.moodle.org.

My site was hacked. What do I do?

See Hacked site recovery.

How can I reduce spam in Moodle?

See Reducing spam in Moodle.

How can I increase privacy in Moodle?

See Increasing privacy in Moodle.

How do I enable reCAPTCHA?

To add spam protection to the Email-based self-registration new account form with a CAPTCHA element:

  1. Obtain a reCAPTCHA key from http://recaptcha.net by signing up for an account (free) then entering a domain.
  2. Copy and paste the public and private keys provided into the recaptchapublickey and recaptchaprivatekey fields in the manage authentication common settings in Administration > Plugins > Authentication > Manage authentication.
  3. Click the "Save changes" button at the bottom of the page.
  4. Follow the settings link for email-based self-registration in Administration > Plugins > Authentication > Manage authentication and enable the reCAPTCHA element.
  5. Click the "Save changes" button at the bottom of the page.

How can I run the security overview report?

To run the security overview report, go to Administration > Site administration > Reports > Security overview.

I have discovered Cross Site Scripting (XSS) is possible with Moodle

Some forms of rich content used by teachers to enhance their courses use the same technologies that malicious users can use for cross-site scripting attacks. If Moodle was solely concerned with security, it would not allow this. However, Moodle is also concerned with education and so a balance has to be struck between securing the system and supporting teachers with their needs.

In order to strike a balance between authoring rich educational content and securing the system, access to post XSS-capable content is controlled by capabilites flagged with the 'XSS risk' - see Risks. In general this means that admins and teachers can post XSS-capable content, but students can not - see XSS_trusted_users.

Occasionally security bugs are discovered in Moodle's handling of XSS capable content and we are greatful to the community for reporting these through responsible disclosure. Before reporting an XSS bug to Moodle, please ensure that the user posting the XSS content does not have capabilities flagged with the XSS risk.

See also