CSP: "local schemes" should inherit policy when embedded.

third_party/WebKit/Source/core/dom/Document.cpp

Index: third_party/WebKit/Source/core/dom/Document.cpp
diff --git a/third_party/WebKit/Source/core/dom/Document.cpp b/third_party/WebKit/Source/core/dom/Document.cpp
index 7755997f837a5574ff44bf827390c9cfa208929d..866a4297d46b4efd6acff8f0ee464709ae85240e 100644
--- a/third_party/WebKit/Source/core/dom/Document.cpp
+++ b/third_party/WebKit/Source/core/dom/Document.cpp
@@ -364,19 +364,6 @@ static inline bool isValidNamePart(UChar32 c) {
   return true;
 }
 
-static bool shouldInheritSecurityOriginFromOwner(const KURL& url) {
-  // http://www.whatwg.org/specs/web-apps/current-work/#origin-0
-  //
-  // If a Document has the address "about:blank"
-  //     The origin of the Document is the origin it was assigned when its
-  //     browsing context was created.
-  //
-  // Note: We generalize this to all "blank" URLs and invalid URLs because we
-  // treat all of these URLs as about:blank.
-  //
-  return url.isEmpty() || url.protocolIsAbout();
-}
-
 static Widget* widgetForElement(const Element& focusedElement) {
   LayoutObject* layoutObject = focusedElement.layoutObject();
   if (!layoutObject || !layoutObject->isLayoutPart())
@@ -5433,7 +5420,15 @@ void Document::initContentSecurityPolicy(ContentSecurityPolicy* csp) {
     ContentSecurityPolicy* parentCSP = toLocalFrame(m_frame->tree().parent())
                                            ->document()
                                            ->contentSecurityPolicy();
-    if (shouldInheritSecurityOriginFromOwner(m_url)) {
+
+    // We inherit the parent frame's CSP for documents with "local" schemes:
+    // 'about', 'blob', 'data', and 'filesystem'. We also inherit the parent
+    // frame's CSP for documents with empty/invalid URLs because we treat
+    // those URLs as 'about:blank' in Blink.

[dcheng, 2016/11/04 18:11:28]

So I'm not sure what we /should/ do, but some interesting scenarios:

One thing Blink gets wrong is the origin of about:blank: it's supposed to be
inherited from the initiator, not the parent. I do plan on fixing this at some
point; at that point, does it make sense for CSP to inherit from the parent or
the initiator?

Similarly, for blob and filesystem URLs: they could be different origin from the
parent frame, right? So should they be inheriting the CSP from their creator or
their parent?

[Mike West, 2016/11/18 11:06:23]

As currently specified, I think we'd end up inheriting from the parent. I think
I agree with your implication that we ought instead inherit from the navigation
initiator.

Today, though, we inherit from neither: that's certainly wrong, and I'd like to
fix it, as it's a fairly straightforward bypass.
Can they? I thought we blocked navigation to cross-origin blob:/filesystem:
URLs.
Same answer as above.

+    //
+    // https://w3c.github.io/webappsec-csp/#initialize-document-csp
+    if (m_url.isEmpty() || m_url.protocolIsAbout() || m_url.protocolIsData() ||
+        m_url.protocolIs("blob") || m_url.protocolIs("data")) {

[dcheng, 2016/11/04 18:11:27]

I notice filesystem isn't in this list, though it's in the comment.

[Mike West, 2016/11/18 11:06:23]

I had `data:` twice, though, so that's got to count for something. :)

       contentSecurityPolicy()->copyStateFrom(parentCSP);
     } else if (isPluginDocument()) {
       // Per CSP2, plugin-types for plugin documents in nested browsing