Skip to content

Latest commit

 

History

History
39 lines (29 loc) · 2.24 KB

sandbox_to_csp.md

File metadata and controls

39 lines (29 loc) · 2.24 KB

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();
%>