UI5 resource integrity
Recently I developed a standalone OpenUI5 app. An app that is accessed without a Fiori Launchpad and has its own index.html on the web server. Of course, I develop the app using a pipeline. And of course, one of the steps is to get the source code analyzed for issues. I use SonarQube for this and it reported me a security issue.
The app is not using the resource integrity feature when loading OpenUI5 from the CDN. The problem reported is: “Fetching external resources, for example from a CDN, without verifying their integrity could impact the security of an application if the CDN gets compromised and resources are replaced by malicious ones.”
The whole script block is marked as related to the issue. If you do not know what the resource integrity feature is, SonarQube shows some information about it and also how to fix this problem.
Resource integrity allows the browser to check if the resources loaded from an external site are the same the developer expects them to be. This is a security feature that allows the developer to assure that an external loaded resource is not changed, for instance, by an attacker to inject malicious code. This is done by calculating a hash value for the resource, store this in the app and let the browser check if the loaded resource has the same hash value. If not, the resource is not loaded as the browser will consider it contaminated.
The example here is using a fixed version (e.g. 1.92.0) of OpenUI5. The latest version can also be used automatically by not referencing explicitly a version. Using default version (latest):
These examples do not include the integrity option. Copy & paste the example for CDN usage from OpenUI5 documentation will lead to the above mentioned SonarQube security issue.
Calculating resource integrity hash
Mozilla has more information on this topic: Subresource Integrity. That page contains some hints on how to generate the needed SRI hashes. As SRI is nothing else than a hash with the used hash algorithm, the SRI hash can be generated locally via OpenSSL. As an alternative, the Mozilla page contains a link to an online tool that can be used to generate a valid SRI hash.
The SRI Hash Generator is easy to use. Just provide a link to the resource, select the hashing algorithm and the script tag to be used in the HTML file is generated.
Enter the link to the resource, e.g. sap-ui-core.js
Click on hash and the tool will generate a SRI hash for the provided resource. The script tag can be copied and used in the HTML file of the app.
<script src=https://openui5.hana.ondemand.com/1.92.0/resources/sap-ui-core.js integrity="sha384-U+twGwGPL4f0M1CYUBYWH2B3YmXhSrzGW/9+QR4g2DRqQ9TGE1Ra3hxp7AoUFAJZ" crossorigin="anonymous"> </script>
The SRI for OpenUI5 1.92.0 is: sha384-U+twGwGPL4f0M1CYUBYWH2B3YmXhSrzGW/9+QR4g2DRqQ9TGE1Ra3hxp7AoUFAJZ
Make sure to include the crossorigin=”anonymous” part too. If not, the browser won’t be able to verify the integrity.
Include the additional information in the HTML file and SonarQube won’t report the SRI issue again.
<script id="sap-ui-bootstrap" src="https://openui5.hana.ondemand.com/1.92.0/resources/sap-ui-core.js" integrity="sha384-U+twGwGPL4f0M1CYUBYWH2B3YmXhSrzGW/9+QR4g2DRqQ9TGE1Ra3hxp7AoUFAJZ" crossorigin="anonymous" data-sap-ui-theme="sap_fiori_3" …> </script>
Does it make sense?
Including the integrity to ensure that the correct version is loaded makes only partially sense for UI5. The integrity check is for the sap-ui-core.js file only. As UI5 is loading dynamically libraries as needed, these additional resources are not checked. If these are compromised, the browser won’t be able to notice this. SRI can only be used for a tagged UI5 version. Using always the latest version means that the hash will change every time the latest version is updated in the CDN. If this happens – and it happens constantly – the browser will stop loading the UI5 library and break the app. If you cannot ensure to roll out a new version of the app fast enough for this not to happen, SRI on the latest version will break things. For instance, the hashes for 1.84.15 and 1.84.16 differ and each have their own unique SRI hash:
- 1.84.15: sha384-hJOWZTXtKOIJgBd/VA07oug+C4Se08x0BGUHR106udzsc8yK7GHxAj1K85feaiju
- 1.84.16: sha384-77nrh/1Ew4Uo38VRqzN5DuGQzTBSUFZ5iW9dg98a8nd5Av2t4zL9eQQZ0S1dER2i