MoodleNet/Security: Difference between revisions
Doug Belshaw (talk | contribs) |
No edit summary |
||
| Line 8: | Line 8: | ||
* MoodleNet users can understand the distinctions between public data and private data/metadata on MoodleNet. | * MoodleNet users can understand the distinctions between public data and private data/metadata on MoodleNet. | ||
* Users | * Users know where their private data/metadata resides and who has access to it, and can access, export, and delete it. | ||
* Protect private user data/metadata, not just from hackers but also (as much as is possible) from other users, instance admins, community moderators, and external applications | * Protect private user data/metadata, not just from hackers but also (as much as is possible) from other users, instance admins, community moderators, and external applications | ||
* Secure from malicious creation, alteration or deletion public data | * Secure from malicious creation, alteration or deletion of public data | ||
* GDPR compliance | * GDPR compliance | ||
Moodle is both a developer of open source self-hosted software, and a cloud service provider with users in the European Union. As a result, we are putting user privacy, data sovereignty, and GDPR compliance into our security plans, including asking both the Moodle community and outside | Moodle is both a developer of open source self-hosted software, and a cloud service provider with users in the European Union. As a result, we are putting user privacy, data sovereignty, and GDPR compliance into our security plans, including asking both the Moodle community and outside experts to review our approaches and implementations. | ||
=== Challenges === | === Challenges === | ||
| Line 31: | Line 31: | ||
<blockquote>“We obviously can’t hire enough engineers to protect against every possible vulnerability, but we can use our bug bounty program to add on-demand expertise where we need it and continuous coverage nearly everywhere else.” – Frank, founder of Nextcloud | <blockquote>“We obviously can’t hire enough engineers to protect against every possible vulnerability, but we can use our bug bounty program to add on-demand expertise where we need it and continuous coverage nearly everywhere else.” – Frank, founder of Nextcloud | ||
</blockquote> | </blockquote> | ||
We’re hoping that a well managed security bug bounty program will help us demonstrate how seriously we take privacy. | |||
We’re hoping that a well-managed security bug bounty program will help us demonstrate how seriously we take privacy. | |||
We believe in transparency about our security, so any valid vulnerabilities discovered are always publicly disclosed after a grace period, to give time for a fix to be developed and deployed by as many self-hosted instances as possible. | We believe in transparency about our security, so any valid vulnerabilities discovered are always publicly disclosed after a grace period, to give time for a fix to be developed and deployed by as many self-hosted instances as possible. | ||
During the initial beta phase, Moodle will be hosting the only official instance of MoodleNet, so will be able to quickly deploy the first wave of security fixes. | During the initial beta phase, Moodle will be hosting the only official instance(s) of MoodleNet, so will be able to quickly deploy the first wave of security fixes. The developers will be aware when the bounty program will start and have time to prepare for the work to receive some real scrutiny. | ||
'''By participating in the MoodleNet bounty program, you agree to be bound by the rules in this document and the [https://docs.moodle.org/dev/MoodleNet/Code_of_Conduct MoodleNet Code of Conduct].''' | '''By participating in the MoodleNet bounty program, you agree to be bound by the rules in this document and the [https://docs.moodle.org/dev/MoodleNet/Code_of_Conduct MoodleNet Code of Conduct].''' | ||
| Line 46: | Line 47: | ||
* High: $400 - i.e. gaining access to private data of any other user. | * High: $400 - i.e. gaining access to private data of any other user. | ||
* Medium: $200 - i.e. limited disclosure of private user data or attacks granting access to a single users’ user session (e.g. XSS) | * Medium: $200 - i.e. limited disclosure of private user data or attacks granting access to a single users’ user session (e.g. XSS) | ||
* Low: $100 - i.e. very limited disclosure of user data or attacks involving a | * Low: $100 - i.e. very limited disclosure of user data or attacks involving a high amount of unlikely user interaction | ||
Only bugs that show a clear exploit that puts users or their private data at risk are eligible for rewards, not theoretical vectors. Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. We only reward the first reporter of a vulnerability. Public disclosure of the vulnerability prior to resolution may cancel a pending reward. | Only bugs that show a clear exploit that puts users or their private data at risk are eligible for rewards, not theoretical vectors. Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. We only reward the first reporter of a vulnerability. Public disclosure of the vulnerability prior to resolution may cancel a pending reward. | ||
We are aware these rewards may be lower than those offered by bigger, more mature, software projects, but we think that starting this bounty programme at such an early stage of the project might mean that many bugs will be found and fixed early, and result in less security exposure for our users. | We are aware these rewards may be lower than those offered by bigger, more mature, software projects, but we think that starting this bounty programme at such an early stage of the project might mean that many bugs will be found and fixed early, and thus result in less security exposure for our users. | ||
Found a bug that isn’t a security issue | Found a bug that isn’t a security issue? While we can’t offer you a monetary reward in that case, we will acknowledge the issue and happily accept reports for it. | ||
=== Scope === | === Scope (final scope TBD upon bounty programme launch) === | ||
* CommonsPub, the ActivityPub server used by MoodleNet: https://gitlab.com/OpenCoop/CommonsPub/Server | * CommonsPub, the ActivityPub server used by MoodleNet: https://gitlab.com/OpenCoop/CommonsPub/Server | ||
| Line 66: | Line 67: | ||
* Alert us about the vulnerability as soon as you become aware of it | * Alert us about the vulnerability as soon as you become aware of it | ||
* | * Follow up with details needed to reproduce and validate the vulnerability and a Proof of Concept (PoC) as soon as possible (if not detailed enough to reproduce the issue, it will not be eligible for a reward) | ||
* Act in good faith to avoid privacy violations, destruction of data, and interruption or degradation of services | * Act in good faith to avoid privacy violations, destruction of data, and interruption or degradation of services | ||
* Do not access or modify users’ private data, without explicit permission of the owner. Only interact with your own accounts or test accounts for security research purposes; | * Do not access or modify users’ private data, without explicit permission of the owner. Only interact with your own accounts or test accounts for security research purposes; | ||
* Contact Moodle HQ (or the instance admin) immediately if you do inadvertently encounter user data. Do not view, alter, save, store, transfer, or otherwise access the data, and immediately purge any local information upon reporting the vulnerability; | * Contact Moodle HQ (or the instance admin) immediately if you do inadvertently encounter user data. Do not view, alter, save, store, transfer, or otherwise access the data, and immediately purge any local information upon reporting the vulnerability; | ||
* Give us time to correct the issue before disclosing it to other parties (if after waiting a reasonable amount of time, we | * Give us time to correct the issue before disclosing it to other parties (if after waiting a reasonable amount of time, we seem clearly unable or unwilling to do anything about it, please do hold us accountable!) | ||
Revision as of 09:51, 4 January 2019
Moodle takes security, privacy and user control seriously, and want to put them front and centre of our project.
Goals
- MoodleNet users can understand the distinctions between public data and private data/metadata on MoodleNet.
- Users know where their private data/metadata resides and who has access to it, and can access, export, and delete it.
- Protect private user data/metadata, not just from hackers but also (as much as is possible) from other users, instance admins, community moderators, and external applications
- Secure from malicious creation, alteration or deletion of public data
- GDPR compliance
Moodle is both a developer of open source self-hosted software, and a cloud service provider with users in the European Union. As a result, we are putting user privacy, data sovereignty, and GDPR compliance into our security plans, including asking both the Moodle community and outside experts to review our approaches and implementations.
Challenges
MoodleNet will be challenging to keep secure, as it is:
- open source, both back-end and front-end
- self-hosted by diverse organisations
- federated (data is transmitted between different hosted instances)
This means there are more attack surfaces compared to typical proprietary, centralised platforms, but also means that hackers and even users can review every part of MoodleNet and make sure that it works as expected. This should result in more secure software, and higher trust in the application and its ecosystem.
Bug bounty programme
Maintaining effective security is a community effort, so if you find a security bug that could potentially impact the security or privacy of MoodleNet users, please report it, with our thanks and potentially a cash reward.
“We obviously can’t hire enough engineers to protect against every possible vulnerability, but we can use our bug bounty program to add on-demand expertise where we need it and continuous coverage nearly everywhere else.” – Frank, founder of Nextcloud
We’re hoping that a well-managed security bug bounty program will help us demonstrate how seriously we take privacy.
We believe in transparency about our security, so any valid vulnerabilities discovered are always publicly disclosed after a grace period, to give time for a fix to be developed and deployed by as many self-hosted instances as possible.
During the initial beta phase, Moodle will be hosting the only official instance(s) of MoodleNet, so will be able to quickly deploy the first wave of security fixes. The developers will be aware when the bounty program will start and have time to prepare for the work to receive some real scrutiny.
By participating in the MoodleNet bounty program, you agree to be bound by the rules in this document and the MoodleNet Code of Conduct.
Rewards
Depending on their impact, issues may qualify for a monetary reward; all reports are reviewed on a case-by-case basis, though here are some guidelines:
- Critical: $800 - i.e gaining remote code execution on the server or full database access.
- High: $400 - i.e. gaining access to private data of any other user.
- Medium: $200 - i.e. limited disclosure of private user data or attacks granting access to a single users’ user session (e.g. XSS)
- Low: $100 - i.e. very limited disclosure of user data or attacks involving a high amount of unlikely user interaction
Only bugs that show a clear exploit that puts users or their private data at risk are eligible for rewards, not theoretical vectors. Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. We only reward the first reporter of a vulnerability. Public disclosure of the vulnerability prior to resolution may cancel a pending reward.
We are aware these rewards may be lower than those offered by bigger, more mature, software projects, but we think that starting this bounty programme at such an early stage of the project might mean that many bugs will be found and fixed early, and thus result in less security exposure for our users.
Found a bug that isn’t a security issue? While we can’t offer you a monetary reward in that case, we will acknowledge the issue and happily accept reports for it.
Scope (final scope TBD upon bounty programme launch)
- CommonsPub, the ActivityPub server used by MoodleNet: https://gitlab.com/OpenCoop/CommonsPub/Server
- MoodleNet back-end: https://gitlab.com/moodlenet/servers/federated
- MoodleNet front-end: https://gitlab.com/moodlenet/clients/react
- Server configurations: https://gitlab.com/moodlenet/servers/deploy
Responsible Disclosure Guidelines
We are committed to working with security researchers to verify, reproduce, and respond to legitimate reported vulnerabilities. You can help us by following these simple guidelines:
- Alert us about the vulnerability as soon as you become aware of it
- Follow up with details needed to reproduce and validate the vulnerability and a Proof of Concept (PoC) as soon as possible (if not detailed enough to reproduce the issue, it will not be eligible for a reward)
- Act in good faith to avoid privacy violations, destruction of data, and interruption or degradation of services
- Do not access or modify users’ private data, without explicit permission of the owner. Only interact with your own accounts or test accounts for security research purposes;
- Contact Moodle HQ (or the instance admin) immediately if you do inadvertently encounter user data. Do not view, alter, save, store, transfer, or otherwise access the data, and immediately purge any local information upon reporting the vulnerability;
- Give us time to correct the issue before disclosing it to other parties (if after waiting a reasonable amount of time, we seem clearly unable or unwilling to do anything about it, please do hold us accountable!)
