Show Advanced KnowledgeHide Advanced Knowledge

Content-Security-Policy

If you need any help in filling out this wiki page, please visit our ILIAS Community FAQ. And please complete the metadata information in the right column after having created the page.

1 Initial Problem

Most of the productive ILIAS systems are host to groups of not completely vetted content editors, which are thus able to integrate any kind of external data (e.g. iFrames) into the systems GUI. There is no global option avialable to ensure the trustworthiness of content elements through validation. This allows i.e. Study Tutors to integrate Google-Maps Frames into their customizable pages, circumventing eventually that this feature is not enabled and not permitted by the ILIAS Core, due to organizational requirements.

The general acceptance of content from people who are not highly aware of - and how - data security matter, has a detrimental effect on the security level for the whole site.
These issues provide a generally vulnerable state of the system and enable the possibility of XSS attacks and worse: It is impossible for ILIAS to ensure the users security with on-board means, when these customizable contents, which may have a bad effect on the security of the installation, are required to remain available to the users, tutors, authors and admins.

2 Conceptual Summary

To mitigate this vulnerability, this feature request proposes the implementation of the Content-Security-Policy header, which can be configured via the ILIAS Administration. Such a header contains a whitelist of trustworthy origins and blocks suspicious origins preemptively. Through this, it prevents external sources from communication with the user, when it is attempted to be integrated into views inside the ILIAS GUI.

It is already possible to implement the header inside the server configuration. This provides some unnecessary workflow, especially when the jurisdiction of hosting and content-management are not within the same institution. Since it is the content-management institution which most likely detects insecure content, it doesn't have the means to properly address them. This causes unnecessary expenditures in time and effort for communications and change-management with the hosting institution. Also it can delay addressing critical insecurities after detection.

With a configuration in the realm of the content-management institution, this expenditures can be reduced and critical vulnerabilities can be avoided in a timely manner after detection.

2.1 How does CSP work?

The CSP header is supported by the majority of all modern browsers. 
The header itself contains a list of source types which enumerate a whitelist of allowed sources.

When sent within the response, the header provides the browser rules for all further requests (not only scripts but also images, styles, fonts etc.) and blocks and reports all connections to sources not whitelisted.

CSP can be configured for different resource types like:

• default-src
• script-src
• img-src
• style-src
• font-src
• ...

The types are set up as a list separated by ";" as delimiter and no enclosures.

The types can be configured with following elements:

• URL (e.g. https://maps.google.com) 
• URL patterns (e.g *.google.com , https: or www.google.com:443)
• keywords (e.g. 'self' matching all sources from the same origin as the header or 'none' matching nothing)

Beside that, there a few more configuration options e.g. 'unsafe-eval' which allows functions that generate code from strings (like the eval function in js) for the src type.

The type-specific configuration is a list with no delimiters and no enclosures.

It is not possible to blacklist sources.

2.1.1 inline-script handling

CSP provides some additional configurationoptions for the script-src type. By default, all inline scripts are disabled and will not be executed. There are three options for the type-specific configuration, which specify this rule by defining positively how to handle script injections:

'unsafe-inline'

• This configuration allows all inline-scripts which request content that does not contradict the src-script configuration itself.

hashes e.g. 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8='

• This configuration allow the inline-script the hash matches for.
• The possible hash algorithm is given as a prefix.
• Allowed aglorithms are sha256, sha384 and sha512.

nonce e.g. 'nonce-2726c7f26c'

• This configuration allows all inline-scripts that have a nonce tag with the same value as the provided configuration key.
• The key is not cryptic so its possible to use every valid string.

All of these configurations can be combined and re-used.
Examples:

script-src: 'self' 'unsafe-inline' 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8='

• This allows all inline-scripts to access only sources inside the page itself and allows 1 inline-script to access all sources.

script-src: 'https://www.example.com' 'unsafe-inline' 'nonce-googleMaps' 'nonce-Youtube'

• This allows all inline-scripts to access only sources from the page 'example.com' and allows all inline-scripts with the tag nonce="googleMaps" or nonce="youtube" to access all sources.

All three configuration are providing different security levels:

• nonce prevents most kinds of fuzzing and automatized script-injections. It does not prevent for smart or manual injections (e.g. by an Author) or complex automatized injections, since every human and program is potentially able to copy the nonce-tag to their own script. With a dynamic generation of the tag or other options, the security can be increased outside of CSP. But since there is no content validation of the script, the usage of nonce is not recommended since it lowers the security level of CSP itself massively.
• hashes provides a more secure way to handle exceptions inline-scripts, as long as their management is safe. The security level depends on the security level of the management itself (how easy is it to add my hash to CPS?). It is worth mentioning that the potential information capacity of the allowed hashes is smaller than the information capacity of most inline-scripts. Therefore it's not collision resistant and can be exploited in the future. The usage of hashes is a security improvement to nonce but still not recommended for use.
• unsafe-inline is the only recommended configuration, since its security depends on the CSP security.

Overall, the highest security level can be provided by not allowing inline-scripts at all, since it always represents a possible vulnerability to the user communication.

3 User Interface Modifications

3.1 List of Affected Views

• Administration / Privacy and Security

3.2 User Interface Details

3.2.1 Header Configuration

3.3 New User Interface Concepts

none

4 Technical Information

Since there is no no central location where all headers are gathered and sent its not possible to provide the 100% coverage needed for ILIAS to guarantee the given security of CSP at the moment. It would be beneficial to implement this junction inside ilias/Services/UICore/classes/class.ilGlobalPageTemplate.php::prepareOutputHeaders(), because this point should be reached by all ILIAS core responses.
Because sending headers can only be done once, the code sending headers must be cleaned up so content-specific responses (approx 30) have to be removed when the global sender is implemented.
This should not cause any issues, as long as the headers are added correctly to the response.

It is recommended providing at least C1 test coverage to guarantee the security standard.

5 Contact

• Author of the Request: {Please add your name.}
• 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.

• …

7 Discussion

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}.