W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2019

Re: characterizing framing security needs for webappsec consideration

From: Jeff Hodges <jdhodges@google.com>
Date: Tue, 16 Apr 2019 17:53:56 -0700
Message-ID: <CAOt3QXsY_Q4zaaV28M57Wijj-6FC1ucGobT36qQLn3ATRLNejA@mail.gmail.com>
To: Rouslan Solomakhin <rouslan@google.com>, public-webappsec@w3.org
HI WebAppSec folk,

I've been corresponding with Rouslan over in the Web Payments working group
regarding Feature Policy in cross-origin iFrames and sandboxed iFrames and
how they might be used for a couple of use cases he/they have.  It would
seem to have relevance for the still-to-be addressed question of policies
wrt WebAuthn in cross-origin iFrames.

This is kinda long, but this stuff is complex. I'll try adding it to the
end of the agenda for tomorrow's call...

On Tue, Apr 16, 2019 at 6:52 AM Rouslan Solomakhin <rouslan@google.com>

> Thank you for the reply, Jeff! Please see my comments inline.
> On Mon, Apr 15, 2019 at 9:46 PM Jeff Hodges <jdhodges@google.com> wrote:
>> On Wed, Apr 3, 2019 at 5:31 PM Rouslan Solomakhin <rouslan@google.com>
>> wrote:
>>> Here's a summary of the needs/considerations for the Web Payment APIs:
>>> *#1: Would it be possible to disable certain powerful APIs (e.g.,
>>> Payment Request and Payment Handler) in embedded cross-origin iframes by
>>> default, unless the embedded iframe explicitly allows to be embedded for
>>> the purpose of payments?* Concretely, this could be something like a <meta
>>> allow-when-embedded="payments"> tag, for example.
>> *In my reading of Feature Policy
>> <https://w3c.github.io/webappsec-feature-policy/>, it seems this use case
>> is addressed*.  For embedding origin example-embedding.foo, and embedded
>> origin example-embedded.bar, the embedding webapp would declare on the
>> embedded iframe:
>> `<iframe allow="payment example-embedded.bar" ...>`
>> and example-embedded.bar would return a "header policy" (from which the
>> UA forms the embedded content's "declared policy"), like so:
>> `Feature-Policy: payment 'self';`
>> And then the magic Feature Policy algorithm Is feature enabled in
>> document for origin
>> <https://w3c.github.io/webappsec-feature-policy/#algo-is-feature-enabled>
>>  combines the two policy declarations and comes up with "Enabled" for
>> the "payment" feature in the cross-origin iframe.
> Is my understanding correct that example-embedded.bar does not have to
> specify a "header policy" for payments to work?

I *think* the answer is "no" because this use case is explicitly
cross-origin (however, see below).  I think the answer is "yes" if it were
a same-origin use case.

So, upon further grovelling thru the Feature Policy spec, I am unsure
whether it can be employed to allow cross-origin feature use. The spec
seems unclear whether the Should request be allowed to use feature
is invoked in the case where JS running in the embedded frame invokes
PaymentRequest ?  The Is feature enabled in document for origin
alg, which does the combining of inherited, declared, and default policies,
appears to only be called from the former alg.  Also, if the *document*
that is passed to the latter alg is the top-level document, then the
embedded document's declared policy (if any) is not evaluated by the latter
alg. And so this scenario would not work.  :(

> If this is correct, then I am proposing that we make an exception for
> "payment" specifically to always require the "header policy" in the
> embedded iframe. This would be a change in the spec and, therefore,
> implementations, if I understand correctly.

In any case, regardless whether Feature Policy is actually intended to
support the above feeble cross-origin example (this is not made clear in
the spec, ISTM), I am now guessing that the above example "header policy"
(i.e., Feature-Policy header field) ought to perhaps be:

`Feature-Policy: payment example-embedding.foo;`

..and am wondering whether that would be a reasonable way for the
combination of the embedding and embedded parties to explicitly declare
that such cross-origin use of a feature(s) is allowed?  (this must have
already been discussed ?)

> #2: Would it be possible to disable these powerful APIs in all iframes
>>> that are not sandboxed? Cross origin iframes today have to look like this:
>>> <iframe allow="payments" src="https://payment-app.com/some.js"></iframe>,
>>> if the parent iframe wants to allow payments in the child iframe. Would it
>>> be kosher to require the tag to look like this: <iframe *sandbox*
>>> allow="payments" src="https://payment-app.com/some.js" ></iframe> ?
>> Sandbox attribute is defined here
>> <https://html.spec.whatwg.org/multipage/iframe-embed-object.html#attr-iframe-sandbox>
>> .
>> Given that definition, it seems that the sandbox attr does not match your
>> above use case. The sandbox attr is about protecting the embedding webapp
>> from the framed webapp/content (and not vice-versa), and also not about
>> controlling whether powerful features are enabled or not (the latter is the
>> province of Feature Policy).
>> That said however, it may be overall reasonable standard best practice
>> for embedders to declare many iframes (in general) like so:
>> <iframe sandbox="allow-same-origin allow-forms allow-scripts" src="
>> https://maps.example.com/embedded.html"></iframe>
>> ..because it disables plugins and popups, thus reducing the risk of the
>> user being exposed to malware and other annoyances.
> It feels like a payment sheet can fall into the category of "other
> annoyances."


> I am proposing to change the spec to say: "if the cross-origin iframe does
> not have a sandbox attribute, then disable the payment APIs in that
> iframe." Does that sound reasonable?

By spec, you're referring to the Payment Request spec?

I remain uncertain that requiring the sandbox attr is appropriate.

However, the framed webapp is able to escape the sandbox relatively easily.
>> See examples and warnings in Sandbox attribute definition
>> <https://html.spec.whatwg.org/multipage/iframe-embed-object.html#attr-iframe-sandbox>
>> .
> Is my reading of the spec correct that only iframes from the same origin
> as the embedder can escape sandbox?

That seems to be implied?


Received on Wednesday, 17 April 2019 00:54:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 17 April 2019 00:54:47 UTC