Hi, I asked Sid about this and he pointed out that since the CSP is stored on the principal, if the data document inherits the principal of the app, it will inherit the CSP...
The violations in the log in the bug are all style-src violations along the lines of : E/GeckoConsole( 423): [JavaScript Warning: "CSP WARN: Directive style-src app://email.gaiamobile.org violated by http://addons.books.com.tw/G/auto_activity_new/act0000037/green_yellow.css what's the name of the 'loaded as data' flag ? I can look at the nsIContentPolicy/CSP code to see if it's checked. thanks, ian ----- Original Message ----- From: "Jonas Sicking" <[email protected]> To: "Andrew Sutherland" <[email protected]>, "Ian Melven" <[email protected]> Cc: [email protected] Sent: Friday, November 30, 2012 10:17:13 AM Subject: Re: [b2g] CSP erroneously being applied to data documents? (email sanitization) On Nov 30, 2012 5:09 AM, "Andrew Sutherland" < [email protected] > wrote: > > For the e-mail app, our HTML sanitization mechanism relies on creating > documents by using document.implementation.createHTMLDocument('') so that we > can use the system HTML parser. It is my understanding that the document > should be flagged as "loaded as data" so that, regardless of CSP, remote > style files should not be loaded, nor JS scripts run. Our sanitization pass > is then able to run over the DOM tree and discard everything that is not > whitelisted. > > Preliminary investigations by Steve Chung are that the CSP rules are being > applied to this data document and this is breaking the e-mail app. > https://bugzilla.mozilla.org/show_bug.cgi?id=816922 has been filed on this > issue. > > So my questions for the CSP / parser gurus are: > > 0) Are we badly confused about the "loaded as data" flag? Note that in order > to get Gecko to parse stylesheets, we cannot just create an orphaned DOM node > in the document (document.createElement without appendChild/insertBefore), so > we are injecting HTML into the document proper. You seem to have a correct understanding of data documents as far as I can tell. > 1) Are CSP rules expected to be applied to "loaded as data" documents? (I am > assuming that document.adoptNode and document.importNode can serve as the > firewalls to avoid evil DOM nodes sneaking in the back door.) I guess it depends on what you mean by "applied"? I would definitely expect that data documents don't issue network requests that aren't permitted by CSP. But then again, data documents are generally prevented from issuing network requests so that shouldn't make a difference really. Likewise I wouldn't expect inline <script>s to execute. But that too is blocked by venereal data document policies. But in both cases I would expect the DOM to remain unaffected by these limitations. I.e. I would expect src attributes to still be there even if the network request is blocked. And I'd expect the <script> element to still have text node children. So what behavious do you see changed that you are attributing to CSP? Potentially inline CSS would behave differently. Is that what you are seeing? Is so, exactly what are you seeing? I'm by no means an expert on CSP so cc'ing Ian who is. > 2) Should we be doing something different for sanitization? Using createHTMLDocument and parsing into that probably doesn't give 100% accurate parsing when it comes to dealing with various rules around handling of parsing of top-level elements like <head>, and <body>, but that seems like an orthogonal concern. I don't think that we have DOMParser hooked up to HTML parsing yet. If we did you could probably use that to address those concerns. But that wouldn't affect any CSP issues. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
