Show Advanced KnowledgeHide Advanced Knowledge

Higher level of security for HTML content

1 Initial Problem

» Often, animations are required for learning materials. These animations are included to content pages as media objects
» The use of flash is undesirable for safety and inventory reasons of the technology.
» Therefore, a conversion of all Flash animations to HTML/HTML5 animations followed.
» Integration and playback of HTML/HTML5 content must be regulated globally in ILIAS. Decisions are thus far-reaching.

On the other side uploaded html content can impose a security risk, since the code or embedded scripts can contain malicious content (like cross-site-scripting, "bad" jscript)

There are currently two configurations form media objects in ILIAS (distinct from file upload settings):

1. HTML content is prohibited. No potential security hole. Nobody can upload HTML. Existing HTML content in media objects is not delivered to client's browser. The objects fail silently, when playing the content (e.g. from a learning module), the page remains white with no sign of content that was not delivered.
2. HTML content is allowed. Anyone can upload HTML in the form of media objects in ILIAS, if access to the page editor or mediapools is granted. It creates opportunities for any user to introduce malicious code. This is not a big problem when creating learning modules or media pools with few, trustworthy authors. But when enabling features like personal protfolios or blogs, nearly any user can upolad media content even without knowing about the risks. The same sitaution applies if admins have to import media content from sources they cannot evaluate.

There is no scaling option.

ILIAS also behaves as follows:

• HTML5 components that are imported when HTML is prohibited are renamed during upload (thsi was not tested in all cases, bit it seems that the files are renamed to .sec. If the html-content brings more files tham a single html source, some files are treated by the file upload regardless of the settings in media object administration (e.g. media objects with html are allowes, but other files in the opject containing .js are renamed without notice to the uploader.
• Subsequent ban on HMTL will not play the imported HTML on the server.

The ILIAS JourFixe has already dealt with this topic twice. This also applies to the Technical Board.
See Mantis #23169: https://www.ilias.de/mantis/view.php?id=23169 

and JourFixe Notes:

• Jour Fixe, 18 JUN 2018 : We will ask the Technical Board if the feature request mentioned above is still accepted for 5.4 to improve security or if it has to wait until 5.5.
• Jour Fixe, 02 JUL 2018 : The Technical Board decided that features that improve security can also be suggested after feature freeze. But the current suggestion is not accepted as a sound solution for the problem of uploading HTML content. A workshop about HTML content handling would be highly appreciated.

2 Conceptual Summary

First ideas:

1. Solution

• RBAC control for uploading HTML
• Advantage: only a few 'trustworthy' persons are allowed to upload. A playback would be possible at any time
• The upload of content can be granually controlled.
• Disadvantage: Implementation and maintenance may be very time-consuming. It requires a personal control.
• Disadvantage: Costs of code-additions and possible performance penalties when accessing objects

2. Solution

• So-called "subdomain isolation"
• Encapsulate the HTML5 content to execute the code, which would be in doubt, in a secure environment.
• Easier to handle than fist approach and probably possible with webserver's configuration
• Disadvantage & advantage: Elimination of the social component. No RBAC-control and communication with users about it.
• Disadvantage: subdomain isolation only works, if the html and scripting code loads elements from other pages and not from the local ILIAS server.  This solution only allows to harden against some "cross site scripting" attacks, but not against malicios code that is stored completely during update.

3 User Interface Modifications

3.1 List of Affected Views

(not complete yet): Solution 1 would introduce new RBAC Assignments, so all Interfaces showing media object rights would have new Elements like "allow html content in media"
Media object upload would need new error messages that tell users about invalid filetypes, like fiel upload does in some places.

3.2 User Interface Details

{For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour.}

3.3 New User Interface Concepts

{If the proposal introduces any completely new user interface elements, you might consult UI Kitchen Sink in order to find the necessary information to propose new UI-Concepts. Note that any maintainer might gladly assist you with this.}

4 Technical Information

{The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues.}

5 Contact

• Author of the Request: Samoila, Oliver [oliver.samoila], some additions by Jackisch, Ingo [jackisch]
• Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

6 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• crowdfunding should be possible.

7 Discussion

Jackisch, Ingo [jackisch] 2018-07-16: For dissemination of the current optes contents, html media objects are a need. (Reasonable!) Security concerns of admins may probhibit successful import of the html content.

Mersch, André [amersch] 2018-07-17: As Flash and Java are getting ever more seldomly used to create interactive graphics, html gets more and more common for this issue. To make those materials usable in ILIAS, a feature like the one proposed here is crucial.

From my point of view there should not be either solution 1 or 2, but both solutions or alternative operationalisations should be developed because they adress different necessities:

• the first necessity is to secure the content so that no malware can be included,
• the second necessity ist to be able to control who is allowed to include html code to prevent a chaotic content hazard (e.g. by users who think it might be a good idea to include their Wordpress Blog content in ILIAS folders).

The second necessity could be operationalised using the RBAC System or by creating a possibility to restrict the objects in which html can be included (e.g. only in ILIAS Learning modules and not in ePortfolios).

Killing, Alexander [alex] 23 July 2018: I think it could be feasible to drop script interpretation in page editor content (text paragraph elements) completely (as currently done in the wikis). It will be hard to put this under rbac control, since content is edited by users with different permissions. If you want to use JS/HTML you need to use media objects in all cases. And these will be served in a subdomain isolation context.

Hesse, Joel [Joel_Hesse] interested!

Schmitt, Pascal [pascal.schmitt] 5.7.21
one of the bigger security problems are probably iframes. this could be counteracted by the following idea: A white list is kept in the administration that contains urls that may be included via iframe. This way, the security is left to the institution/company, which is the right thing to do in my opinion.

8 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.