Critical: Support Google application/webbundle responses

[GeneGenie]

Type of issue

• Bug
• Feature request

Description

Prebid version: 5.20
We experience more and more webbundle content-type responses from GAM. It seems like it is served in AB test, but exact amount is not available right now.
Such scenario breaks safeframe universal creative, because origin of such iframe is 'null' and href of iframe is 'urn:uuid:{guid}'

Response preview

Elements and console location

Stack trace

[ChrisHuie]

@GeneGenie We are trying to figure out the best way to reproduce this issue so we can look into it. Are you able to make a test page or is there a specific interaction where this behavior is triggered from A/B testing.

[GeneGenie]

@ChrisHuie , it looks like this is absolute random behaviour. I saved a har file, but har viewers are not compatible with such data (yet?). And chrome has no built in tools to watch response contents.
The basic problem (shown on screenshot) that iframe has origin eq 'null' so prebid-cure could respond with '*' eventOrigin in postMessage.

[dgirardi]

@GeneGenie can you post the HAR or a test page? even if not readable or consistent, it would give me something to attempt to reproduce it.

I am wary of simply changing target origin to "*" because of the security implications.

[bretg]

@dgirardi patiently explained this to me enough that we came up with a proposal:

1. Add a new configuration to allow publishers to downgrade security.

pbjs.setConfig({disablePostMessageSecurity: true});

The relevant routines in secureCreatives.js and native.js would be updated to read disablePostMessageSecurity. If true, they would react to a null incoming origin by responding to origin:*

We would document this new option by noting that it would reveal ad markup to any listening code, even in another tab of the browser.

1a) If Google makes webbundles common in the short term, we could consider making this option on by default.

2. We open a separate issue for enhancing safeframe security:

• add an option for "enhancedPostMessageSecurity"
• add a "safeframe ID" to the message posted from the PUC to Prebid-Core
• if a safeframeID is provided and enhancedPostMessageSecurity is true, it's a signal to Prebid-Core that the receiver will be able to handle a more secure response. If not, fall back to the original protocol.

New response protocol:

• remove adId from Prebid-Core's PostMessage response
• Prebid-Core adds the safeframe ID to the response message
• Prebid-Core encrypts the PostMessage response with the adId
• The receiver decrypts the message with the expected adId and confirms the safeframe ID is theirs

[jeffkaufman]

@bretg @dgirardi I'm one of the Google Ad Manager engineers working on WebBundles, and someone pointed me to this issue. For more context, WICG/webpackage#624 describes how we're planning to use bundles to increase security and efficiency in ad rendering. We're currently participating in Chrome's origin trial for this feature, and are validating it on a small fraction of traffic.

Instead of fetching a SafeFrame from [random].safeframe.googlesyndication.com to hold the creative, with subresource bundles we can render the creative immediately in an opaque-origin iframe, saving a round trip. Because the iframe has an opaque origin, however, the origin will be null, as you saw.

Could you say more about why Prebid checks the origin on the message? What does this protect against? Without knowing the details of what you're doing this doesn't look like it's doing much, because SafeFrames can host arbitrary content. That is, SafeFrame ensures its contents are cross-domain from the containing page but it can't "vouch" for its contents or otherwise attest that they came from a trusted source (see section 2.4 of the SafeFrame 1.1 spec).

[dgirardi]

@jeffkaufman Currently Prebid interacts with safeframe in the following way:

1. Safeframe content sends a postMessage to the parent window (Prebid) asking for the ad to render. The origin is not checked on the receiving end (but there verification of a randomly generated token that is passed from Prebid to the safeframe via GAM rendering).
2. Prebid replies with request.source.postMessage(adInfo, request.origin). This fails if request.origin is null.

If we do not specify origin for step 2 (set it to "*"), it opens up some avenues of attack that have to do with navigating the safeframe to somewhere else in between steps 1 and 2 (more details here, section 4.2). This would expose adInfo to an attacker that would not otherwise have access to the token needed for step 1.

[jeffkaufman]

@dgirardi I'm sorry, I'm still not seeing how specifying an origin in (2) protects adInfo. Are you trying to protect it from other parties operating within the JavaScript context of the publisher page? Because, if so, it seems to me that adInfo is still exposed. Something in the publisher JS context can update the name attribute on the SafeFrame with new "creative content" intended to exfiltrate adInfo, and then reload the SafeFrame.

[dgirardi]

@jeffkaufman I am by no means a security expert, but my understanding is that you don't always need access to the target's JS context to manipulate iframe location. The two scenarios in that paper assume the attacker does not have such access. I do not know if they still apply today or if there are other attacks of the same kind that have been discovered since.

[jeffkaufman]

@dgirardi the paper is from 2009, and it does discuss some attacks that are no longer relevant today. For example, it is no longer the case that browsers allow any frame to navigate any other frame (permissive policy), and even when it was published it wasn't possible in the most recent versions of browsers.

Would you be able to say more about your threat model? What sort of potential attacker are you attempting to hide adInfo from?

[dgirardi]

In the context of this issue, we'd just like to verify that using targetOrigin: "*" does not increase attack surface compared to what we have currently. Since adInfo is available to anyone who has access to its token, which equates roughly to anyone who can run code in either the publisher or GAM creative context, the concern is just about an attacker with access to neither that can still somehow control navigation of the iframe.

Unfortunately guidance on the matter is limited to "never use *" which makes it hard to verify if that is possible in modern browsers. If the standard now is what that paper calls "descendant navigation policy" (search result are all pretty dated) it seems to me like it should - that would be the "recursive mashup attack", although I don't know how you would get a handle on a child of a cross-origin frame.

[jeffkaufman]

@dgirardi OK, sorry, you're right: there is a problem with the interaction between * and the descendant navigation policy (which is what all the browsers use now). Specifically, if an attacker iframes the publisher, then ad slots on the publisher site are also descendants of the attacker. Let me talk to people more here and get back to you.

[jeffkaufman]

@dgirardi I think you could use a MessageChannel to protect against sending adInfo to an ad iframe that has been navigated. Something like:

1. SafeFrame content creates a MessageChannel and includes its port when sending a postMessage to Prebid to ask for the adInfo.

2. Prebid replies with adInfo by postMessageing on the provided port.

Demo: https://www.jefftk.com/test/message-channel

If the SafeFrame is (maliciously) navigated, the MessageChannel will be lost, and the replacement will have no way to receive (intercept) the message.

What do you think?

[dgirardi]

@jeffkaufman that looks like a good solution - thank you! Do you have suggestions on how we could test against webbundle responses, or can we go ahead and assume that origin set to null is going to be the only visible difference?

@bretg the new proposal would be:

1. Update Prebid to accept MessageChannel in addition to the current flow. If a "normal" (non-MessageChannel) request is received with origin set to null, log an error that suggests the publisher needs to update their creative.
2. Update PUC and creative examples to also work with MessageChannel .

[jeffkaufman]

@dgirardi I don't have a way you can enable this behavior in GPT, but would it work to test with a data: url? The browser will also treat this as having an opaque origin, and it should behave very similarly.

Alternatively, and this may be enough hassle that it's not worth it, you could flip the chrome://flags/#enable-experimental-web-platform-features and then build your own test web bundle response? You might find https://www.jefftk.com/test/wbn-script/prototype useful as a demo.

[bretg]

the new proposal would be

If this will work, go for it @dgirardi ! Thanks for the suggestion @jeffkaufman

[patmmccann]

Work on this is now complete and just awaiting the next puc release