w3c / webappsec-permissions-policy

A mechanism to selectively enable and disable browser features and APIs
https://w3c.github.io/webappsec-permissions-policy/
Other
399 stars 155 forks source link

Potential bug in access delegation to cross-origin iframe for feature that has default allowlist value "self"? #512

Closed shuranhuang closed 1 year ago

shuranhuang commented 1 year ago

According to the explainer, when no declared policy presents, a powerful features that has default allowlist value "self" should be allowed in the top-level document and its same-origin frames, but blocked in cross-origin frames, unless allow attribute is used to set this policy and the origin of the document in the frame matches the iframe's src attribute.

However, the following step from the "Define an inherited policy for feature in container at origin" algorithm, https://github.com/w3c/webappsec-permissions-policy/blob/b363be8b113ed980b0449945483920bf1a19bac3/index.bs#L912-L915 which steps into "Is feature enabled in document for origin?" algorithm to the following steps https://github.com/w3c/webappsec-permissions-policy/blob/b363be8b113ed980b0449945483920bf1a19bac3/index.bs#L949-L952 will return "Disabled" for the case mentioned at the beginning, where "Enabled" is expected.

Could this be a bug or I am missing something here?

clelland commented 1 year ago

That does seem like a bug -- that step should be checking to see if the feature can potentially be delegated to the child frame, or if it is blocked by the policy in the containing document. Either 9.8 needs to return Enabled in all default cases, or 9.7 should be calling something different in this step.

This algorithm needs to be rewritten to handle #480 as well, so I'll see if I can come up with text that fits that and matches the intended behavior for default-self inheritance.

shuranhuang commented 1 year ago

Thanks for confirming! I think this issue was first introduced in https://github.com/w3c/webappsec-permissions-policy/pull/501. The fix should be easy.