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

Possible reflected XSS in editor and imagefile form fields

    XMLWordPrintable

    Details

    • Testing Instructions:
      Hide

      Test 1: Make sure filemanager and editor form elements work with JS on and off and when choosing different formats for text

      Test 2: Try substituting values for hidden elements related to filemanager and editor form elements and make sure that they are not repeated on the page after form submission

      Show
      Test 1: Make sure filemanager and editor form elements work with JS on and off and when choosing different formats for text Test 2: Try substituting values for hidden elements related to filemanager and editor form elements and make sure that they are not repeated on the page after form submission
    • Affected Branches:
      MOODLE_24_STABLE, MOODLE_25_STABLE, MOODLE_26_STABLE, MOODLE_27_STABLE
    • Fixed Branches:
      MOODLE_24_STABLE, MOODLE_25_STABLE, MOODLE_26_STABLE, MOODLE_27_STABLE
    • Story Points:
      8
    • Sprint:
      BACKEND Sprint 13

      Description

      We have the issue below reported to us via a security review of Totara, and since it also affects moodle/master I am reporting it here.

      I am reasonably sure that it is not exploitable, but I am not a security expert therefore I thought I'd better report it just in case. Feel free to close as not a bug if that is the case.

      The report is as follows:

      It has been detected by exploiting the parameter imagefile of the form located in URL [SITEURL]/user/edit.php?id=70&course=1

      Request:

      POST [SITEURL]/user/edit.php

      Payload:

      id=70&course=1&sesskey=xNwOTlWuU1&_qf__user_edit_form=1&mform_isexpanded_id_moodle=1&mform_isexpanded_id_moodle_picture=0&mform_isexpanded_id_moodle_interests=0&firstname=Whitney&mform_isexpanded_id_moodle_optional=0&lastname=Eldridge&email=whitney.eldridge@anaplan.com&interests[othertags]=1234&maildisplay=2&imagealt=1234&url=http://127.0.0.1/foo.html&imagefile=%22'%3E%3Cqss%20%60%3b!--%3D%26%7b()%7d%3E&mailformat=1&icq=1234&maildigest=0&skype=1234&autosubscribe=1&aim=1234&trackforums=0&yahoo=1234&htmleditor=1&msn=1234&city=San%20Francisco&idnumber=1234&institution=1234&timezone=99&department=1234&phone1=8000000000&phone2=8000000000&address=123 Main St.&submitbutton=Update%20profile
      

      Response:

      D%26%7B%28%29%7D%3E&subdirs=0&maxbytes=1048576000&areamaxbytes=-1&maxfiles=1&ctx_id=1&course=1&sesskey=xNwOTlWuU1' height='160' width='600' style='border:1px solid #000'></object></div></noscript><input value=""'><qss `;!--=&{()}>" name="imagefile" type="hidden" /><input value="" id="id_imagefile" type="hidden" /></div></div>
      <div id="fitem_id_imagealt" class="fitem fitem_ftext"><div class="fitemtitle"><label for="id_imagealt">Picture description </label></div><div
      

      There is a similar issue with the summary_editor[itemid] parameter of editor form elements.

      The problem only occurs in forms where the submitted value is being set as the initial value for the field when the form fails validation and is being redisplayed. Someone could potentially insert something malicious in the value field and have it executed when the page returns.

      The reason we don't think this is exploitable is that it seems that the malicious code can only originate and execute on the same client.

      However we did note that the Chrome XSS-Auditor blocked the code from executing "because [the script's] source code was found within the request".

      We had a look to see where the problem is. It appears to be with the way the values for these form elements are filtered when server side validation of the form has failed. "getCleanType" is returning "cleanhtml" and "raw" for the editor and filemanager elements, respectively. "clean_param" with type PARAM_CLEANHTML is being applied to all three of the parameters for the editor, "description_editor[text]", "description_editor[format]" and "description_editor[itemid]", while the "itemid" and "format" parameters seem to only even contain integers. "imagefile" is being cleaned with type PARAM_RAW (the default when no setType has been specified).

      This could be a problem with other form element types - any element where setType is not specified, or when an insufficient filter type is specified and the field is not cleaned in some other way before being sent back to the client when there is a validation error.

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Fix Release Date:
                14/Jul/14