A transition from IFrame sandbox to CSP Back

As security requirements of presented contents to avoid XSS vulnerabilities growing larger and larger, developers may need some technics to eliminate scripts like using sandbox with allow-same-origin and no allow-scripts in IFrames. Nevertheless, I recently found that, we can't do two things in such a frame under Safari or below Chrome 70:

• We can bind any event handlers upon nodes inside an iframe via accessing iframe.contentDocument but failed to run.
• We can't post any messages via iframe.contentWindow.postMessage.

In those two cases, browsers should throw an error:

[Error] Blocked script execution in 'xxx' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.

Certainly, there is also a snippet of POC to detect whether your browser will do so:

let sandboxInteroperable;
$('<iframe sandbox=allow-same-origin>').on('load', function () {
    $(this).contents().find('body').click(() => { sandboxInteroperable = 1; })[0].click();
    $(this).remove();
}).appendTo('body');

So in Safari and Chrome 70-, we need an alternative to solve the compatibility problem. That's script-src of Content-Security-Policy (CSP). Notice: choose it rather than csp of IFrame because of its better compatibility.

<!-- wrapper.html -->
<meta http-equiv="Content-Security-Policy" content="script-src 'none';">

If you can use service side rendering page to construct such a wrapper page, you can also choose a more compatible way to set CSP rather than <meta>:

<!-- wrapper.jsp -->
<%
    response.addHeader("Content-Security-Policy", "script-src 'none';");
    out.clear();
%>

Comments Copyright © aleen42 all right reserved, powered by aleen42

Empty Comments

Sign in GitHub

As the plugin is integrated with a code management system like GitLab or GitHub, you may have to auth with your account before leaving comments around this article.

Notice: This plugin has used Cookie to store your token with an expiration.

authorize