Feature policy: Add basic algorithm for supporting frame policies.

third_party/WebKit/Source/platform/feature_policy/FeaturePolicy.cpp

 // Copyright 2016 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "platform/feature_policy/FeaturePolicy.h"
 
 #include "platform/json/JSONValues.h"
 #include "platform/network/HTTPParsers.h"
 #include "platform/weborigin/KURL.h"
 #include "platform/weborigin/SecurityOrigin.h"
@@ skipping 105 matching lines @@
       ({&kDocumentCookie, &kDocumentDomain, &kDocumentWrite,
         &kGeolocationFeature, &kFullscreenFeature, &kMidiFeature,
         &kNotificationsFeature, &kPaymentFeature, &kPushFeature, &kSyncScript,
         &kSyncXHR, &kUsermedia, &kVibrateFeature, &kWebRTC}));
   return defaultFeatureList;
 }
 
 // static
 std::unique_ptr<FeaturePolicy> FeaturePolicy::createFromParentPolicy(
     const FeaturePolicy* parent,
+    const WebParsedFeaturePolicy* framePolicy,
     RefPtr<SecurityOrigin> currentOrigin,
     FeaturePolicy::FeatureList& features) {
   DCHECK(currentOrigin);
   std::unique_ptr<FeaturePolicy> newPolicy =
       WTF::wrapUnique(new FeaturePolicy(currentOrigin, features));
   for (const FeaturePolicy::Feature* feature : features) {
     if (!parent ||
         parent->isFeatureEnabledForOrigin(*feature, *currentOrigin)) {
       newPolicy->m_inheritedFeatures.set(feature, true);
     } else {
       newPolicy->m_inheritedFeatures.set(feature, false);
     }
   }
+  if (framePolicy) {
+    newPolicy->addFramePolicy(parent, framePolicy);
+  }
   return newPolicy;
 }
 
 // static
 std::unique_ptr<FeaturePolicy> FeaturePolicy::createFromParentPolicy(
     const FeaturePolicy* parent,
+    const WebParsedFeaturePolicy* framePolicy,
     RefPtr<SecurityOrigin> currentOrigin) {
-  return createFromParentPolicy(parent, std::move(currentOrigin),
+  return createFromParentPolicy(parent, framePolicy, std::move(currentOrigin),
                                 getDefaultFeatureList());
 }
 
+void FeaturePolicy::addFramePolicy(const FeaturePolicy* parent,
+                                   const WebParsedFeaturePolicy* framePolicy) {
+  DCHECK(parent);
+  DCHECK(framePolicy);
+  for (const WebFeaturePolicy::ParsedWhitelist& parsedWhitelist :
+       *framePolicy) {
+    const FeaturePolicy::Feature* feature =
+        featureForName(parsedWhitelist.featureName, m_features);
+    if (!feature)
+      continue;
+    if (Whitelist::from(parsedWhitelist)->contains(*m_origin) &&
+        parent->m_inheritedFeatures.get(feature)) {

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

Hmm does this match what we had in
https://docs.google.com/document/d/1saEBLE6d-qmMxao8Aw6A06oSP3yKdUG7lqMWBYlzE...


I guess the difference would be that right now this will be true, even if the
parent disabled the feature in itself by header policy, or if the feature is
disabled by default. In both those cases, the parent page would not itself have
access, so I think our reasoning was that it shouldn't be allowed to delegate
through the iframe attribute either.

I think here we want to return true if the parent frames policy allows the
parent frames origin. Does this make sense?

Could we add an extra 2 cases to the loop in createFromParentPolicy to handle
this (and more closely match what we have in the doc)? Would that work?

[iclelland, 2017/02/03 16:59:54]

Without this (and we can certainly debate in the doc or elsewhere whether it's
correct,) you can never use an iframe attribute to enable a default-off feature
for a child frame, even if you potentially could have turned it on for yourself.
As soon as you introduce default-off features, developers *have* to use headers.

It also means that there is no way to specify a general policy in an HTTP header
like {"feature": []} turn off a feature, and then selectively turn it back on
for individual frames.

[raymes, 2017/02/03 18:11:28]

Hmm, that's a good point. I guess the main problem I see with it is that a site
could try to lock itself down as an XSS mitigation, by saying "disable
geolocation in myself". But then if it was compromised, it could simply embed a
same-origin frame and then re-enable geolocation for that frame and get access.
Does that make sense? (I might be missing something).
That's true, but I guess they could do feature: ["self"] and then selectively
re-enable. I think that fits with the security model better in the sense that
the frame itself needs runtime access in order to delegate access at runtime.
What do you think?

[iclelland, 2017/02/03 19:50:04]

No that's a really good point. I'll update the spec, logic and tests.
Maybe we should revisit the idea of using <meta> tags, so that users with
HTML-only capabilities can still turn these features on.
I liked the idea that a site could say "I don't ever want to use this feature,
but turn it on in this child frame" -- similarly to having a header like

Feature-Policy: {"feature": ["https://some-other-site/"]} (not mentioning own
origin)

But without using headers. Maybe that doesn't fit the security model well,
though.

[iclelland, 2017/02/14 21:25:03]

Changed this to require that the feature be enabled in the embedding frame, and
updated tests to validate this.

+      m_inheritedFeatures.set(feature, true);
+    } else {
+      m_inheritedFeatures.set(feature, false);
+    }
+  }
+}
+
 // static
 WebParsedFeaturePolicy FeaturePolicy::parseFeaturePolicy(
     const String& policy,
     RefPtr<SecurityOrigin> origin,
     Vector<String>* messages) {
   Vector<WebFeaturePolicy::ParsedWhitelist> whitelists;
 
   // Use a reasonable parse depth limit; the actual maximum depth is only going
   // to be 4 for a valid policy, but we'll give the featurePolicyParser a chance
   // to report more specific errors, unless the string is really invalid.
@@ skipping 109 matching lines @@
     sb.append("  ");
     sb.append(whitelist.key->featureName);
     sb.append(": ");
     sb.append(whitelist.value->toString());
     sb.append("\n");
   }
   return sb.toString();
 }
 
 }  // namespace blink