Content processing and user trust

Content processing and user trust

by Matt Porritt -
Number of replies: 2
Picture of Core developers Picture of Moodle HQ

Hi All,

We’ve created an epic to collate tracker issues that relate to how Moodle LMS processes, stores and displays content submitted from users; such as course content created by teachers and evaluate this against current functionality. Also to evaluate and collate tracker issues that relate to how users are trusted in Moodle as it relates to content content creation and delivery.

There are further details in the epic and it can be found here: MDL-76743
Over the coming days we’ll be linking relevant existing issues to it. Please add or mention any issues that should be added to it. Or if you feel there is something that isn’t covered please feel free to create a new issue under this epic.

If you wish to create an issue that relates to this tracker that you believe is a security issue the correct reporting procedure needs to be followed. The related documentation for this is here: https://moodledev.io/general/development/process/security.

Regards,


Average of ratings: Useful (2)
In reply to Matt Porritt

Re: Content processing and user trust

by Petr Skoda -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers
Pardon me, is this discussion about the fact that teachers can inject arbitrary Javascript into Moodle sites? If yes, are you planning to reclassify RISK_XSS in teacher role definitions from a feature to a security bug?
In reply to Petr Skoda

Re: Content processing and user trust

by Michael Hughes -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

(paraphrasing response on the ticket for purpose discussion here!)

Speaking as some one who supports a University, with very talented CIS (for example) lecturers and learning technologists who would be impacted by this).

Yes, as some of them are sufficiently competent to do interesting things via this route. Others are not. It should be individual institution decision as to whether or not they trust their staff to be competent to do so, and for Moodle to allow for different levels of trust to be granted. 

So the question "is should they all be allowed to add Javascript to Moodle sites by default?", and does there need to be much more overt warnings to those users who are allowed to do this, about them holding that capability and the repercussions. Should the process why which "arbitrary" javascript is added to a page be improved to ask for verification (say) every time it gets updated (and potentially *prevent* non-permitted users from editing that content and stripping it back out?).

Equally should the issues mentioned by Tim Hunt, where the logged-in-as user has stripped out content make it hard for that user to get a realistic "logged in" view of another user. 

But maybe those privileged users shouldn't be allow to have that content whilst they are privileged, rather than the non-privileged users and once logged in must be treated in all respects as the users they are logged in as (so do XSS protections need to be tightened against admin pages...yes of course).