Make content::FeaturePolicy implement WebFeaturePolicy, and use it in blink code

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

 /*
  * Copyright (C) 2011 Google Inc. All Rights Reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in the
@@ skipping 11 matching lines @@
  * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  *
  */
 
 #include "core/dom/SecurityContext.h"
 
 #include "core/frame/csp/ContentSecurityPolicy.h"
 #include "platform/RuntimeEnabledFeatures.h"
 #include "platform/weborigin/SecurityOrigin.h"
+#include "public/platform/Platform.h"
 
 namespace blink {
 
 SecurityContext::SecurityContext()
     : m_sandboxFlags(SandboxNone),
       m_addressSpace(WebAddressSpacePublic),
       m_insecureRequestPolicy(kLeaveInsecureRequestsAlone) {}
 
 SecurityContext::~SecurityContext() {}
 
 DEFINE_TRACE(SecurityContext) {
   visitor->trace(m_contentSecurityPolicy);
 }
 
 void SecurityContext::setSecurityOrigin(
     PassRefPtr<SecurityOrigin> securityOrigin) {
   m_securityOrigin = securityOrigin;
+  updateFeaturePolicyOrigin();
 }
 
 void SecurityContext::setContentSecurityPolicy(
     ContentSecurityPolicy* contentSecurityPolicy) {
   m_contentSecurityPolicy = contentSecurityPolicy;
 }
 
 void SecurityContext::enforceSandboxFlags(SandboxFlags mask) {
   applySandboxFlags(mask);
 }
@@ skipping 33 matching lines @@
 
   DCHECK(!suborigin.name().isEmpty());
   DCHECK(RuntimeEnabledFeatures::suboriginsEnabled());
   DCHECK(m_securityOrigin.get());
   DCHECK(!m_securityOrigin->hasSuborigin() ||
          m_securityOrigin->suborigin()->name() == suborigin.name());
   m_securityOrigin->addSuborigin(suborigin);
   didUpdateSecurityOrigin();
 }
 
-void SecurityContext::setFeaturePolicyFromHeader(
+void SecurityContext::initializeFeaturePolicy(
     const WebParsedFeaturePolicyHeader& parsedHeader,
-    FeaturePolicy* parentFeaturePolicy) {
+    const WebFeaturePolicy* parentFeaturePolicy) {
   DCHECK(!m_featurePolicy);
   // TODO(iclelland): Use the frame owner properties here to pass the frame
   // policy, if it exists.
-  m_featurePolicy = FeaturePolicy::createFromParentPolicy(
-      parentFeaturePolicy, nullptr, m_securityOrigin);
-  m_featurePolicy->setHeaderPolicy(parsedHeader);
+  WebParsedFeaturePolicyHeader containerPolicy;
+  WebSecurityOrigin origin = WebSecurityOrigin(m_securityOrigin);
+  m_featurePolicy.reset(Platform::current()->createFeaturePolicy(
+      parentFeaturePolicy, containerPolicy, parsedHeader, origin));
+}
+
+void SecurityContext::updateFeaturePolicyOrigin() {
+  if (!m_featurePolicy)
+    return;
+  Platform::current()->updateFeaturePolicyOrigin(
+      m_featurePolicy.get(), WebSecurityOrigin(m_securityOrigin));

[raymes, 2017/02/28 00:39:51]

This still worries me a bit just because we've always thought about the policy
as being tied to a single origin through its lifetime and I don't know what
assumptions we're breaking when this happens. 

For example, a feature may be enabled in a frame, and the origin changes but we
don't recheck the policy so it's still enabled. I guess it boils down to me not
understanding the circumstances under which origins can change in a
SecurityContext - it seems like it should be a rare thing.

Either way, I defer on this point since I don't know the answer but I do think
it would be good to feel more confident about it. Perhaps dcheng or mkwst can
give better advice here?

[iclelland, 2017/02/28 05:25:56]

With this CL, we would recalculate the feature policy in this case, so there
would have to be code in the renderer which is caching the result of
isFeatureEnabled, rather than calling it each time. If it's possible for the
policy to change in a way that would make that caching invalid, then we'll need
to document that callers shoudn't cache the results of that method.
.
I believe, from reading specs and code, that post-document-creation, there are
only a couple of ways that the document's origin could change:

 - Setting document.domain can update the domain properly
 - Using document.write or .open from *another* document sets the first
document's origin to be the same as the second one's.

That second technique is also restricted in code: the two documents need to
already be same-scheme-host-port-and-suborigin, so I believe that the only
properties of the origin that can reasonably change are the domain and some
flags like m_universalAccess, m_canLoadLocalResources and
m_blockLocalAccessFromLocalOrigin, which we don't use for FP decisions, and are
not normally set on the open web.

+r mkwst and dcheng for any more useful insight here -- are there other
situations where the origin can change post-creation?

 }
 
 }  // namespace blink