Iframe Attacks and Preventions

XSF (Cross-Frame Scripting)

Attack

The attacker loads DM into an iframe on a page they control, tricking users into navigating to and interacting with the page and allowing them to then steal information, for example, keystrokes for login.

Prevention

The presence of a strong CSP in addition to XFO headers by default prevents this form of attack. To allow the integration to work this must be relaxed, however, specifying the Dynamics domain as the only allowed ‘parent’ for the iframe (XFO/Frame-Ancestors) ensures that only Dynamics can iframe DM.

In addition, with the SSO integration enabled, a user never interacts with DM in order to authenticate – this is entirely handled externally, therefore removing any window of opportunity in which an attacker may intercept the input of credentials.

Iframe Injection

Attack

Where the origin site is loading third-party content, the attack involves a library carrying a malicious payload that then injects an iframe, or any attack that uses an iframe, as an injection channel to deliver the malicious payload.

Prevention

The iframe content is the DM application only, no third-party content other than the trusted libraries used within the application is used. DM utilises a CSP that restricts iframe content to its own origin therefore preventing malicious injection.

Clickjacking

Attack

The attacker loads legitimate content into an attacker-controlled site within an iframe and overlays interception layers on top with the intent to either capture input or redirect the user who believes they are interacting with the attack target.

Prevention

As with XSF and iframe injection, correctly defined CSP and XFO headers prevent this.

Cookie Abuse

Attack

Any attack in which the third-party cookies from the target site can be intercepted, read, or implicitly reused to affect an attack.

Prevention

Browsers have supported the ‘SameSite’ attribute on cookies for some time and recent shifts in security posture mean that modern browsers now default to the value of ‘lax’ when not explicitly set.

This would provide the first line of defence against cookie misuse, however, as the DM application is used from within an iframe it must be set to ‘none’. This allows the authentication cookies to work in the context of cross-site interactions, therefore removing this preventative measure.

However, DM marks authentication cookies as ‘secure’ ensuring they must be transferred over a secure channel to avoid MitM attacks. It also marks them as ‘httponly’ ensuring they cannot be read from scripts, and finally a robust CSRF token mechanism is present. The latter being the older, more typical means of preventing any of the attacks that would otherwise be controlled with the SameSite cookie attribute means that these attacks are prevented.