Behavior for non-secure requests and responses

[csharrison]

Currently in the Chromium implementation has the following behavior:

• Insecure background attributionsrc requests are blocked if their urls are insecure
• Otherwise background attributionsrc requests are allowed to redirect through insecure origins, but responses for them will not be processed.

This behavior is not really consistent, so we should think through the desired behavior here. If we think about the security stance of the API - we say that the publisher is in control of who can register sources by nature of them placing the attributionsrc attribute. We then make an argument for supporting redirects via transitive trust. If party A trusts party B, we consider that trust to extend to party C which B calls into. As soon as any of those parties are insecure, I think that argument falls over, because it's equivalent to e.g. party B saying they trust everyone which feels possibly too permissive.

I see two possible solutions:

1. As soon as a redirect is insecure, taint the request so no further response headers can be processed. This would be a backwards incompatible change so we'd need to analyze feasibility.
2. Keep the behavior that allows intermediate insecure requests, and make the existing behavior consistent to allow the first URL to be insecure as well.

cc @apasel422 cc @letitz for security POV here with respect to powerful features. Do you have any opinions here?

[apasel422]

I agree that we should be consistent and am fine with either option from an implementation perspective.

[letitz]

New web features should use HTTPS everywhere by default, so I think the right thing to do is to require HTTPS on every hop.

That said, in the spirit of Chesterton's fence, do you have a pointer to the discussions that led to the current tainting design? At first blush, it seems strange to allow the requests but not process the response. Why not block them?

[csharrison]

Hey @letitz , when you mention the "tainting" design, do you mean the option (1) I am suggesting we may move to? Just to clarify this is not the current design, which just ignores HTTP hops and only allows registrations on HTTPS ones. The reason I thought of tainting was because our API is integrated into existing measurement flows and so my preference would be to just break the API itself (i.e. disallow registration) rather than break actual existing deployments that our API piggy-backs on top of.

[letitz]

Sorry, I think I'm confused. What's the difference between these two statements?

background attributionsrc requests are allowed to redirect through insecure origins, but responses for them will not be processed.

As soon as a redirect is insecure, taint the request so no further response headers can be processed.

I was referring to the former, which I took to be the same as your tainting proposal, but that does not make sense.

[csharrison]

Ah, in our current design if you imagine a redirect chain of

1. https://secure1.example
2. http://insecure.example
3. https://secure2.example

If all of those hops send response headers configuring ARA, then we will only process (1) and (3). Critically, we will still process (3) even though an insecure origin redirected to it (so maybe it is not really "trusted" since it could be anyone at that point).

The tainting proposal would reject ARA headers on (3).

[letitz]

Ah, ok, that makes sense. Thanks!

We can indeed trust that the response headers for 3 genuinely came from secure2.example, but we cannot trust that secure1.example meant to extend its trust to secure2.example, since http://insecure.example could be anyone.

I think your tainting proposal makes most sense. Allowing insecure URLs in the attributionsrc attribute regresses security, so I'd really rather not. Do you have metrics indicating how much of a compatibility issue this would be?

[csharrison]

@letitz we don't have metrics but we can investigate, your feedback is really appreciated.

[apasel422]

Note that we will also want to apply this logic to response-processing on non-background attributionsrc requests, e.g. navigation redirects.

[csharrison]

Note that due to mixed content blocking and auto-upgrading, in practice I believe this issue should only affect navigation requests. To protect against being redirected to in an insecure way (e.g. you receive a request in the middle of a redirect chain to your HTTP endpoint instead of HTTPS), you can ensure your origin uses HSTS (and is preloaded to ensure high coverage).

In our recent May 1 meeting it was mentioned that if we do break subsequent secure sites via "tainting" it would be good to surface the error somewhere, e.g. in a request header notifying that this request would have been eligible but some error happened.

[letitz]

Notifying subsequent websites about the error would provide them with some data about other origins involved in the redirect chain. Could an attacker abuse this?

[csharrison]

Notifying subsequent websites about the error would provide them with some data about other origins involved in the redirect chain. Could an attacker abuse this?

Good call out @letitz , we should definitely tread carefully here. The signal you get here is basically "the request was configured for ARA but the redirect chain hit an insecure origin". The only abuse vectors I can think of involve a site which already has some prior information about the redirect chain it could be part of, like that it is either in chain A or B: A. secure1.com -> insecure.com -> secure2.com -> last.com B. secure1.com -> secure2.com -> last.com

The signal would allow them to determine which chain they are in, which may leak some information (i.e. A is used for some users and B is used for other users).

[letitz]

I see. Given that these affect navigation requests, which I believe would carry first-party cookies, it seems a bit dangerous to expose this information cross-origin. If foo.com had some open redirect path that went through different origins based on whether the user was logged in or not, then an attacker could abuse this leak to learn whether the user was logged in.

@camillelamy tells me she has been involved with error reporting for attribution reporting, I'm curious to hear her opinion.

[csharrison]

Thanks for the feedback @letitz . I think it may be feasible for the redirect chain to expose this information on their own (in an opt-in way) without browser involvement which would avoid the cross-origin leak.

[bmayd]

Per @csharrison in 5/15 meeting (correct me if I got something wrong): the opt-in way is for an insecure intermediary to alert the next down-stream participant in the chain that they broke the chain and for each participant receiving a breakage alert to forward the message to the next participant.

[csharrison]

Update on our side: we have implemented metrics in Chromium to detect the breakage of the tainting proposal. We expect that the HTTPS upgrading proposal will also mitigate this to some extent, so we are monitoring with breakouts with this feature enabled.