Comment 2 for bug 1480329

I was able to replicate this bug. Essentially the problem is that the filebrowser Pieform element, in the event of a file upload, does all the necessary processing and returns a result message entirely in the pieform->get_value() stage (via pieform_element_filebrowser_get_value()). Thus, it never gets to the form validation stage of pieforms, bypassing our normal sesskey check.

This makes a Cross-Site Request Forgery (CSRF) attack possible, which is what Abdullah's video illustrates. The attacker puts together a form that will generate an HTTP request with all the same parameters as Mahara's own file upload process. If they can then trick a logged-in Mahara user into submitting this form in another tab, then they'll cause the user to upload a file of their choice.

With any other form, we include a "sesskey" value in a hidden variable, which matches a randomly generated key stored in the user's session. Then when the form is submitted, we verify that the sesskey that was passed back from the user's browser matches the sesskey in the session. However, because we're not getting to the validation step in the filebrowser upload process, the sesskey is not checked, and thus CSRF is possible.

The code that did this was added in 2009, so this vulnerability is likely present in all current versions of Mahara, and in all places where the filebrowser element is used (not just group files, but also individual files, institution files, and site files). Notably, this means an attacker could upload a file into the Site Files "Public" area, where it would be accessible by logged-out users outside of Mahara.