Vulnerability scans

There are numerous free and paid tools available to perform automated vulnerability scans of web applications. These usually operate in one of two ways:

Static analysis

As Moodle is open source, you are able to run scanners directly on the source code behind your Moodle site. These tools work by analysing the code (in Moodle's case, PHP and Javascript) for patterns that may represent a potential for a security exploit. These tools never actually execute your code to see what happens, they just read it and perform pattern analysis, much like a human reading through the code, but much faster.

Automated penetration testing

These tools run by attempting to attack your site (or ideally, a copy of your site) using the most common web application vulnerabilities. These include techniques like SQL injection and Cross-Site-Scripting (XSS). These tools often require a test account which they will use to log into your system, then automatically explore the links and forms available, submitting data and reporting if they appear to have successfully exploited your site. Tools like this should only be run with the knowledge and consent of the site owner and host, since they may perform destructive actions and may set off automated threat detection systems.

Help! I've run a vulnerability scan and it's given me a report full of issues! What do I do?

The first step is, not to panic. These tools are just the first step in identifying possible security issues. Their results will need to be analysed and verified by a person with sufficient knowledge of Moodle and web application exploits to determine if the issues are genuine. An issue report from an automated scan does not necessarily mean your site is vulnerable to attack. With this in mind, ensure that you are confident in your organisation's ability to make proper use of such a report before selecting an running a tool against Moodle. If your Moodle site is provided by a Moodle Partner or another third party, discuss with them how you will use the results before performing the scan. They may also be able to advise on tools or techniques for identifying security vulnerabilities.

Moodle's APIs are built with security in mind. There are built-in protections against cross-site-scripting, request forgery, and injection attacks. When code is submitted to Moodle core, it undergoes a review process first by the Moodle community and then by Moodle HQ to ensure good security practices are followed. This doesn't mean that Moodle core code is completely free of vulnerabilities, but it should give you a high level of confidence in its security. Automated scans reporting issues like this are likely to be false positives, due to the tool not correctly identifying the protections that Moodle has in place.

Moodle plugins interact with Moodle using the same APIs, and plugins submitted to the moodle.org plugins database also undergo a review before they are published. However, each update to a plugin does not receive the same level of scrutiny form the Moodle community as updates to Moodle core. You should confirm whether any issues identified by a vulnerability scan are related to a plugin you have installed rather than Moodle core code, and once you have verified the issue, report it to the plugin vendor. You may wish to disable or remove the plugin in the meantime, to mitigate the risk. If you are unsure whether a reported issue affects a plugin, download a fresh copy of Moodle core from the moodle.org website and run the same scan with no additional plugins installed.

How to I report an issue with Moodle core?

If you have tested an issue reported from a vulnerability scan and found that it is a genuine, reproducible issue affecting Moodle core, the first step is to familiarise yourself with Moodle's Security procedures. Moodle follows a policy of responsible disclosure, meaning that details of a vulnerability should not be posted publicly until a fix has been produced, to avoid malicious actors attacking vulnerable sites in the meantime.