Moodle Penetration Testing

This is information for people who want to performing a penetration test of their Moodle instance as well as information for pen testers.

XSS risks and capabilities

Moodle has a fine grained capabilities and roles system for providing access control to the whole system. Various capabilities inherently have an XSS risk, for instance an admin setting which allows an admin to inject arbitrary html and js into the sites header or footer. This is both known, and should be consider a feature and not a bug. So the presence of an XSS risk in itself is not a new or unknown issue.

However if a pentest finds that actions can be taken which expose an XSS risk, AND that the test user has NOT been granted capabilities that grant them an explicit XSS risk, then there is a real issue and either the XSS risk should be closed, or it should be disclosed in the definition of that capability.

The most trivial example would be the ability to edit 'site:config' which has the RISK_XSS:

   'moodle/site:config' => array(

       'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG | RISK_DATALOSS,

       'captype' => 'write',
       'contextlevel' => CONTEXT_SYSTEM,
       'archetypes' => array(
       )

https://github.com/moodle/moodle/blob/master/lib/db/access.php#L58-L60

See also: https://docs.moodle.org/310/en/Roles_and_permissions

sesskey param is a CSRF token

Many pentests highlight the use of the ?sesskey=xxx http param as an issue because it leaks to session id. The moodle session is stored in a cookie, and the sesskey is actually instead a somewhat poorly named CSRF token param.

https://docs.moodle.org/dev/Security:Cross-site_request_forgery#Session_key