Security:Insecure configuration management: Difference between revisions
No edit summary |
Dev Docs Bot (talk | contribs) m (Protected "Security:Insecure configuration management": Developer Docs Migration ([Edit=Allow only administrators] (indefinite))) |
||
| (4 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{Template:Migrated|newDocId=/general/development/policies/security/insecure-config}} | |||
This page forms part of the [[Security|Moodle security guidelines]]. | This page forms part of the [[Security|Moodle security guidelines]]. | ||
| Line 13: | Line 14: | ||
This is not really a problem that can be solved from within Moodle code. However, any Moodle code that does install other PHP code (for example admin/langimport.php) must be written with extreme care. | This is not really a problem that can be solved from within Moodle code. However, any Moodle code that does install other PHP code (for example admin/langimport.php) must be written with extreme care. | ||
| Line 26: | Line 25: | ||
* Keep up-to-date with the latest Moodle release from whichever branch you are using. | * Keep up-to-date with the latest Moodle release from whichever branch you are using. | ||
** Register your Moodle site, so you get notified of security problems before the general public. | ** Register your Moodle site, so you get notified of security problems before the general public. | ||
* Think about how you deploy the Moodle code to your server. For example, if you [[ | * Think about how you deploy the Moodle code to your server. For example, if you [[:en:Git_for_Administrators|use git]], then 'git status' will tell you which files have been edited. | ||
** Alternatively, if you upload the Moodle code manually, delete all the old code except config.php before you upload a new version. | ** Alternatively, if you upload the Moodle code manually, delete all the old code except config.php before you upload a new version. | ||
* Be very careful who can access your servers. | * Be very careful who can access your servers. | ||
| Line 36: | Line 35: | ||
* [[Coding]] | * [[Coding]] | ||
[[Category:Security]] | [[Category:Security]] | ||
Latest revision as of 07:27, 6 May 2022
| Important:
This content of this page has been updated and migrated to the new Moodle Developer Resources. The information contained on the page should no longer be seen up-to-date. Why not view this page on the new site and help us to migrate more content to the new site! |
This page forms part of the Moodle security guidelines.
What is the danger?
Evil Hacker somehow gets access to your server some time and installs some nasty code. For example, they could add some code to the login page that records every username and password entered, and sends it back to evel-hacker.com.
Unfortunately, you have no procedures in place for detecting that this is happening.
Another problem is not updating to the latest Moodle release, which means that you will be running a version of Moodle with know security holes.
How Moodle avoids this problem
This is not really a problem that can be solved from within Moodle code. However, any Moodle code that does install other PHP code (for example admin/langimport.php) must be written with extreme care.
What you need to do in your code
- If you are writing code like admin/langimport.php, make sure you know what you are doing.
What you need to do as an administrator
- Keep up-to-date with the latest Moodle release from whichever branch you are using.
- Register your Moodle site, so you get notified of security problems before the general public.
- Think about how you deploy the Moodle code to your server. For example, if you use git, then 'git status' will tell you which files have been edited.
- Alternatively, if you upload the Moodle code manually, delete all the old code except config.php before you upload a new version.
- Be very careful who can access your servers.
