Disable Payment Request API in CSP/iframe sandbox

[shhnjk]

CSP/iframe sandbox is meant to host untrusted content (by locking down privildge of the untrusted
content). And powerful APIs such as Service Worker, AppCache, etc are not callable from sandboxed contents. For the same reason, Payment Request API should be disabled in sandxboxed content. If anyone feels that there's a valid use case of Payment Request API in sandbox, then it should be only allowed with "allow-same-origin" keyword (Though I don't think there is such a use case).

[rsolomakhin]

Example of a CSP HTML header that @shhnjk proposes should prevent web payments:

Content-Security-Policy: sandbox allow-scripts

[ianbjacobs]

@rsolomakhin,

This seems like a good entry for the FAQ [1] and/or MDN [2]. Thoughts?

[1] https://github.com/w3c/payment-request-info/wiki/FAQ
[2] https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API/Using_the_Payment_Request_API

[rsolomakhin]

Do any of the implementers think it would be a good idea to have this in the spec?

[marcoscaceres]

Looking quickly, seems we would need to add it to:

• HTML Sandboxing

And we would need something like this in the PaymentRequest constructor:

If the document object's active sandboxing flag set has the sandboxed payment request browsing context flag set, throw a SecurityError DOMException.

@domenic, does the above seem right? Or is there more to it?

[marcoscaceres]

Noting we have allowpaymentrequest... so we would need to work out how they interact.

<iframe sandbox allowpaymentrequest></iframe>

I guess sandbox there bans everything, and allowpaymentrequest enables.... but because PR API is disabled by default cross-origin, we might not need our own flag?

[domenic]

This is interesting... usually we do not add features to both allow*/feature policy and iframe sandboxing. But, the fact that for top-level pages payment request is on by default, whereas in iframes it is off by default, makes this complicated.

Paging @clelland, our feature policy expert, for this thoughts.

[clelland]

PaymentRequest should be disabled, by default, in any sandboxed frame, just by virtue of it being cross-origin to the main document. The only way around that would be with something like

    <iframe sandbox="allow-same-origin allow-scripts" srcdoc="..."></iframe>

which would inherit the origin of the parent, and therefore not be cross-origin. That case should be treated like any other same-origin embed, practically, though. (The HTML spec specifically warns against doing that and thinking that it's anything like actually being secure)

allowpaymentrequest, and the equivalent payment policy-controlled-feature will currently enable the API in any cross-origin frame, including a sandboxed one, but that is entirely at the control of the developer including the sandboxed page. I'm pretty confident that that is sufficient to stop any content that shouldn't be using the API from using it, while giving developers enough control to enable it in a sandbox if they need it turned on for any reason.

[shhnjk]

Real world example: dropbox.com/enterprise runs with CMS which they made isolation with main dropbox.com using CSP sandbox. XSS in CMS theoretically has no impact on main dropbox.com but in this case, attacker can ask for payment :)
CC: @devd

[clelland]

So, to disable paymentrequest completely in any frame, whether same- or cross- origin, sandboxed or not, it is possible to use allow="payment 'none'".

Then, even in the least-sandboxed sandbox:

<iframe allow="payment 'none'" sandbox="allow-same-origin allow-scripts" srcdoc="..."></iframe>

the PaymentRequest API will be denied.

That won't stop a malicious script from reaching up into parent and forcing it to call the API, (or removing the attribute, or even the sandbox attribute, and reloading itself,) but if you're same-origin with your parent, then you've already given up on a lot of origin-based security protections.

Is dropbox.com/enterprise using allow-same-origin and allow-scripts? That's the only way that it should be able to request payment in a sandbox (but has all of the other problems above).

[shhnjk]

dropbox.com/enterprise is using following CSP sandbox.
content-security-policy: sandbox allow-forms allow-scripts allow-top-navigation allow-popups;

FYI to the spec editors (of all kinds), you all are doing great job in restricting cross-origin frames or insecure context for powerful APIs. But in my experience, CSP/iframe sandbox is usually left to implementors and I don't think it's a good idea (especially, now we have major website taking advantage of sandbox). This was also a spec issue in Web App Manifest. And what about Credential Management API?

So I appreciate if spec editors can keep in mind about sandbox and restrict powerful APIs in sandboxed content as you do for cross-origin frames and insecure context. Thanks.

[devd]

I agree. Out of curiosity, even if spec says nothing about the sandbox, shouldn't the spec rely on current origin of page when making decisions and if it did, shouldn't it just work out?

…

On Sat, May 5, 2018, 12:20 PM Jun ***@***.***> wrote: dropbox.com/enterprise <https://www.dropbox.com/enterprise> is using following CSP sandbox. content-security-policy: sandbox allow-forms allow-scripts allow-top-navigation allow-popups; FYI to the spec editors (of all kinds), you all are doing great job in restricting cross-origin frames or insecure context for powerful APIs. But in my experience, CSP/iframe sandbox is usually left to implementors and I don't think it's a good idea (especially, now we have major website taking advantage of sandbox). This was also a spec issue in Web App Manifest <w3c/manifest#638>. And what about CredMan? So I appreciate if spec editors can keep in mind about sandbox and restrict powerful APIs in sandboxed content as you do for cross-origin frames and insecure context. Thanks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#698 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIXGbOI7569BqBTemvgDMpW7nePw7Dcks5tvftkgaJpZM4S-rpc> .

[shhnjk]

Credit card information is saved in a browser and it isn’t tied to any origin. So if user trusts “dropbox.com/enterprise”, that’s a good way to monetize an XSS inside sandbox.

[clelland]

dropbox.com/enterprise is using following CSP sandbox.
content-security-policy: sandbox allow-forms allow-scripts allow-top-navigation allow-popups;

That should be sufficient to completely restrict the use of the PaymentRequest API in that frame. That policy should ensure that the frame has an opaque origin, which will be cross-origin with the frame in which it is embedded, and as long as the containing page hasn't explicitly granted access, it will be denied by default. Any other behavior is a bug.

shouldn't the spec rely on current origin of page when making decisions and if it
did, shouldn't it just work out?

Exactly, that is what should happen in this situation.

[clelland]

After re-reading all of the comments in this thread, I think I see the issue more clearly. This isn't about iframe sandboxing at all -- that works exactly as intended, as @devd points out. This comes up when the top-level document has sandboxed itself through the CSP sandbox directive. In that case, the browser's default policy is to allow the API in the main frame.

For now, this can be mitigated by also using the header

Feature-Policy: payment 'none'

but perhaps sandboxed main frames should have features like this disabled by default. I don't think it should be a behavior specific to this API, but possibly to Feature Policy generally, for any features which are disabled in cross-origin frames by default.

[devd]

sounds good. Just to sanity check: is feature-policy support a requirement of payment-request support?

[ianbjacobs]

I am not familiar with Feature Policy. However, the comment from @clelland that for security reasons powerful features should be disabled by default makes sense to me.

@devd, right now I don't see in the normative dependencies of Payment Request any dependency on feature-policy.

[stpeter]

Regarding Feature Policy, see #600 (it's marked as a future feature).

[shhnjk]

Just to clarify, why I included iframe in the title is because pop ups opened from iframe sandbox would also be a top-level sandboxed document (assuming the escape sandbox flag is not set).

[marcoscaceres]

Rereading the thread, it seems this will be handled by generically by the Feature Policy spec. I'm going to close this out via: #822