Moodle Penetration Testing: Difference between revisions
(Created page with "This is information for people who want to performing a penetration test of their Moodle instance as well as information for pen testers.") |
Dev Docs Bot (talk | contribs) m (Protected "Moodle Penetration Testing": Developer Docs Migration ([Edit=Allow only administrators] (indefinite))) |
||
| (8 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{Template:Migrated|newDocId=/general/development/process/security/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. | This is information for people who want to performing a penetration test of their Moodle instance as well as information for pen testers. | ||
== Preparing for a penetration test == | |||
=== Set debugging to normal === | |||
Either turn off all debugging which can disclose stacktraces etc, or show the pentesters how this can be toggled. | |||
=== Setup the environment like production === | |||
Sometimes a dedicated pentest environment is setup and it is setup more like a dev / uat / stage environment which might have things like debugging on (see above). Generally a pentest env should mirror a production configuration to avoid wasting pentesters time. | |||
== Common non-issues == | |||
There are a number of things which pen testers often flag as issues which are more just the way Moodle works and are often misunderstood. | |||
=== 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 considered 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: | |||
<syntaxhighlight lang="php"> | |||
'moodle/site:config' => array( | |||
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG | RISK_DATALOSS, | |||
'captype' => 'write', | |||
'contextlevel' => CONTEXT_SYSTEM, | |||
'archetypes' => array( | |||
) | |||
</syntaxhighlight> | |||
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 normal 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 | |||
Latest revision as of 12:54, 28 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 is information for people who want to performing a penetration test of their Moodle instance as well as information for pen testers.
Preparing for a penetration test
Set debugging to normal
Either turn off all debugging which can disclose stacktraces etc, or show the pentesters how this can be toggled.
Setup the environment like production
Sometimes a dedicated pentest environment is setup and it is setup more like a dev / uat / stage environment which might have things like debugging on (see above). Generally a pentest env should mirror a production configuration to avoid wasting pentesters time.
Common non-issues
There are a number of things which pen testers often flag as issues which are more just the way Moodle works and are often misunderstood.
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 considered 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 normal 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
