Some of our users are doing horrible things with Javascript

Some of our users are doing horrible things with Javascript

by Lexy Walker -
Number of replies: 8
Picture of Core developers

Hello,

I've recently discovered something which is quite alarming and I really don't like that users are able to do this.

So in Moodle 4, the site changed so that courses and activities are shown fixed-width. This has a lot of readability and accessibility benefits by setting the maximum number of characters that can appear on a line, and I really like it. I have had requests to take this away and I have refused them.

Here's the thing: some people in certain departments have gone rogue and have been sharing this code, which they have been adding to labels and custom HTML blocks in their courses:

-script tag removed-
    var cssRules = ".pagelayout-standard #page.drawers .main-inner, body.limitedwidth #page.drawers .main-inner { max-width: 100%;}";
    var styleElement = document.createElement('style');
    styleElement.appendChild(document.createTextNode(cssRules));
    document.getElementsByTagName('head')[0].appendChild(styleElement);
-end script tag removed-

I'm a little bit horrified that they're able to do this. I've managed to reproduce this on a development site, and taking away the "Trust submitted content" permission doesn't seem to stop them being able to do this.

Is anyone familiar with the code behind the "Trust submitted content" feature that can tell me exactly what it blocks and how, and whether random users should be able to embed bits of Javascript like this?

I'm a little bit worred about the security implications of this.

Edit: Adding a link to the purifier function in lib/weblib.php

Average of ratings: -
In reply to Lexy Walker

Re: Some of our users are doing horrible things with Javascript

by Rick Jerz -
Picture of Particularly helpful Moodlers Picture of Testers
I can't help you with your technical questions, but I can provide some thoughts about your situation.

First, it is interesting that your instructors have found their own workaround to this "full width" issue. It appears their position is, "If you can't fix it, they will." So, when there is a will, there is a way.

I happen to agree with your instructors. Moodle should be full-width. If you have students who prefer a narrower width (as you do), they can narrow their browser window. Since Moodle is "responsive," it will adapt to the screen width, which I think supports your idea of accessibility and readability. I could be wrong, but seldom on Internet websites do I see a page purposely designed using wide margins, fixed-width, for content, as Moodle 4 does it. I was puzzled by Moodle 4 design, so I added CSS to go full-width.
Average of ratings: Useful (2)
In reply to Rick Jerz

Re: Some of our users are doing horrible things with Javascript

by Brett Dalton -
Picture of Moodle HQ Picture of Particularly helpful Moodlers
Part of the reason for the current design for the main course pages is accessibility. WCAG 2.2 SC 1.4.8 indicates that text blocks should be below 80 characters for accessibility reasons. having wider pages leads to people designing for wider pages or pages needing to be scrollable horoizontally which is then breaking 2 success criteria. Making content in RTE responsive is difficult for instructors. In some areas scrolling is unavoidable (gradebook) but there are alternate views to acomodate users here.

https://www.w3.org/TR/WCAG22/#visual-presentation

That all said there are opportunities where we can be taking better advantage of the available screen space, when editing, when submitting assignments and similar. Where it makes sense the UX and PX teams are looking to make changes here.
In reply to Brett Dalton

Re: Some of our users are doing horrible things with Javascript

by Rick Jerz -
Picture of Particularly helpful Moodlers Picture of Testers
At first, Brett, I would say, "Now I understand." However, when a web page is designed as "responsive" as Moodle is, we don't seem to need to worry about horizontal scrolling. A "responsive" design does not display a horizontal scrollbar. Am I missing something?
 
Also, I wonder if a solution would be to have a user setting for "full width," or "turn all accessibility features on" would be a solution.  Then the student could control whether or not they need some of these restrictions.
In reply to Rick Jerz

Re: Some of our users are doing horrible things with Javascript

by Brett Dalton -
Picture of Moodle HQ Picture of Particularly helpful Moodlers
Responsive design of Moodle doesn't extend to user generated content if its also not designed to be responsive, essentially its really easy to build badly behaved pages that will cause the layout to break and end up with horizontal scrolling. This is not a trivial problem.  

Blackboard and D2L constrains content to approx 100 chars max width.   Blackboard does reflow when its narrower but their editor is intentionally limited block editor to make this easier.  D2L doesn't reflow when the screen is narrower.  Canvas constrains to approx 320 charaters width and thier editor reflows content really well but its taken them 5+ years and a dedicated product and enginering team to get it to that point.  I know the product manager on that project well, he's an old friend, and was involved with parts of it when I was working there.  Even with all that effort the excessive width issue is something that they have had complaints about.  If you visit their WCAG page (https://www.instructure.com/en-au/products/canvas/accessibility) Success Criteria dealing with this (Visusal presentation 1.4.8) is not listed or referenced at all because it doesn't pass even with their excellent reflow capability.

Hope the visual examples help

Blackboard - standard (content page)





Blackboard - Content page narrow




BrightSpace (D2L) (course page) 





Brightspace Content page 




D2L - Narrow



Canvas super wide  (this is a problem)




In reply to Lexy Walker

Re: Some of our users are doing horrible things with Javascript

by Dominique Bauer -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers
... and I really like it.

Whether an administrator is a fan of it or not doesn't really come into play here. What truly counts is meeting the needs and desires of our wonderful teachers, the users. When it comes to Moodle content, it's not just about squeezing everything into 80 characters. Take question types, for example; they often require much more room than the current 830px width allows. And as for concerns about security when adjusting width in the DOM, trust me, Moodle has got that covered! smile

In reply to Dominique Bauer

Re: Some of our users are doing horrible things with Javascript

by Rick Jerz -
Picture of Particularly helpful Moodlers Picture of Testers
Remember that (at least in the U.S.) it is many school administrators who are picking other LMSs (e.g., Canvas) over Moodle because it is making their lives easier (i.e., a simpler LMS requires less IT support.) I can say this from personal experience at two different universities where I taught.
In reply to Dominique Bauer

Re: Some of our users are doing horrible things with Javascript

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I thought that the end users were the students? We've been monitoring this and nearly all (85%) of our students access Moodle on mobile devices. So, I'm struggling to see why supporting huge monitors is a thing.

Anyway, I think the OP's point was that it was *possible* to do things like that. Not, whether it's a good idea assuming that you can.
In reply to Lexy Walker

Re: Some of our users are doing horrible things with Javascript

by Michael Hawkins -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Testers
Hi Lexy,

There are risk flags associated with some capabilities, where they allow greater freedom to perform actions, in this case the "Risk XSS" flag, which is marked on capabilities where they allow someone to insert JavaScript on a page. If you log in as an administrator and navigate to Site administration > Users > Permissions > Define roles and click on Teacher, you can scroll down the list of capabilities teachers have and see the risks associated with them (if any) - the red triangle with the exclamation (XSS risk) identifies capabilities which allow JavaScript to be used. Risks of this nature are reserved for "trusted/elevated" users such as teachers and managers by default (and not students). The types of capabilities associated with this are generally things like the ability to add and update course and activity information/settings, and one of the reasons this was originally implemented was to allow teachers to enhance their course content with multimedia that may require JavaScript to embed/enrich the content (there are some details around this in the Security FAQ docs).

The "Trust submitted content" capability requires the "trusttext" feature to be enabled on the site (it is disabled by default), but the way it is implemented is not a global check that users without that capability cannot insert JavaScript anywhere (so not having that capability generally won't override the XSS risk capabilities teachers otherwise have). The way it works is more like users who do have that capability gain additional access to insert JavaScript in certain places where it is otherwise removed, but only where that feature has been implemented. The Trusttext cleaning bypass docs go into some more detail about this, including a list of some of the places where "trust submitted content" is implemented.

There isn't currently a way to give someone a capability with their known risks removed (eg the ability to change the course summary, without the ability to include the risk/XSS flag and allow JavaScript), however it's an area we're interested in exploring some more in the future as the security landscape of the internet evolves (it requires quite a bit of investigation and analysis, because it's quite a complex topic with a lot of considerations). One of the existing Tracker issues proposing this type of granularity is MDL-71102. If it is something you think adds value, it would be great if you can give that issue a vote, which helps show whether a feature has some demand from the community.

I hope that information and the documentation I've linked to help answer your questions.

Mick
Average of ratings: Useful (1)