Moodle app security

The Moodle app is a hybrid app (uses web-technologies) developed on top of a well-tested widely used framework called "Cordova" that provides a robust container for HTML apps.

Security is very important to us, this is why we follow the Cordova and Moodle security recommendations:

• Cordova: https://cordova.apache.org/docs/en/latest/guide/appdev/security/
• Moodle: https://docs.moodle.org/dev/Security (when developing Web Services)

How we approach security

• Login and authorisation
  • Authorisation is done via temporary access tokens. The duration of the access tokens can be configured via Moodle settings.
  • Single Sign-On (or auto-login) from the app to the site is done using a special private token (that is obtained and stored when the user log-in with the app)
  • Single Sign-On (or auto-login) from the app to the site has several additional restrictions (like limiting it in only several times per hour)
  • QR-Login is done using temporary tokens that require the user to be in the same network (IP address) and it is limited to 10 minutes time
  • For retrieving files from the server (images or other assets), a different non-authentication token is used.

• Permissions
  • The app only has access to a subset of Moodle functionalities (available through the Moodle App Service)
  • Privileges escalation is not possible via the Web Services layer since all the operations are done in a non-privileged way, permissions are checked based on the currently authenticated user.
  • Even if a temporary access token for an admin (or privileged user) was hijacked, it wouldn't be possible for the attacker to access to site administration functionality via the Moodle site.

Because the app is a Webservices client we recommend to enable it only under https and use the following settings to enforce security like:

• Enable only certain roles to be able to access via the app via system capabilities (avoid site administrators)
• Use Moodle security settings to reduce the expiration time of WebService access tokens (so the user has to authenticate again)
• Apart from that, the Cordova framework enforces security adding restrictions like avoiding connecting to sites running non-trusted certificates.

What is the Moodle app security issues process?

• We follow the standard Moodle security process: https://docs.moodle.org/dev/Moodle_security_procedures
• There is only one relevant difference: security patches are applied immediately in the next app release or in an emergency release (depending the risks attached to the issue)

Do you run security/penetration/pentest or static code analysis tests?

We do occasionally receive automated vulnerability reports of this nature. The issue with automated tools is that they usually output generic results that indicate where an exploit may be possible, which means the results often contain many false positives.

As mentioned above our app is built on top of Cordova, we rely on the Cordova framework developers to detect any native code issue.

You can do a search in the Cordova project tracker to see that several runs with the Static Code Analysis Veracode tool created issues that have been already solved, see: https://issues.apache.org/jira/issues/?jql=project%20%3D%20CB%20AND%20text%20~%20%22veracode%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

Unfortunately, those Veracode runs are not publicly available because most of the time are run by external parties using the framework.

Please, note also that there are CVE codes for Cordova security issues: https://www.cvedetails.com/product/27153/Apache-Cordova.html?vendor_id=4