MoodleDocs - Användarbidrag [sv]

report/security/report security check preventexecpath

2021-08-25T03:09:56Z

Michaelh2: Small layout tweak.

{{Security overview report}}Some administration options allow setting the path to executable files on the web server such as du, aspell, ghostscript and others. This can potentially cause a security risk. You can prevent administrators from changing these paths by adding the following setting to your config.php file:

<code php>
$CFG->preventexecpath = true;
</code>

You should also explicitly set the relevant paths in your config.php file such as:
<code php>
$CFG->pathtodu = 'PATH';
$CFG->pathtounoconv = 'PATH';
$CFG->aspellpath = 'PATH';
</code>

[[es:report/security/report security check preventexecpath]]

Site security settings

2021-06-02T06:12:02Z

Michaelh2:

.
{{Security}}
===Protect usernames===

If enabled, when a user attempts to reset their password and enters a username or email address, the following message is displayed: "If you supplied a correct username or email address then an email should have been sent to you." This is to prevent a malicious party from using the interface to determine which usernames and email addresses are in use in valid accounts.

If the protect usernames setting is disabled, when a user attempts to reset their password they are provided with feedback regarding whether an account exists with the username or email address supplied. For example, the message "The email address was not found in the database" may be displayed.

===Force users to login===

If you turn this setting on, all users must login before they even see the [[Front Page]] of the site. Note however that this does not prevent guest access to courses, if you have autologin guests enabled in [[User policies]].

===Force users to login for profiles===

Leave this set to Yes to keep anonymous visitors away from user profiles.

===Force users to login to view user pictures===

If enabled, users must login in order to view user profile pictures and the default user picture will be used in all notification emails.

===Open to search engines===

Enabling this setting allows search engines crawlers guest access to your site. Any part of the site that allows guest access will then be searchable on search engines. In addition, people coming in to your site via a search engine search will automatically be logged in as a guest.

=== Referrer policy ===

A referrer policy can be set, various parts of moodle rely on the referrer being set so it's generally best to only remove or reduce the referrer for external links. So a policy of origin-when-cross-origin is probably the best balance.
See the MDN docs for more details:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

===Allow indexing by search engines===
This determines whether to allow search engines to index your site. The default is Everywhere except login and signup pages.

===Profile visible roles===
Any role which is checked/ticked here will be visible on user profiles and the Participation screen.

===Maximum uploaded file size===

Probably the most frequently asked question in the Moodle.org Using Moodle forums is "How do I increase the upload file size limit?"

Upload file sizes are restricted in a number of ways - each one in this list restricts the following ones:

1. The Apache server setting LimitRequestBody ... default in Apache 2.x or greater is set to 0 or an unlimited upload size

2. The PHP site settings post_max_size and upload_max_filesize in php.ini : '''modify php.ini in web server directories''' ( apache2.x.x/bin/php.ini ) not in php directories :

post_max_size = 128M; to increase limit to 128 Megabytes;
upload_max_filesize = 128M; to increase limit to 128 Megabytes;
max_execution_time = 600 ; Maximum execution time of each script, in seconds;

3. The Moodle site-wide maximum uploaded file size setting: ''Settings > Site administration > Security > Site policies > Maximum uploaded file size''.

4. The Moodle course maximum uploaded file size setting in the course default settings: ''Settings > Site administration > Courses > Course default settings''

5. The file size settings in each individual course in ''Course Administration>Settings''.

5. Certain course activity module settings (for example, Assignment)

* See [[File upload size]] for more details.

===User quota===

The maximum number of bytes that a user can store in their own [[Private files]] area.

===Allow EMBED and OBJECT tags===
Allowing these presents a security risk but if you wish normal users such as students to be able to use them then check the box here.

===Enable trusted content===

By default Moodle will always thoroughly clean text that comes from users to remove any possible bad scripts, media etc that could be a security risk. The Trusted Content system is a way of giving particular users that you trust the ability to include these advanced features in their content without interference. To enable this system, you need to first enable this setting, and then grant the [[Capabilities/moodle/site:trustcontent|Trust submitted content]] capability to a specific Moodle role. Texts created or uploaded by such users will be marked as trusted and will not be cleaned before display.

===Maximum time to edit posts===

This sets the editing time for forum postings. The editing time is the amount of time users have to change forum postings before they are mailed to subscribers.

Please refer to the forum discussions [http://moodle.org/mod/forum/discuss.php?d=28679 Editing a forum post after the 30 minutes deadline] and [http://moodle.org/mod/forum/discuss.php?d=5367 The philosophy underlying "no editing after 30 minutes"]

===Full name format===

This setting has been moved in Moodle 2.6 onwards to ''Administration > Site administration > Users > Permissions > [[Roles settings|User policies]]''.

===Allow extended characters in usernames===

The default here, unchecked = unenabled, can only contain alphabetical letters in lowercase, numbers, hypen '-', underscore '_', period '.', or at sign '@'. If you enable this, it will be possible to have any characters for the username, but they must still be lowercase. This setting would allow you for example to have usernames with accents such as ö or ê and so on.

Note: In Moodle 3.4.2 onwards, the Site policy URL and Site policy URL for guests settings have been moved to 'Policy settings' in the Site administration.

===Keep tag name casing===

If checked, then tags like the following will be displayed: SOCCER, gUiTaR, MacDonalds, music

If unchecked, then all tags will be displayed as follows: Soccer, Guitar, Macdonalds, Music

:''Tips'':
:* For English, off is useful.
:* For Japanese, no changes are made either way.
:* For languages where this kind of capitalization changes the meaning, it is best to keep this option on.

===Profiles for enrolled users only===

To prevent misuse by spammers, profile descriptions of users who are not yet enrolled in any course are hidden. New users must enrol in at least one course before they can add a profile description.

===Cron execution via command line only===

[[Cron]] is an action that runs various administrative jobs on your Moodle such as sending out forum posts. Running the cron from a web browser can expose privileged information to anonymous users. Thus it is recommended to only run the cron from the command line or set a cron password for remote access.

===Cron password for remote access===

Setting a password will mean that users can only run cron from the browser if they know the password and add it like this:
www.YOURMOODLE.com/admin/cron.php/?password=THEPASSWORDYOUSET.

===Account lockout===

Account lockout may be enabled.

Account lockout threshold: After a specified number of failed login attempts, a user's account is locked and they are sent an email containing a URL to unlock the account. Setting this to 'No' means there is no threshold and an account attempting to log in can do so an unlimited number of times.

Account lockout observation window: Observation time for lockout threshold, if there are no failed attempts the threshold counter is reset after this time. This is the counter for how long to watch for more failed attempts by an account trying to log in even after being locked out, the counter will reset at each attempt and last this long.

Account lockout duration: Locked out account is automatically unlocked after this duration.

The account may also be unlocked by an administrator in ''Administration > Site administration > Users > Accounts > Browse list of users'' or by waiting for the account lockout duration to elapse.

===Password policy===

It is highly recommended that a password policy is set to force users to use stronger passwords that are less susceptible to being cracked by a intruder.
[[Image:Password policy.png|thumb|Password policy]]

The password policy includes option to set the minimum length of the password, the minimum number of digits, the minimum number of lower-case characters, the minimum number of upper-case characters and the minimum number of non alphanumeric characters.

The password policy is enabled by default. Default (recommended) settings are:
* Password length - 8
* Digits - 1
* Lowercase letters - 1
* Uppercase letters - 1
* Non-alphanumeric characters - 1

If a user enters a password that does not meet the requirements, they are given an error message indicating the nature of the problem with the entered password.

Enabling the password policy does not affect existing users until they decide to or are required to change their password. An admin can force all users to change their password using the force password change option in [[Bulk user actions]].

:''Tip'': The password policy may also be applied to [[Enrolment key|enrolment keys]] by ticking the 'Use password policy' checkbox in the [[Self enrolment]] settings.

===Password rotation limit===

Here you can specify how often a user must change their password before they can re-use a previous password. Note that this might not work with some external authentication plugins.

===Log out after password change===

By default, users can change their password and remain logged in. Enabling this setting will log them out of existing sessions except the one in which they specify their new password. This setting only applies to users manually changing their password, not to bulk password changes.

===User created token duration===

A new setting in Moodle 3.4 onwards enables the duration of a web services token created by a user (for example via the mobile app) to be set. (Previously the duration was 3 months and this value could not be changed.)

===Group enrolment key policy===
If this is enabled then when a teacher sets a group enrolment key, they will have to set a key which follows the password policy set above. Note that the group enrolment key policy requires the password policy to be enabled.

===Disable user profile images===

Check/tick this box if you don't want your users to be able to change their [[User pictures|profile images]].

===Email change confirmation===

A confirmation step is required for users to change their email address unless the ''emailchangeconfirmation'' box is unchecked.

===Remember username===
If you want usernames to be stored during login then set this to "yes". This will store permanent cookies and in some countries may be considered a privacy issue if used without consent. From a UK point of view, see http://tracker.moodle.org/secure/attachment/24290/UK+Laws+Relating+to+Cookies-LUNS2011.pdf See also the Using Moodle forum discussion [http://moodle.org/mod/forum/discuss.php?d=201558 EU Cookie Law].

===Strict validation of required fields===
If enabled, users are prevented from entering a space or line break only in required fields in forms. (note: add more info)

==See also==
* [[Policies plugin]] - The Policies plugin provides a new user sign-on process, with ability to define multiple policies (site, privacy, third party), track user consents, and manage updates and versioning of the policies

[[es:Políticas del sitio]]
[[eu:Gunearen_politikak]]
[[fr:Règles site]]
[[ja:サイトポリシー]]
[[de:Sicherheitsregeln der Website]]

Security recommendations

2021-05-20T09:50:42Z

Michaelh2: /* See also */

{{Security}}All web application software is highly complex, and every application has security issues that are found from time to time, usually involving some combination of input that the programmers did not anticipate. The Moodle project takes security seriously, and is continuously improving Moodle to close such holes as we find them.

==Introduction==
*This page contains important security measures for your Moodle installation.
*You should report security problems to the [http://tracker.moodle.org/secure/CreateIssue!default.jspa Moodle tracker] (and mark it as a security issue!) so that developers can see it and inform registered Moodle sites about fixes as soon as possible.
*You should not post actual exploits in the forums or elsewhere on the web (to protect Moodle admins who have not upgraded yet).

==Simple security measures==
*The best security strategy is a good backup! But you don't have a good backup unless you are able to restore it. Test your restoration procedures!
*Load only software or services you will use
*Perform regular updates
*Model your security after the layers of clothing you wear on a cold winter day

==Basic recommendations==

;Update Moodle regularly on each release
:Published security holes draw crackers' attention after release. The older the version, the more vulnerabilities it is likely to contain.
; Use https to secure all pages (not just the login page)
:Protect all traffic from your Moodle instance and your users by making all pages accessible via https only. This not only protects passwords on login but also ensures the privacy of your users so that all user data cannot be intercepted or manipulated ("ad injections") from third parties like WLAN providers for example. Free https certificates are available from https://letsencrypt.org/. In addition, set httpslogin=yes in your moodle config to add an extra layer of protection for submitting login credentials.
;[[admin/environment/custom check/php check register globals|Register globals '''MUST''' be disabled]]
:This will help prevent against possible XSS problems in third-party scripts.
;Run the [[Security_overview_report|Security Overview Report]]
:This identifies various configurations within your Moodle site that may pose a security risk, so any issues raised by that report should be investigated and action taken if necessary.
;Use strong passwords for admin and teachers
:Choosing "difficult" passwords is a basic security practice to protect against "brute force" cracking of accounts.
;Only give teacher accounts to trusted users. Avoid creating public sandboxes with free teacher accounts on production servers.
:Teacher accounts have much more liberal permissions and it is easier to create situations where data can be abused or stolen.
;Separate your systems as much as possible
:Another basic security technique is to use different passwords on different systems, use different machines for different services and so on. This will prevent damage being widespread even if one account or one server is compromised.

==Run regular updates==
*Use auto update systems
*Windows Update
*Linux: up2date, yum, apt-get
:Consider automating updates with a script scheduled via cron
*Mac OSX update system
*Stay current with php, apache, and moodle

==Use mailing lists to stay updated==
*CERT - http://www.us-cert.gov/cas/signup.html
*PHP - http://www.php.net/mailing-lists.php - sign up for Announcements list
*MySQL - http://lists.mysql.com - sign up for MySQL Announcements

==Firewalls==
*Security experts recommend a dual firewall
:Differing hardware/software combinations
*Disabling unused services is often as effective as a firewall
:Use netstat -a to review open network ports
*Not a guarantee of protection
*Allow ports
:80, 443(ssl), and 9111 (for chat),
:Remote admin: ssh 22, or rdp 3389

==Password policy==

A password policy may be set up in ''Settings > Site administration > Security > [[Site policies]]''.

There is a check box to determine if password complexity should be enforced or not, the option to set the minimum length of the password, the minimum number of digits, the minimum number of lowercase characters, the minimum number of uppercase characters and the minimum number of non alphanumeric characters.

If a user enters a password that does not meet those requirements, they are given an error message indicating the nature of the problem with the entered password.

Enforcing password complexity along with requiring users to change their initial password go a long way in helping ensure that users choose and are in fact using "good passwords".

However, making the check too onerous just results in them writing it down so be realistic.

==Be prepared for the worst==
*Have backups ready
*Practice recovery procedures ahead of time
*Use a rootkit detector on a regular basis
**Linux/MacOSX - http://www.chkrootkit.org/
**Windows - http://technet.microsoft.com/en-en/sysinternals/bb897445.aspx and http://technet.microsoft.com/de-de/sysinternals/bb897445.aspx

==Moodle security alerts==
*Register your site with Moodle.org
:Registered users receive email alerts
*Security alerts also posted online
*Web - http://moodle.org/security
*RSS feed - http://moodle.org/rss/file.php/1/1/forum/996/rss.xml

==Miscellaneous considerations==
These are all things you might consider that impact your overall security:
*Use the secure forms setting
*Always set a mysql root user password
*Turn off mysql network access
*Use SSL, httpslogins=yes
*Use good passwords - set up a password policy in ''Settings > Site administration > Security > [[Site policies]]''
*Do not enable the ''opentowebcrawlers'' setting (in ''Settings > Site administration > Security > [[Site policies]]'')
*Disable guest access
*Place enrollment keys on all courses or set Course Enrollable = No for all courses
*Ensure the enrolment key hint is disabled (which it is by default) in ''Administration > Site administration > Plugins > Enrolment > Self enrolment.''

==Most secure/paranoid file permissions==

'''Note''': <u>The following information applies to Linux/Unix based installations only, as MS Windows permission system is quite different</u>.

Depending on your server set-up there are two different scenarios:
# You are running Moodle on your own dedicated server.
# You are running Moodle on a shared hosting environment.

In the sections below, you are required to use the web service user account and group to set the permissions, so you need to know them. This can vary quite a bit from server to server but if this feature has not been disabled in your server, you can go to ''<nowiki>http://your.moodle.site/admin/phpinfo.php</nowiki>'' (logging in as admin), and then search for the line that reads 'User/Group', inside the 'apache' table. For example, I get 'www-data' for the user account and 'www-data' for the group too.

=== Running Moodle on a dedicated server ===
Assuming you are running Moodle on a sealed server (i.e. no user logins allowed on the machine) and that root takes care of the modifications to both moodle code and moodle config (config.php), then this are the most tight permissions I can think of:

1. moodledata directory and all of its contents (and subdirectories, includes sessions):
owner: apache user (apache, httpd, www-data, whatever; see above)
group: apache group (apache, httpd, www-data, whatever; see above)
permissions: 700 on directories, 600 on files

2. moodle directory and all of its contents and subdirectories (including config.php):
owner: root
group: root
permissions: 755 on directories, 644 on files.

If you allow local logins for regular users, then 2. should be:
owner: root
group: apache group (apache, httpd, www-data, whatever; see above)
permissions: 750 on directories, 640 on files.

Think of these permissions as the most paranoid ones. You can be secure enough with less tighter permissions, both in moodledata and moodle directories (and subdirectories).

=== Running Moodle on a shared hosting environment ===
If you are running Moodle on a shared hosting environment, then above permissions are probably wrong. If you set 700 as the permission for directories (and 600 for files), you are probably denying the web service user account access to your directories and files.

If you want to tighten your permissions as much as possible, you will need to know:

# the user account and the group the web service is running under (see above).
# the owner of the directories/files of both moodledata and the moodle directory (this should normally be your client user account), and the group of the directories/files. You can usually get this information from the file manager of your hosting control panel. Go to the moodle folder and pick any directory or file and try to view/change the permissions, owner and group of that file. That would normally show the current permissions, owner and group. Do the same for the moodledata directory.

Then, depending on the following scenarios you should use a different set of permissions (listed from more secure to less secure) for your moodledata directory:

# if the web service account and the owner of the directories/files is the same, you should use 700 for directories and 600 for files.
# if the web service group and the group of the directories/files is the same, you should use 770 for directories and 660 for the files.
# if none of the above, you will need to use 777 for directories and 666 for files, which is less secure but it is your only option. 707 and 606 would be more secure, but it might or might not work, depending on your particular setup.

In fact, you just need to set moodledata the permissions specified above, as all the directories and files inside are created by the web service itself, and will have the right permissions.

Regarding the moodle directory, as long as the web service user account can read the files plus read and execute the directories, that should be enough. There is no need to grant write permission to the web service account/group on any of the files or subdirectories. The only drawback is that you will need to create the config.php by hand during the installation process, as Moodle will not be able to create it. But that should not be a big problem.

==See also==

*[[Security FAQ]]
*[https://moodle.com/news/top-security-tips-for-moodle-administrators/ Top security tips for Moodle administrators article]
Using Moodle forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=39404 Guide to Securing your Moodle Server]
*[http://moodle.org/mod/forum/discuss.php?d=93561 How to secure Moodle website from hacking] including recommendations on emergency recovery

[[es:Recomendaciones de Seguridad]]
[[fr:Sécurité]]

Security overview report

2021-04-13T10:06:19Z

Michaelh2:

{{Security}}
A security overview report is available via 'Security checks' in the Site administration "Reports" section.

Some of the checks included are as follows:

*[[report/security/report security check globals|Register globals]]
:register_globals is a PHP setting that must be disabled for Moodle to operate safely.

*[[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.

*[[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.

*[[Vendor directory security check|Vendor directory]]
:The vendor directory should not be present on public sites.

*[[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.

*[[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.

*[[report/security/report_security_check_preventexecpath|Execuable paths]]
:Allowing executable paths to be set via the Admin GUI is a vector for privilege escalation. This can be prevented by setting the following config.php: <code php>$CFG->preventexecpath = true;</code>

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

*[[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.

*[[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.

*[[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.

*[[Password salting|Password salt]]
:Setting a password salt greatly reduces the risk of password theft.

*[[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.

*[[report/security/report security check cookiesecure|Secure cookies]]
:It is recommended to use secure cookies only when serving over SSL.

*[[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.

*[[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.

*[[report/security/report security check riskadmin|Administrators]]
:Review your administrator accounts and make sure you only have what you need.

*[[Backup of user data]]
:Make sure that only roles that need to backup user data can do so and that all users who have the capability are trusted.

*[[report/security/report security check defaultuserrole‎ |Default role for all users]]
:This checks that the registered user role is defined with sane permissions.

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

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

==See also==

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

[[Category:Report]]
[[Category:Site administration]]

[[de:Sicherheitsbericht]]
[[es:Reporte Vista general de Seguridad]]
[[eu:Seguratasunaren_ikuspegi_orokorra]]
[[fr:Panorama de sécurité]]
[[ja:セキュリティオーバービュー]]

Security recommendations

2021-04-13T09:59:11Z

Michaelh2: /* Basic recommendations */

{{Security}}All web application software is highly complex, and every application has security issues that are found from time to time, usually involving some combination of input that the programmers did not anticipate. The Moodle project takes security seriously, and is continuously improving Moodle to close such holes as we find them.

==Introduction==
*This page contains important security measures for your Moodle installation.
*You should report security problems to the [http://tracker.moodle.org/secure/CreateIssue!default.jspa Moodle tracker] (and mark it as a security issue!) so that developers can see it and inform registered Moodle sites about fixes as soon as possible.
*You should not post actual exploits in the forums or elsewhere on the web (to protect Moodle admins who have not upgraded yet).

==Simple security measures==
*The best security strategy is a good backup! But you don't have a good backup unless you are able to restore it. Test your restoration procedures!
*Load only software or services you will use
*Perform regular updates
*Model your security after the layers of clothing you wear on a cold winter day

==Basic recommendations==

;Update Moodle regularly on each release
:Published security holes draw crackers' attention after release. The older the version, the more vulnerabilities it is likely to contain.
; Use https to secure all pages (not just the login page)
:Protect all traffic from your Moodle instance and your users by making all pages accessible via https only. This not only protects passwords on login but also ensures the privacy of your users so that all user data cannot be intercepted or manipulated ("ad injections") from third parties like WLAN providers for example. Free https certificates are available from https://letsencrypt.org/. In addition, set httpslogin=yes in your moodle config to add an extra layer of protection for submitting login credentials.
;[[admin/environment/custom check/php check register globals|Register globals '''MUST''' be disabled]]
:This will help prevent against possible XSS problems in third-party scripts.
;Run the [[Security_overview_report|Security Overview Report]]
:This identifies various configurations within your Moodle site that may pose a security risk, so any issues raised by that report should be investigated and action taken if necessary.
;Use strong passwords for admin and teachers
:Choosing "difficult" passwords is a basic security practice to protect against "brute force" cracking of accounts.
;Only give teacher accounts to trusted users. Avoid creating public sandboxes with free teacher accounts on production servers.
:Teacher accounts have much more liberal permissions and it is easier to create situations where data can be abused or stolen.
;Separate your systems as much as possible
:Another basic security technique is to use different passwords on different systems, use different machines for different services and so on. This will prevent damage being widespread even if one account or one server is compromised.

==Run regular updates==
*Use auto update systems
*Windows Update
*Linux: up2date, yum, apt-get
:Consider automating updates with a script scheduled via cron
*Mac OSX update system
*Stay current with php, apache, and moodle

==Use mailing lists to stay updated==
*CERT - http://www.us-cert.gov/cas/signup.html
*PHP - http://www.php.net/mailing-lists.php - sign up for Announcements list
*MySQL - http://lists.mysql.com - sign up for MySQL Announcements

==Firewalls==
*Security experts recommend a dual firewall
:Differing hardware/software combinations
*Disabling unused services is often as effective as a firewall
:Use netstat -a to review open network ports
*Not a guarantee of protection
*Allow ports
:80, 443(ssl), and 9111 (for chat),
:Remote admin: ssh 22, or rdp 3389

==Password policy==

A password policy may be set up in ''Settings > Site administration > Security > [[Site policies]]''.

There is a check box to determine if password complexity should be enforced or not, the option to set the minimum length of the password, the minimum number of digits, the minimum number of lowercase characters, the minimum number of uppercase characters and the minimum number of non alphanumeric characters.

If a user enters a password that does not meet those requirements, they are given an error message indicating the nature of the problem with the entered password.

Enforcing password complexity along with requiring users to change their initial password go a long way in helping ensure that users choose and are in fact using "good passwords".

However, making the check too onerous just results in them writing it down so be realistic.

==Be prepared for the worst==
*Have backups ready
*Practice recovery procedures ahead of time
*Use a rootkit detector on a regular basis
**Linux/MacOSX - http://www.chkrootkit.org/
**Windows - http://technet.microsoft.com/en-en/sysinternals/bb897445.aspx and http://technet.microsoft.com/de-de/sysinternals/bb897445.aspx

==Moodle security alerts==
*Register your site with Moodle.org
:Registered users receive email alerts
*Security alerts also posted online
*Web - http://moodle.org/security
*RSS feed - http://moodle.org/rss/file.php/1/1/forum/996/rss.xml

==Miscellaneous considerations==
These are all things you might consider that impact your overall security:
*Use the secure forms setting
*Always set a mysql root user password
*Turn off mysql network access
*Use SSL, httpslogins=yes
*Use good passwords - set up a password policy in ''Settings > Site administration > Security > [[Site policies]]''
*Do not enable the ''opentowebcrawlers'' setting (in ''Settings > Site administration > Security > [[Site policies]]'')
*Disable guest access
*Place enrollment keys on all courses or set Course Enrollable = No for all courses
*Ensure the enrolment key hint is disabled (which it is by default) in ''Administration > Site administration > Plugins > Enrolment > Self enrolment.''

==Most secure/paranoid file permissions==

'''Note''': <u>The following information applies to Linux/Unix based installations only, as MS Windows permission system is quite different</u>.

Depending on your server set-up there are two different scenarios:
# You are running Moodle on your own dedicated server.
# You are running Moodle on a shared hosting environment.

In the sections below, you are required to use the web service user account and group to set the permissions, so you need to know them. This can vary quite a bit from server to server but if this feature has not been disabled in your server, you can go to ''<nowiki>http://your.moodle.site/admin/phpinfo.php</nowiki>'' (logging in as admin), and then search for the line that reads 'User/Group', inside the 'apache' table. For example, I get 'www-data' for the user account and 'www-data' for the group too.

=== Running Moodle on a dedicated server ===
Assuming you are running Moodle on a sealed server (i.e. no user logins allowed on the machine) and that root takes care of the modifications to both moodle code and moodle config (config.php), then this are the most tight permissions I can think of:

1. moodledata directory and all of its contents (and subdirectories, includes sessions):
owner: apache user (apache, httpd, www-data, whatever; see above)
group: apache group (apache, httpd, www-data, whatever; see above)
permissions: 700 on directories, 600 on files

2. moodle directory and all of its contents and subdirectories (including config.php):
owner: root
group: root
permissions: 755 on directories, 644 on files.

If you allow local logins for regular users, then 2. should be:
owner: root
group: apache group (apache, httpd, www-data, whatever; see above)
permissions: 750 on directories, 640 on files.

Think of these permissions as the most paranoid ones. You can be secure enough with less tighter permissions, both in moodledata and moodle directories (and subdirectories).

=== Running Moodle on a shared hosting environment ===
If you are running Moodle on a shared hosting environment, then above permissions are probably wrong. If you set 700 as the permission for directories (and 600 for files), you are probably denying the web service user account access to your directories and files.

If you want to tighten your permissions as much as possible, you will need to know:

# the user account and the group the web service is running under (see above).
# the owner of the directories/files of both moodledata and the moodle directory (this should normally be your client user account), and the group of the directories/files. You can usually get this information from the file manager of your hosting control panel. Go to the moodle folder and pick any directory or file and try to view/change the permissions, owner and group of that file. That would normally show the current permissions, owner and group. Do the same for the moodledata directory.

Then, depending on the following scenarios you should use a different set of permissions (listed from more secure to less secure) for your moodledata directory:

# if the web service account and the owner of the directories/files is the same, you should use 700 for directories and 600 for files.
# if the web service group and the group of the directories/files is the same, you should use 770 for directories and 660 for the files.
# if none of the above, you will need to use 777 for directories and 666 for files, which is less secure but it is your only option. 707 and 606 would be more secure, but it might or might not work, depending on your particular setup.

In fact, you just need to set moodledata the permissions specified above, as all the directories and files inside are created by the web service itself, and will have the right permissions.

Regarding the moodle directory, as long as the web service user account can read the files plus read and execute the directories, that should be enough. There is no need to grant write permission to the web service account/group on any of the files or subdirectories. The only drawback is that you will need to create the config.php by hand during the installation process, as Moodle will not be able to create it. But that should not be a big problem.

==See also==

*[[Security FAQ]]
Using Moodle forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=39404 Guide to Securing your Moodle Server]
*[http://moodle.org/mod/forum/discuss.php?d=93561 How to secure Moodle website from hacking] including recommendations on emergency recovery

[[es:Recomendaciones de Seguridad]]
[[fr:Sécurité]]

Security recommendations

2021-04-13T09:56:29Z

Michaelh2: /* Basic recommendations */

{{Security}}All web application software is highly complex, and every application has security issues that are found from time to time, usually involving some combination of input that the programmers did not anticipate. The Moodle project takes security seriously, and is continuously improving Moodle to close such holes as we find them.

==Introduction==
*This page contains important security measures for your Moodle installation.
*You should report security problems to the [http://tracker.moodle.org/secure/CreateIssue!default.jspa Moodle tracker] (and mark it as a security issue!) so that developers can see it and inform registered Moodle sites about fixes as soon as possible.
*You should not post actual exploits in the forums or elsewhere on the web (to protect Moodle admins who have not upgraded yet).

==Simple security measures==
*The best security strategy is a good backup! But you don't have a good backup unless you are able to restore it. Test your restoration procedures!
*Load only software or services you will use
*Perform regular updates
*Model your security after the layers of clothing you wear on a cold winter day

==Basic recommendations==

;Update Moodle regularly on each release
:Published security holes draw crackers' attention after release. The older the version, the more vulnerabilities it is likely to contain.
; Use https to secure all pages (not just the login page)
:Protect all traffic from your Moodle instance and your users by making all pages accessible via https only. This not only protects passwords on login but also ensures the privacy of your users so that all user data cannot be intercepted or manipulated ("ad injections") from third parties like WLAN providers for example. Free https certificates are available from https://letsencrypt.org/. In addition, set httpslogin=yes in your moodle config to add an extra layer of protection for submitting login credentials.
;[[admin/environment/custom check/php check register globals|Register globals '''MUST''' be disabled]]
:This will help prevent against possible XSS problems in third-party scripts.
;Run the [[Security_overview_report|Security Overview Report]] and address any issues identified.
;Use strong passwords for admin and teachers
:Choosing "difficult" passwords is a basic security practice to protect against "brute force" cracking of accounts.
;Only give teacher accounts to trusted users. Avoid creating public sandboxes with free teacher accounts on production servers.
:Teacher accounts have much more liberal permissions and it is easier to create situations where data can be abused or stolen.
;Separate your systems as much as possible
:Another basic security technique is to use different passwords on different systems, use different machines for different services and so on. This will prevent damage being widespread even if one account or one server is compromised.

==Run regular updates==
*Use auto update systems
*Windows Update
*Linux: up2date, yum, apt-get
:Consider automating updates with a script scheduled via cron
*Mac OSX update system
*Stay current with php, apache, and moodle

==Use mailing lists to stay updated==
*CERT - http://www.us-cert.gov/cas/signup.html
*PHP - http://www.php.net/mailing-lists.php - sign up for Announcements list
*MySQL - http://lists.mysql.com - sign up for MySQL Announcements

==Firewalls==
*Security experts recommend a dual firewall
:Differing hardware/software combinations
*Disabling unused services is often as effective as a firewall
:Use netstat -a to review open network ports
*Not a guarantee of protection
*Allow ports
:80, 443(ssl), and 9111 (for chat),
:Remote admin: ssh 22, or rdp 3389

==Password policy==

A password policy may be set up in ''Settings > Site administration > Security > [[Site policies]]''.

There is a check box to determine if password complexity should be enforced or not, the option to set the minimum length of the password, the minimum number of digits, the minimum number of lowercase characters, the minimum number of uppercase characters and the minimum number of non alphanumeric characters.

If a user enters a password that does not meet those requirements, they are given an error message indicating the nature of the problem with the entered password.

Enforcing password complexity along with requiring users to change their initial password go a long way in helping ensure that users choose and are in fact using "good passwords".

However, making the check too onerous just results in them writing it down so be realistic.

==Be prepared for the worst==
*Have backups ready
*Practice recovery procedures ahead of time
*Use a rootkit detector on a regular basis
**Linux/MacOSX - http://www.chkrootkit.org/
**Windows - http://technet.microsoft.com/en-en/sysinternals/bb897445.aspx and http://technet.microsoft.com/de-de/sysinternals/bb897445.aspx

==Moodle security alerts==
*Register your site with Moodle.org
:Registered users receive email alerts
*Security alerts also posted online
*Web - http://moodle.org/security
*RSS feed - http://moodle.org/rss/file.php/1/1/forum/996/rss.xml

==Miscellaneous considerations==
These are all things you might consider that impact your overall security:
*Use the secure forms setting
*Always set a mysql root user password
*Turn off mysql network access
*Use SSL, httpslogins=yes
*Use good passwords - set up a password policy in ''Settings > Site administration > Security > [[Site policies]]''
*Do not enable the ''opentowebcrawlers'' setting (in ''Settings > Site administration > Security > [[Site policies]]'')
*Disable guest access
*Place enrollment keys on all courses or set Course Enrollable = No for all courses
*Ensure the enrolment key hint is disabled (which it is by default) in ''Administration > Site administration > Plugins > Enrolment > Self enrolment.''

==Most secure/paranoid file permissions==

'''Note''': <u>The following information applies to Linux/Unix based installations only, as MS Windows permission system is quite different</u>.

Depending on your server set-up there are two different scenarios:
# You are running Moodle on your own dedicated server.
# You are running Moodle on a shared hosting environment.

In the sections below, you are required to use the web service user account and group to set the permissions, so you need to know them. This can vary quite a bit from server to server but if this feature has not been disabled in your server, you can go to ''<nowiki>http://your.moodle.site/admin/phpinfo.php</nowiki>'' (logging in as admin), and then search for the line that reads 'User/Group', inside the 'apache' table. For example, I get 'www-data' for the user account and 'www-data' for the group too.

=== Running Moodle on a dedicated server ===
Assuming you are running Moodle on a sealed server (i.e. no user logins allowed on the machine) and that root takes care of the modifications to both moodle code and moodle config (config.php), then this are the most tight permissions I can think of:

1. moodledata directory and all of its contents (and subdirectories, includes sessions):
owner: apache user (apache, httpd, www-data, whatever; see above)
group: apache group (apache, httpd, www-data, whatever; see above)
permissions: 700 on directories, 600 on files

2. moodle directory and all of its contents and subdirectories (including config.php):
owner: root
group: root
permissions: 755 on directories, 644 on files.

If you allow local logins for regular users, then 2. should be:
owner: root
group: apache group (apache, httpd, www-data, whatever; see above)
permissions: 750 on directories, 640 on files.

Think of these permissions as the most paranoid ones. You can be secure enough with less tighter permissions, both in moodledata and moodle directories (and subdirectories).

=== Running Moodle on a shared hosting environment ===
If you are running Moodle on a shared hosting environment, then above permissions are probably wrong. If you set 700 as the permission for directories (and 600 for files), you are probably denying the web service user account access to your directories and files.

If you want to tighten your permissions as much as possible, you will need to know:

# the user account and the group the web service is running under (see above).
# the owner of the directories/files of both moodledata and the moodle directory (this should normally be your client user account), and the group of the directories/files. You can usually get this information from the file manager of your hosting control panel. Go to the moodle folder and pick any directory or file and try to view/change the permissions, owner and group of that file. That would normally show the current permissions, owner and group. Do the same for the moodledata directory.

Then, depending on the following scenarios you should use a different set of permissions (listed from more secure to less secure) for your moodledata directory:

# if the web service account and the owner of the directories/files is the same, you should use 700 for directories and 600 for files.
# if the web service group and the group of the directories/files is the same, you should use 770 for directories and 660 for the files.
# if none of the above, you will need to use 777 for directories and 666 for files, which is less secure but it is your only option. 707 and 606 would be more secure, but it might or might not work, depending on your particular setup.

In fact, you just need to set moodledata the permissions specified above, as all the directories and files inside are created by the web service itself, and will have the right permissions.

Regarding the moodle directory, as long as the web service user account can read the files plus read and execute the directories, that should be enough. There is no need to grant write permission to the web service account/group on any of the files or subdirectories. The only drawback is that you will need to create the config.php by hand during the installation process, as Moodle will not be able to create it. But that should not be a big problem.

==See also==

*[[Security FAQ]]
Using Moodle forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=39404 Guide to Securing your Moodle Server]
*[http://moodle.org/mod/forum/discuss.php?d=93561 How to secure Moodle website from hacking] including recommendations on emergency recovery

[[es:Recomendaciones de Seguridad]]
[[fr:Sécurité]]

HTTP security

2021-04-13T06:01:04Z

Michaelh2:

{{Security}}
*In Moodle 3.4 onwards, the setting 'Use HTTPS for logins' (loginhttps) has been removed.
* There is a [[HTTPS conversion tool]] for converting embedded content to HTTPS.

==Secure cookies only==

It is recommended to use secure cookies only when serving over [https://en.wikipedia.org/wiki/Transport_Layer_Security SSL]. When not serving over SSL, the setting is ignored. In Moodle 3.1.2 onwards, the 'Secure cookies only' default setting is on.

==cURL blocked hosts list==

This allows you to block Moodle's cURL implementation from accessing the specified hosts, wherever it is used to fetch content (such as by the URL downloader in the file picker). Generally it is recommended that as a minimum this is configured to prevent access to any internal network resources. The following is an example list of hosts which can be configured, which prevents access to various versions of "localhost", as well as an address commonly used by AWS and some other cloud providers to provide meta data about the server instance (169.254.169.254):

<code php>
127.0.0.1
192.168.0.0/16
10.0.0.0/8
172.16.0.0/12
0.0.0.0
localhost
169.254.169.254
0000::1
</code>

In future, some logical default values such as those above will be configured automatically for new Moodle sites. See MDL-56873 for more details.

'''Note:''' In addition to configuring this at the application level via this setting, it is also recommended that sufficient firewall/network security measures are in place, including restricting access to internal network endpoints to those users/services that require them.

==cURL allowed ports list==

This allows you to restrict Moodle's cURL implementation to only access the specified list of port numbers, wherever it is used to fetch content (such as by the URL downloader in the file picker). Generally it is recommended that this is configured to only allow standard web ports, as follows:

<code php>
80
443
</code>

In future, some logical default values such as those above will be configured automatically for new Moodle sites. See MDL-56873 for more details.

'''Note:''' In addition to configuring this at the application level via this setting, it is also recommended that sufficient firewall/network security measures are in place, including restricting access to open ports on the internal network to those users/services that require them.

==See also==

* MDL-55662 for removing the secure cookies only setting

[[Category:Site administration]]

[[de:HTTP-Sicherheit]]
[[es:Seguridad HTTP]]

Security recommendations

2020-11-12T08:56:42Z

Michaelh2: /* Miscellaneous considerations */

{{Security}}All web application software is highly complex, and every application has security issues that are found from time to time, usually involving some combination of input that the programmers did not anticipate. The Moodle project takes security seriously, and is continuously improving Moodle to close such holes as we find them.

==Introduction==
*This page contains important security measures for your Moodle installation.
*You should report security problems to the [http://tracker.moodle.org/secure/CreateIssue!default.jspa Moodle tracker] (and mark it as a security issue!) so that developers can see it and inform registered Moodle sites about fixes as soon as possible.
*You should not post actual exploits in the forums or elsewhere on the web (to protect Moodle admins who have not upgraded yet).

==Simple security measures==
*The best security strategy is a good backup! But you don't have a good backup unless you are able to restore it. Test your restoration procedures!
*Load only software or services you will use
*Perform regular updates
*Model your security after the layers of clothing you wear on a cold winter day

==Basic recommendations==

;Update Moodle regularly on each release
:Published security holes draw crackers attention after release. The older the version, the more vulnerabilities it is likely to contain.
; Use https to secure all pages (not just the login page)
:Protect all traffic from your Moodle instance and your users by making all pages accessible via https only. This not only protects passwords on login but also ensures the privacy of your users so that all user data cannot be intercepted or manipulated ("ad injections") from third parties like WLAN providers for example. Free https certificates are available from https://letsencrypt.org/. In addition, set httpslogin=yes in your moodle config to add an extra layer of protection for submitting login credentials.
;[[admin/environment/custom check/php check register globals|Register globals '''MUST''' be disabled]]
:This will help prevent against possible XSS problems in third-party scripts.
;Use strong passwords for admin and teachers
:Choosing "difficult" passwords is a basic security practice to protect against "brute force" cracking of accounts.
;Only give teacher accounts to trusted users. Avoid creating public sandboxes with free teacher accounts on production servers.
:Teacher accounts have much freer permissions and it is easier to create situations where data can be abused or stolen.
;Separate your systems as much as possible
:Another basic security technique is to use different passwords on different systems, use different machines for different services and so on. This will prevent damage being widespread even if one account or one server is compromised.

==Run regular updates==
*Use auto update systems
*Windows Update
*Linux: up2date, yum, apt-get
:Consider automating updates with a script scheduled via cron
*Mac OSX update system
*Stay current with php, apache, and moodle

==Use mailing lists to stay updated==
*CERT - http://www.us-cert.gov/cas/signup.html
*PHP - http://www.php.net/mailing-lists.php - sign up for Announcements list
*MySQL - http://lists.mysql.com - sign up for MySQL Announcements

==Firewalls==
*Security experts recommend a dual firewall
:Differing hardware/software combinations
*Disabling unused services is often as effective as a firewall
:Use netstat -a to review open network ports
*Not a guarantee of protection
*Allow ports
:80, 443(ssl), and 9111 (for chat),
:Remote admin: ssh 22, or rdp 3389

==Password policy==

A password policy may be set up in ''Settings > Site administration > Security > [[Site policies]]''.

There is a check box to determine if password complexity should be enforced or not, the option to set the minimum length of the password, the minimum number of digits, the minimum number of lowercase characters, the minimum number of uppercase characters and the minimum number of non alphanumeric characters.

If a user enters a password that does not meet those requirements, they are given an error message indicating the nature of the problem with the entered password.

Enforcing password complexity along with requiring users to change their initial password go a long way in helping ensure that users choose and are in fact using "good passwords".

However, making the check too onerous just results in them writing it down so be realistic.

==Be prepared for the worst==
*Have backups ready
*Practice recovery procedures ahead of time
*Use a rootkit detector on a regular basis
**Linux/MacOSX - http://www.chkrootkit.org/
**Windows - http://technet.microsoft.com/en-en/sysinternals/bb897445.aspx and http://technet.microsoft.com/de-de/sysinternals/bb897445.aspx

==Moodle security alerts==
*Register your site with Moodle.org
:Registered users receive email alerts
*Security alerts also posted online
*Web - http://moodle.org/security
*RSS feed - http://moodle.org/rss/file.php/1/1/forum/996/rss.xml

==Miscellaneous considerations==
These are all things you might consider that impact your overall security:
*Use the secure forms setting
*Always set a mysql root user password
*Turn off mysql network access
*Use SSL, httpslogins=yes
*Use good passwords - set up a password policy in ''Settings > Site administration > Security > [[Site policies]]''
*Do not enable the ''opentowebcrawlers'' setting (in ''Settings > Site administration > Security > [[Site policies]]'')
*Disable guest access
*Place enrollment keys on all courses or set Course Enrollable = No for all courses
*Ensure the enrolment key hint is disabled (which it is by default) in ''Administration > Site administration > Plugins > Enrolment > Self enrolment.''

==Most secure/paranoid file permissions==

'''Note''': <u>The following information applies to Linux/Unix based installations only, as MS Windows permission system is quite different</u>.

Depending on your server set-up there are two different scenarios:
# You are running Moodle on your own dedicated server.
# You are running Moodle on a shared hosting environment.

In the sections below, you are required to use the web service user account and group to set the permissions, so you need to know them. This can vary quite a bit from server to server but if this feature has not been disabled in your server, you can go to ''<nowiki>http://your.moodle.site/admin/phpinfo.php</nowiki>'' (logging in as admin), and then search for the line that reads 'User/Group', inside the 'apache' table. For example, I get 'www-data' for the user account and 'www-data' for the group too.

=== Running Moodle on a dedicated server ===
Assuming you are running Moodle on a sealed server (i.e. no user logins allowed on the machine) and that root takes care of the modifications to both moodle code and moodle config (config.php), then this are the most tight permissions I can think of:

1. moodledata directory and all of its contents (and subdirectories, includes sessions):
owner: apache user (apache, httpd, www-data, whatever; see above)
group: apache group (apache, httpd, www-data, whatever; see above)
permissions: 700 on directories, 600 on files

2. moodle directory and all of its contents and subdirectories (including config.php):
owner: root
group: root
permissions: 755 on directories, 644 on files.

If you allow local logins for regular users, then 2. should be:
owner: root
group: apache group (apache, httpd, www-data, whatever; see above)
permissions: 750 on directories, 640 on files.

Think of these permissions as the most paranoid ones. You can be secure enough with less tighter permissions, both in moodledata and moodle directories (and subdirectories).

=== Running Moodle on a shared hosting environment ===
If you are running Moodle on a shared hosting environment, then above permissions are probably wrong. If you set 700 as the permission for directories (and 600 for files), you are probably denying the web service user account access to your directories and files.

If you want to tighten your permissions as much as possible, you will need to know:

# the user account and the group the web service is running under (see above).
# the owner of the directories/files of both moodledata and the moodle directory (this should normally be your client user account), and the group of the directories/files. You can usually get this information from the file manager of your hosting control panel. Go to the moodle folder and pick any directory or file and try to view/change the permissions, owner and group of that file. That would normally show the current permissions, owner and group. Do the same for the moodledata directory.

Then, depending on the following scenarios you should use a different set of permissions (listed from more secure to less secure) for your moodledata directory:

# if the web service account and the owner of the directories/files is the same, you should use 700 for directories and 600 for files.
# if the web service group and the group of the directories/files is the same, you should use 770 for directories and 660 for the files.
# if none of the above, you will need to use 777 for directories and 666 for files, which is less secure but it is your only option. 707 and 606 would be more secure, but it might or might not work, depending on your particular setup.

In fact, you just need to set moodledata the permissions specified above, as all the directories and files inside are created by the web service itself, and will have the right permissions.

Regarding the moodle directory, as long as the web service user account can read the files plus read and execute the directories, that should be enough. There is no need to grant write permission to the web service account/group on any of the files or subdirectories. The only drawback is that you will need to create the config.php by hand during the installation process, as Moodle will not be able to create it. But that should not be a big problem.

==See also==

*[[Security FAQ]]
Using Moodle forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=39404 Guide to Securing your Moodle Server]
*[http://moodle.org/mod/forum/discuss.php?d=93561 How to secure Moodle website from hacking] including recommendations on emergency recovery

[[es:Recomendaciones de Seguridad]]
[[fr:Sécurité]]

OAuth 2 LinkedIn service

2019-05-29T05:27:55Z

Michaelh2:

{{OAuth2}}

From 1 May 2019, LinkedIn no longer support their v1 API, which could previously be configured as an OAuth 2 authentication method in Moodle. According to LinkedIn's v2 API [https://docs.microsoft.com/en-us/linkedin/consumer/integrations/self-serve/migration-faq?context=linkedin/consumer/context migration documentation], the new API replaces the old basic user information endpoint with a 'lite' endpoint, which does not include a user's email address (which must be retrieved from a separate endpoint).

Since email address is a required field in Moodle, and our OAuth 2 implementation currently requires all user information to be retrieved from a single endpoint, the LinkedIn v2 API currently appears to be incompatible with Moodle's "Custom OAuth 2 Service" feature.

We are continuing to investigate a workaround for the new API, and will update this documentation further when a solution can be found. In the meantime, if you have any information that may assist with this, please contribute to Tracker issue MDL-65637.
[[es:Servicio OAuth 2 Linkedln]]
[[de:OAuth2 LinkedIn Service]]

report/security/report security check google

2019-05-22T05:56:00Z

Michaelh2:

{{Security overview report}}Allowing search engines 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.

==See also==

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

Security FAQ

2019-01-10T07:42:09Z

Michaelh2: /* Who is able to view security issues in the Tracker? */

{{Security}}
==How do I report a security issue?==

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?==

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.

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

* [[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 forum or [http://twitter.com/moodlesecurity follow moodlesecurity on Twitter].

==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 [[dev:Tracker guide#When_creating_an_issue|Security Level field description in the Tracker guide]].

==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?==

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==

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

[[Category:FAQ]]

[[es:Seguridad FAQ]]

Nolink tags

2019-01-04T01:53:47Z

Michaelh2: /* See also */

{{stub}}
At times it is useful to turn off HTML linking. This can be done several ways. One is to use the [[HTML editor]]'s no linking icon. Another way is to toggle the source code and place a <nowiki><nolink> </nolink></nowiki> set of tags directly in the code.

:''TIP:'' New users of Moodle should be careful when using any nolink feature for the first few times. See below.

==Tips and Tricks==
Joseph Rézeau offered these observation in the Quiz forum:

In the prehistory of Moodle we used to have the <nowiki><nolink></nolink></nowiki> tag to enclose any portion of HTML which we did not want to be autolinked. This was not very WC3 compliant, so it was replaced (or rather complemented) by <nowiki><span class="nolink"></span</nowiki>>. That was in my opinion an unfortunate decision; it should have been replaced with a <nowiki><div class="nolink"></div></nowiki>, not a span tag. The reason is that a <span>'s scope is too narrow and we often want to enclose a whole block of HTML within a nolink tag, so <div> should have been the best choice...

So, like you, I keep using the old <nowiki><nolink></nolink></nowiki> tag, which in fact still works, '''provided you do not come back to your HTML text and edit it'''. If you do, then you have to remove the <nowiki><span class="nolink"></span></nowiki>and replace it with <nowiki><nolink></nolink></nowiki> (as you found out). I do it all the time and find it pretty irritating. The automatic replacing is due to the HTML editor being over-zealous in its tidying up of the HTML text.

Another solution would be to hack the Moodle code and systematically replace all occurrences of <nowiki><span class="nolink"></span></nowiki> with <nowiki><div class="nolink"></div></nowiki>. I have done it on my local installation and it works OK.

However, there is another problem. If you have typed some text in the HTML editor and formatted it (e.g. added a few bold or italics, etc. here and there) and then select that formatted text and click on the Prevent automatic linking button in the HTML editor toolbar, you find that all of your formatting is wiped away... You can, of course, re-format your text, but its a loss of time. If you decide that the whole of your text will have to be prevented from automatic linking (as is a frequent requirement in quiz questions), then you should immediately click on the Prevent automatic linking button, before typing anything. If the editor complains that "you must select some text first", then clidk on the body tag at the bottom of the editor (see attached 1) before clicking the Prevent automatic linking button. Then start typing your text, formattting it, etc.

==See also==
[[HTML editor]]<br>
[[Media FAQ]]