IRSS: User Content Isolation

1 Initial Problem

ILIAS stores files uploaded by users and derived versions thereof (such as preview images/thumbnails or converted versions in other image formats) in the ILIAS Resource Storage Service (IRSS). Currently, these resources are usually delivered in such a way that the client uses the same host/cookie domain (e.g. images come from docu.ilias.de, the same domain as the page itself) as the application. This poses several security and operational risks:

In short: Untrusted user content must be served isolated from the main application origin — best practice for this is a separate (sub)domain / sandbox domain or a cookieless host strategy. This reduces the risk of user-uploaded files compromising the main application.

2 Conceptual Summary

Objective: Introduction of optional, configurable subdomain isolation for all IRSS assets, delivered via the existing token-based signed delivery (FileDelivery).
Core idea:

In short: use of the existing IRSS/token infrastructure — only the delivery path (host) and token validation are extended so that resources are cleanly separated from the application origin. This approach complies with OWASP recommendations (‘use an isolated server with a different domain to serve uploaded files’) and modern best practices (sandbox/sandbox domains).

2.1 Technical possibilities and potential implementation

2.1.1 Goals / requirements

2.1.2 Architecture — Variants

There are generally two possible architecture variants for achieving the objectives. For the sake of completeness, both are briefly explained below. However, as we do not want to and cannot introduce a specific dependency on an existing CDN service in ILIAS, only one approach will be pursued further.

Proxy mode (app-hosted asset subdomain)

Direct mode (content delivery network CDN / object storage + signed URLs)

The main problem is that we do not want to store ILIAS data in a CDN and we also do not want to bind ILIAS to one or more CDNs.

2.1.3 Implementation of proxy mode

Extension of SignedDelivery

A new administration tab is set up in ‘File Services’ for file delivery and, in particular, signed delivery. This allows subdomain isolation to be activated via a form, while also entering a domain used for content delivery.

The title of the tab may vary: If additional features related to file delivery in ILIAS are added that also have settings in the administration, the tab could be called ‘Downloads’. If only the User Content Isolation feature is implemented, the tab would be called ‘Domain Isolation’.

If activated, this setting is included in the following services:

The FileDelivery service then uses the defined ‘domain for delivery’ (content domain) instead of the current domain by default when generating embed URLs. All resources integrated by the IRSS (consumers), for example, automatically receive a URL to the content domain instead of the ILIAS domain as was previously the case. Consumers of the services therefore do not need to make any adjustments.
The settings must be stored as a PHP artefact: The FileDelivery service works without sessions and initialises only a small part of ILIAS (e.g. HTTP service) in order to deliver files as efficiently as possible. This means that the database, for example, is not available in the context of file delivery. By using a PHP artefact, the settings can be read in without any further dependencies:

<?php return array (
  'si_activated' => true,
  'si_domain' => 'https://test11.iliascontent.de',
  'ilias_domain' => 'https://test11.ilias.de',
);

This also ensures that content is only delivered if it is obtained via the correct domain. If content continues to be obtained via the ILIAS domain, the FileDelivery service may refuse delivery or respond with an HTTP 404 (Not Found) error.

HTTP service adjustment

The HTTP service is extended so that ILIAS sends the appropriate headers to allow content to be loaded from the content domain (if necessary. ILIAS only sends headers that are absolutely necessary). This is particularly relevant for content embedded via iFrame, such as HTML learning modules, but also media objects, depending on the context.
The customisation particularly concerns so-called CORS headers. Although these are not relevant for images, they may need to be set correctly for files such as .css, .js, .html, etc. so that integration into ILIAS from an alternative domain works. These are usually headers that system administrators set up directly on the server. In order to enable the subdomain isolation feature with as little configuration effort as possible, relevant headers are already set where possible. In addition, it is necessary to check whether, when the feature is activated, instructions can be generated dynamically in the administration section as to which headers need to be set up on the ILIAS server and for the content ‘server’.

Adjustments \ILIAS\Init\Environment\HttpPathBuilder

The HttpPathBuilder checks as a security feature that the current domain through which ILIAS is accessed is valid. (These are currently configured in the database in ‘settings’ as ‘allowed_hosts’.) Since the database is not available at the time of file delivery, the content domain setting must be introduced elsewhere.

Adjustments to be checked

The communication of SCORM learning modules with ILIAS must be tested in a proof of concept. Since SCORM modules communicate directly with the surrounding player (across the iFrame boundary), further adjustments may be necessary here. However, this is only relevant once SCORM modules are migrated to the IRSS and can therefore also be delivered via the new FileDelivery.
It is also necessary to check whether outdated security and file delivery services can be adapted (e.g. WebAccessChecker), as some components continue to use these services. On the one hand, this reduces the urgency of converting these components. However, for security in general, it would be advantageous if these files could also be loaded from a content domain. It must be clarified whether this is possible and whether it is possible without adapting the components that use them.

Prevent ILIAS use via content domain

Since the content domain is only used for the delivery of files, the ILIAS installation should not be regularly accessible via this domain. Options and behaviour still need to be worked out.

Prevent content delivery on the main domain

When user content isolation is enabled, content (e.g. images) requested directly via the ILIAS domain should no longer be delivered.

Adjustments to the server infrastructure

An additional domain including a server certificate must be set up on the existing infrastructure. This VHOST must point to the same ILIAS installation as the ILIAS domain.

In principle, subdomain isolation can be implemented in ILIAS at a reasonable cost. By using the current services, delivery via an alternative domain in proxy mode can be implemented for at least some of the user-generated content (using the new FileDelivery, e.g. for files from the ILIAS Resource Storage Service).
The effort involved in setting up subdomain isolation tends to lie more on the side of the server administrators. An additional domain must be set up and maintained, ideally one that is different from the ILIAS domain (e.g. iliascontent.de vs. Ilias.de). Appropriate server certificates must also be created for this domain or these domains. For larger institutions, however, this does not usually represent a significant financial or administrative burden.

 

3 User Interface Modifications

3.1 List of Affected Views

3.2 User Interface Details

See Mockup above, a simple Form to activate the User Content Isolation.

3.3 New User Interface Concepts

The feature is implemented with existing UI components and does not introduce any new UI concepts.

3.4 Accessibility Implications

The use of existing UI components does not introduce any new implications for accessibility.

4 Additional Information

4.1 Involved Authorities

If this request is related to multiple components, please list both authorities for all related components.

4.2 Technical Aspects

As mentioned above, we ensure that the headers are already set by ILIAS – if necessary – so that the feature works on the server without any further configuration.

4.3 Privacy

No new personal data is collected or processed as a result of the implementation of the feature.

4.4 Security

The implementation of the feature does not introduce any new attack vectors. there are no further special security-related considerations to be made.

4.5 4.5 Contact 

Person to be contacted in case of questions about the feature or for funding offers: Lorenz, Katharina [klorenz]

4.6 Funding

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

5 Discussion

<?php return array (
  'si_activated' => true,
  'si_domain' => 'https://oops-this-string-was-not-escaped.and-contains' . (PASTE-MALICIOUS-CODE-HERE-THAT-RETURNS-EMPTY-STRINGS) .'.de',
  'ilias_domain' => 'https://test11.ilias.de',
);

6 Implementation

Feature has been implemented by {Please add related profile link of this person}

6.1 Description and Screenshots

{ Description of the final implementation and screenshots if possible. }

6.2 Test Cases

Test cases completed at {date} by {user}

6.3 Privacy

Information in privacy.md of component: updated at {date} by {user} | no change required

6.4 Approval

Approved at {date} by {user}.