-
Epic
-
Resolution: Unresolved
-
Minor
-
None
-
3.3
-
None
-
MOODLE_33_STABLE
-
Remove RISK_XSS from capabilities
Historically Moodle has allowed teachers to insert "good" javascript in the text fields. When we allow it we mark the respective capability with RISK_XSS bitmask. We consider users having these capabilities "trusted" and do not clean the text that they enter.
I have been closing lots of security reports about users being able to inject XSS referring them to:
https://docs.moodle.org/en/Security_FAQ#I_have_discovered_Cross_Site_Scripting_.28XSS.29_is_possible_with_Moodle
Relying on 'moodle/site:trustcontent' capability (that is marked with RISK_XSS) will allow to preserve current flexibility for teachers but at the same time remove RISK_XSS from the most of the capabilities, especially capabilities that can be potentially given to students. At the moment we do not encourage collaboration because it is impossible, for example, to give a student capability to create any activity or resource without allowing them to insert javascript in the descriptions.
Approach 1:
This is what was done in forums where in the same form trusted users (teachers) CAN insert javascript and untrusted users (students) CAN NOT.
Each text field ('editor' form element) should have three fields in the database and not usual two, for example:
<FIELD NAME="message" TYPE="text" NOTNULL="true" SEQUENCE="false"/>
|
<FIELD NAME="messageformat" TYPE="int" LENGTH="2" NOTNULL="true" DEFAULT="0" SEQUENCE="false"/>
|
<FIELD NAME="messagetrust" TYPE="int" LENGTH="2" NOTNULL="true" DEFAULT="0" SEQUENCE="false"/>
|
Editor options should include:
'trusttext' => true
|
(Editor options are passed to the form element 'editor' and also to file_prepare_standard_editor() and file_save_draft_area_files())
This way users with capability 'moodle/site:trustcontent' in the current context will be able to insert JS and users without this capability will not.
Approach 2:
BEFORE storing the text into the database clean it for users that do not have 'moodle/site:trustcontent' in the current context. (See also discussion below)
Please create issues in this epic for individual capabilities that you want to see refactored and we will work on them one by one. Please vote on issues so we can see which capabilities should be converted first.
- has a non-specific relationship to
-
MDL-47658 Description of enabletrusttext is misleading
- Open
-
MDL-76743 Content processing and User trust
- Open
-
MDL-28501 For folder resource, allow files to be opened in the browser rather than being downloaded
- Closed
-
MDL-47638 Indicate if a form field will be cleaned when it is displayed.
- Closed
-
MDL-47639 Add a new setting to clean all text always.
- Closed
- has been marked as being related by
-
MDL-47658 Description of enabletrusttext is misleading
- Open
-
MDL-80952 When $CFG->forceclean is enabled, $CFG->enabletrust is ignored, but the combination of them would be great
- Open
-
MDL-60940 Add ability to force cleaning all user texts
- Closed
-
MDL-61876 Fixes for $CFG->forceclean and move to experimental
- Closed
- will help resolve
-
MDL-52038 Persistent Cross Site Scripting (XSS)
- Closed
-
MDL-9493 XSS in assignment description
- Closed
-
MDL-9495 xss when adding a new course
- Closed
-
MDL-30011 XSS vuln in Matching Question type
- Closed
-
MDL-50635 Essai javascript injection + Cookies theft
- Closed
-
MDL-57747 JS code injection via resource description
- Closed
-
MDL-59451 Course module into should be filtered for XSS
- Closed