w3c / webappsec-permissions-policy

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

PP header inheritance for local schemes #552

Open AlbertoFDR opened 1 month ago

AlbertoFDR commented 1 month ago

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 of microphone=(self) which includes a about: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 the https://malicious iframe gets included directly on origin A, it can't request access because of the PP header. The example is the following one:

With 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/111

The idea was also suggested here: https://github.com/w3c/webappsec-permissions-policy/issues/513#issuecomment-1567666837

clelland commented 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.

annevk commented 2 weeks ago

This should build on policy containers.