Request: The ability to whitelist servers from which external scripts are taken using <script> tags.

[LukeLongworth]

We are starting to look towards the future prohibition of <script> tags. Our question bank has several hundred STACK questions that rely on running the line <script src="..."></script> at the beginning of the question text. This is not possible with the proposed prohibition of <script> tags.

The ability for a Moodle site administrator to whitelist <script> tags to a particular server, or folder on a particular server, would solve all of our problems. Can this (or similar) functionality be added before script tags are disabled?

This would satisfy the security goals, as our scripts are stored on our server and modifications on our server are tightly controlled. Uncontrolled external sources would still be prohibited.

Here is one of the scripts that we use: https://apps.canterbury.ac.nz/1/math/online_resources/EMTH119/setup.js. This does the following:

1. Define CSS. We have the entire lecture content of 6 courses presented in "Learning Module" quizzes in a mixture of Description and STACK questions (and a few other question types). These Learning Modules are the primary form of content delivery for one course and the preferred form for many students in other courses. We need a variety of things formatted consistently across ~1700 questions.
2. Establish JSXGraph defaults (which we are moving to a separate script that can be run inside the JSXGraph IFRAME with [[include]], so this is no major issue)
3. Define custom LaTeX commands (for MathJax, again heavily used in the Learning Modules, and sometimes in other questions).

If we are unable to use <script> tags at all, we can only see the following as possible options:

• Manually setting all styling in html, and not using any custom LaTeX commands. This would be a mammoth task whilst also making us vulnerable to future changes that might require all questions to be edited again.
• Put all of the content in IFRAMEs whilst keeping the inputs outside the IFRAMEs. This is also impractical, in part because we often have scaffolded questions with content in between answer boxes, leading to a large number of IFRAMEs in individual questions which each have to load the script.
• Putting all of our CSS into our Moodle site directly, and not using custom LaTeX commands. This would then apply to (and be loaded for) all courses in the university, rather than just the relevant quiz pages. Again, this would be a mammoth task, and difficult for us to maintain/update.

We see the whitelist proposal as a simple solution that still addresses the security concerns. If anyone has any other suggestions we are keen to hear them.

[aharjula]

Well, that sure is a situation where we should support things, and your solution makes sense, so why not? It is not even technically hard to do. Funnily enough, it mirrors what is in plans for the <iframe>-ban, which would happen at the same time. In the world of <iframe> to [[iframe]], it has become apparent that certain commonly used things, like YouTube videos, do not work in those sandbox iframes, so a whitelist for the src-attribute there is a thing in planning there (well it was a leading candidate for the solution and now that you asked this it has become the winner as it would follow the same logic). As you are asking basically the same, this would not be difficult to provide.

While such whitelisting is something that can be circumvented if one can use social engineering to modify the whitelist, it is still probably safe and allows us to be, by default safe. We cannot build a system that would be safe from all users that have enough rights.

In general, this is what I would expect the world to look like after the prohibition hits:

1. You cannot load active content into a question as an author unless it is whitelisted or executes in a sandbox provided by us.
2. As whitelists are defined at the system level by system admins, we can provide a security reminder next to the settings. If the whitelists allow externally sourced stuff, we simply give up and hope that no one messes with the DNS or otherwise can inject stuff between the machines in the picture. Those wishing to fight that fight can apply signatures and extra CORS rules to their whitelisted inclusions through other means.
3. When we run the filter that applies these rules, it will parse the output for both <script> and <iframe> tags and do as follows:
   1. If a <script> tag with any content other than white space is found, it will be banned.
   2. If a <script> or a <iframe> tag with a URL that does not belong to the relevant whitelist is found, it will be banned.
   3. Banning means inactivating the tag by turning it to entities and placing an error message on the page pointing to the documentation telling why it was banned.

Case 3.i. above forbids inline code and is not a negotiable one. While in theory, we could allow signed code from whitelisted signatories, in practice, that is overly complicated and will not be feasible when simply opening stuff in an editor may mess up the code and, thus whatever checksum it has.

From the administrator's point of view there would then be three new settings:

1. The whitelist for <script> sources, which is probably going to be a comma-separated list of acceptable prefixes. Just to keep things sane, I will probably make sure that all items in this list have at least three / characters in them so that no one can turn the whole feature off by giving this the value "http://,https://". Whether we will have a way to declare a full match pattern as opposed to a prefix is still an open question, but for those who really want to play it safe, that might be a thing.
2. Same for <iframe> sources.
3. For a transition period, there will be a selector that can be used to disable this whole security system, by default, the system will be on, and eventually, that option will disappear.

[LukeLongworth]

Thanks for the prompt and detailed response Matti, that all sounds very reasonable to me! This gives us some much appreciated certainty.