Re: characterizing framing security needs for webappsec consideration

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>
wrote:

> 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
<https://w3c.github.io/webappsec-feature-policy/#algo-should-request-be-allowed-to-use-feature>
alg
is invoked in the case where JS running in the embedded frame invokes
PaymentRequest ?  The Is feature enabled in document for origin
<https://w3c.github.io/webappsec-feature-policy/#algo-is-feature-enabled>
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."
>

Possibly?


> 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?

HTH,

=JeffH