Open AlbertoFDR opened 1 month ago
That's a really good point - we've talked about the idea of headerless documents automatically inheriting the feature state from their parent, and we should make it explicit in the algorithms.This should apply at least to about:blank
, <iframe srcdoc>
and data:
urls
https://github.com/w3c/webappsec-permissions-policy/pull/515 also discusses headerless docs, but specifically for the default:none case of unload
. We should make sure that it applies to the whole header policy.
This should build on policy containers.
Currently, local schemes (such as
about:srcdoc
) do not inherit the PP header of their parents. This poses an issue if we have an origin A with a PP header ofmicrophone=(self)
which includes aabout:srcdoc
. If this local scheme iframe includes a cross-origin iframe (<iframe allow='microphone' src='https://malicious/'>
), this last iframe (https://malicious
) can request access for the permission. Instead, if thehttps://malicious
iframe gets included directly on origin A, it can't request access because of thePP header
. The example is the following one:PP header: microphone=(self)
src=”https://malicious” allow=”microphone”
--> Not allowed to promptsrc=”https://malicious” allow=”microphone”
--> Allowed to promptWith local schemes not inheriting the PP header, every website with an HTML injection and allowing
self
(which is necessary to allow anything at the moment: https://github.com/w3c/webappsec-permissions-policy/issues/480) could be exploited.The attack is almost identical to the
<iframe srcdoc="<script>alert(1);</script>"></iframe>
case in CSP that was mitigated by deciding to inherit the header (https://w3c.github.io/webappsec-csp/#security-inherit-csp). The general discussions on inheritances also seemed to conclude that local schemes should inherit: https://github.com/w3ctag/design-principles/issues/111The idea was also suggested here: https://github.com/w3c/webappsec-permissions-policy/issues/513#issuecomment-1567666837