Ho una pagina padre che contiene una politica di sicurezza dei contenuti. Lo scopo principale di CSP non è quello di prevenire l'XSS, ma di impedire l'accesso alla rete. Questa pagina deve eseguire alcuni HTML / CSS / JS generati / inviati dall'utente. Sto eseguendo questo contenuto utente in un iframe utilizzando document.write per scrivere il contenuto dell'utente in questo iframe.
NOTA: il contenuto dell'utente che ho non è caricato o presente su un server ma è disponibile in modo dinamico, ad esempio utilizzando un modulo.
Desidero anche che il contenuto dell'utente erediti il CSP della pagina principale e qualsiasi iframe creato anche dall'iframe secondario.
Il criterio applicato agli iframe in base alle specifiche:
The policy of the embedding resource controls what may be embedded. The embedded resource, however, is controlled by the policy delivered with the resource, or the policy of the embedding resource if the embedded resource is a globally unique identifier (or a srcdoc frame).
Quindi, lo standard dice che la politica non sarà ereditata, perché la pagina madre non è un identificatore univoco globale. Non voglio usare iframe srcdoc per i seguenti motivi
- L'html può essere molto grande
- L'html deve essere sottoposto a escape per usare srcdoc che sembra inaffidabile e impuro.
- Supporto browser (Edge - in esame )
Ma c'è una svolta:
Quando ho continuato a testare questa ereditarietà sui browser, la csp veniva effettivamente ereditata su Chrome, Safari, Firefox ma non Edge. Questo per me sembra abbastanza logico e corretto.
Ecco il test di prova che ho eseguito:
<html>
<head>
<!-- CSP just for demo purposes - not the actual csp -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'unsafe-inline'; style-src 'unsafe-inline'"/>
</head>
<body>
<h1>Parent Content</h1>
<p style="font-weight: bold; font-family: arial, sans-serif;">
The image here will be blocked due to CSP (default-src directive).
However the iframe's image will not be blocked on Edge since the CSP is not inherited.
</p>
<img src="http://www.w3schools.com/html/pic_mountain.jpg"/><script>window.addEventListener("DOMContentLoaded", function() {
// creating the child iframe
// Some user controlled HTML content.
var html = "<html><body><h1>Child Content</h1><img src='http://www.w3schools.com/html/pic_mountain.jpg'/></body></html>";
var iframe = document.createElement("iframe");
iframe.setAttribute("height", "400px");
iframe.setAttribute("width", "400px");
document.body.appendChild(iframe); //need to append first to be able to write into the iframe.
var iframeDoc = iframe.contentWindow.document;
iframeDoc.open();
iframeDoc.write(html);
iframeDoc.close();
});
</script>
</body>
</html>
Quindi, finalmente le mie domande sono:
- Posso contare su questa ereditarietà di CSP su iframe figlio su Chrome, Firefox e Safari? - Non riesco a trovare questo documento ovunque.
- Esiste un modo pulito e affidabile per essere in grado di utilizzare srcdoc con escaping e tutto il resto? Quali sono gli impatti delle prestazioni dell'uso di srcdoc?
- C'è qualche altro metodo per farlo?
Altre riflessioni:
La gestione delle specifiche (e dei bordi) del CSP che si applica all'iframe aumenta ulteriormente il rischio di consentire "inline-in-safe" per gli script per impedire l'XSS. Perché in questo caso l'autore dell'attacco può persino utilizzare document.write in questo modo per attivare anche la creazione di iframe nel proprio sito dannoso. Anche child-src / frame-src 'none', non interrompe la creazione di iframe usando document.write . Non è molto brutto per sicurezza?