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.