Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-58639

Remove RISK_XSS from capabilities, instead rely on moodle/site:trustcontent



    • Type: Epic
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 3.3
    • Fix Version/s: None
    • Component/s: Roles / Access
    • Labels:
    • Affected Branches:
    • Epic Name:
      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:

      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.


          Issue Links



              Unassigned Unassigned
              marina Marina Glancy
              Component watchers:
              Amaia Anabitarte, Carlos Escobedo, Ferran Recio, Ilya Tregubov, Sara Arjona (@sarjona)
              12 Vote for this issue
              21 Start watching this issue