VIP Authentication HUB: Standard Angular Content-Security-Policy breaks IARISK device thumbprint script iadfp.js from Sample App
search cancel

VIP Authentication HUB: Standard Angular Content-Security-Policy breaks IARISK device thumbprint script iadfp.js from Sample App

book

Article ID: 254478

calendar_today

Updated On:

Products

VIP Authentication Hub

Issue/Introduction

Do you have an updated version of this thumbprint script but the script provided in the Sample App that calculates the device thumbprint for the IARISK engine relies on JS eval which is blocked by the standard Angular CSP

https://angular.io/guide/security#content-security-policy

Environment

Release : October.01.2022

Resolution

Q&A

 
 
Not sure if you have an updated version of this thumbprint script but the script provided in the Sample App that calculates the device thumbprint for the IARISK engine relies on JS eval which is blocked by the standard Angular CSP 
 
Can you please let us know if there is a version available that is resolving this issue?
 
No.  
 
There is no version of the code that does not require a customized CSP policy if CSP is enabled in a header set by a server that serves the IaDfp JavaScript. 
 
Recommendation
 
My recommendation is: the customer set a CSP policy to allow 'unsafe-eval' of a nonce-qualified usage of the IaDfp JavaScript.
That is a customer configuration and script usage task.
It requires:
  • Appropriate settings in the customer application server to serve the appropriate CSP policy in the HTTP response headers or HTML meta-data.
AND
  • The HTML page created by the customer to source the IaDfp JavaScript needs to have an attribute in the script tag to specify a nonce reference by the CSP.
Background
 
According to the site linked by the customer: https://angular.io/guide/security#content-security-policy
 
The minimal policy required for brand-new Angular is:
default-src 'self'; style-src 'self' 'unsafe-inline'; 
 
As noted in the Angular documentation:
 
Angular itself requires only these settings to function correctly. As your project grows, you may need to expand your CSP settings to accommodate extra features specific to your application.
 
If you apply such a policy when referencing the IaDfp JavaScript, the JavaScript will fail because, for its internal working, it requires the use of JavaScript eval functions.
So you need to expand your CSP setting to accommodate the extra features provided by the IaDfp script.
 
To allow the IaDfp JavaScript to work, it is necessary to add the directive 'unsafe-eval'.
 
For instance, to do this globally, the following value can be set in the Content-Security-Policy HTTP response header returned by the server serving the IaDfp JavaScript:
default-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; 
 
To restrict the relaxation to only a provided script, then you can use a nonce which is just some randomly unique value, for more information, see https://content-security-policy.com/nonce/.
 
Here is an example of a CSP with a nonce "xyzzy" (the actual value doesn't matter, it should just be something unique):
 
default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'nonce-xyzzy' 'unsafe-eval';
 
This only allows unsafe eval for the script marked with the given nonce.
 
Additionally, the IA integration guide discusses some usages of IaDfp in calling pages where inline scripts are used.
Generally, inline scripts are prevented when a CSP is provided.
To allow the inline scripts to work, you can also place a nonce value in the script tag and reference it in the CSP.
 
Example
 
Here is a complete example, to test the policy.
 
To run this test, I set the following CSP policy as the response header (make sure not to set it as the request header) using the Chrome mod header plugin:
 
Content-Security-Policy: default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'nonce-frobozz' 'nonce-xyzzy' 'unsafe-eval';
 
And I served the following HTML page (and the accompanying iadfp_1.3.js script) from a local web server, which resulted in correct fingerprint generation.
 

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>Fingerprint data collection test</title>

    <script src="iadfp_1.3.js" nonce="xyzzy"></script>

</head>

<body>

<h1>Fingerprint Test</h1>

<p id="fingerprint"></p>

</body>

 

<script nonce="frobozz">

    IaDfp.setEnhancedFingerprint(true);

 

    setTimeout(

        function() {

            document.getElementById("fingerprint").innerHTML = IaDfp.readFingerprint()

        },

        200

    );

</script>

 

</html>

 
For instance, to do this globally, the following value can be set in the Content-Security-Policy HTTP response header returned by the server serving the IaDfp JavaScript:
 
Why this approach is likely OK
 
The CSP with google site provides advice on CSP settings and usage:
 
Regarding 'unsafe-eval', it states:
 
'unsafe-eval' allows the application to use the eval() JavaScript function. This reduces the protection against certain types of DOM-based XSS bugs, but makes it easier to adopt CSP. If your application doesn't use eval(), you can remove this keyword and have a safer policy.
 
However, we do use and require eval, so if CSP is used, this setting must be set.
 
The CSP with google site notes that when applied with a nonce and other recommended CSP policy settings, usage 'unsafe-eval' policy is appropriate as part of: 
 
A production-quality strict policy appropriate for most applications.
 
 
Content Security Policy (CSP) is a defense-in-depth technique to prevent XSS
 
The VIP and IaDfp JavaScript implement numerous (non-CSP) features to prevent XSS.