I2I: AMP Inabox friendly frame rendering

jeffkaufman commented 5 years ago

Summary

An ad network may want to protect publishers from potentially malicious creatives, and so render third party ads in cross-domain iframes. Validated AMP creatives shouldn't allow the kind of malicious behaviors that cross domaining protects against, so AMP should (a) explicitly support rendering friendly to the page and (b) include documentation on how to do this safely.

This behavior has been live in Google Ad Manager for several months on an experimental basis, and we propose standardizing it.

Motivation

For a regular HTML creative from an untrusted source, cross-domain rendering is essential for protecting the publisher and users from the ads. For example, creatives could:

Copy the page's cookies (if not marked http-only) and allow user impersonation
Modify page content, enabling phishing or other fraud
Exfiltrate page content
Do anything else an XSS attack would allow

AMP creatives can't run custom JS, and the AMP JS doesn't (and shouldn't) allow any of these things, so this protection shouldn't be needed. Since cross-domain iframes are less performant than same domain ones (for example, because of site isolation in Chrome) rendering AMP creatives in same-domain iframes improves both page and ad performance.

Recommendations

We should offer a recommended configuration for serving AMP Inabox creatives friendly to the containing page. As a first cut, we propose:

Limiting friendly rendering to validated, transformed, AMP creatives.
Injecting a CSP (see https://github.com/ampproject/amphtml/issues/21681).
Injecting a referrer-policy like <meta name="referrer" content="origin"> at the beginning of the creative <head> to avoid accidental referrer leaks. Intentionally sending referrers is already possible in both AMP and non-AMP creatives.
Including a sandbox attribute on the iframe. We would need to agree what specifically to recommend here.
Only using friendly frame rendering in cases where you want to protect the publisher from the ad. AMP does nothing to protect the ad from the publisher.

/cc @ampproject/wg-approvers

mrjoro commented 5 years ago

/cc @ampproject/wg-ads

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

sbenhai commented 3 years ago

This security issue has been open for a long time, will this issue not be fixed?

jeffkaufman commented 3 years ago

For what it's worth, this behavior is still live on Google Ad Manager.

sbenhai commented 3 years ago

For what it's worth, this behavior is still live on Google Ad Manager.

So, It's exploitable?

jeffkaufman commented 3 years ago

@sbenhai This is a security ticket, but it isn't a vulnerability report. It is a request that the AMP project officially support this kind of friendly frame rendering and offer official guidelines on how networks should implement it.

I believe AdManager does everything listed under Recommendations above already.

I don't know whether there are any other ad networks that are rendering validated Inabox creatives friendly to the page?

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

ampproject / amphtml