RFC1918 protection needs to be added to the spec

[MattMenke2]

RFC1918 requires protections against requests initiated by remote sites being made to local devices, to protect local devices whose security models rely on them not being web-accessible from being web-accessible through cross-site requests. Normally, web-initiated requests are associated with a browsing context, so inherit RFC1918 protections through the browsing context.

Conversion measurement API reports, however, aren't made in the context of a webpage, so are unable to inherit these protections. The spec should be updated to provide these protections.

Disclaimer: I'm not familiar with the standards work going on here, just with Chrome's implementation of it, so can't really provide any feedback on how best to cover these protections in the markdown files.

[apasel422]

Attribution Report requests aren't made in the context of a webpage, but the recipient of the report is determined by a previous request made in a webpage to that recipient.

For example: https://example.com can embed <img attributionsrc=http://localhost/register>. The browser will make a request to http://localhost/register, which in its response headers can include a trigger registration that ultimately causes the browser to store a report associated with the "reporting origin" http://localhost. Later, when the report's report time is reached, the browser will send the report to http://localhost/.well-known/attribution-reporting/report-event-attribution.

Presumably the initial request to http://localhost/register is already protected by RFC1918, as stated in the issue description. In other words, a report to reporting origin X can only be sent if there was already an RFC1918-valid request to X in the past that caused the report to be stored by the browser in the first place.

Given that, are any other protections necessary here?

[MattMenke2]

That doesn't address DNS rebinding attacks, though, does it? I think the latest RFC1918 spec may have given up on protecting same origin requests in that case, but not positive.

…

On Fri, Apr 14, 2023 at 12:38 PM Andrew Paseltiner ***@***.***> wrote: Attribution Reports aren't made in the context of a webpage, but the recipient of the report is determined by a request made in a webpage to *that* recipient. For example: https://example.com can embed <img attributionsrc= http://localhost/register>. The browser will make a request to http://localhost/register, which in its response headers can include a trigger registration that ultimately causes the browser to store a report associated with the "reporting origin" http://localhost. Later, when the report's report time is reached, the browser will send the report to http://localhost/.well-known/attribution-reporting/report-event-attribution . Presumably the initial request to http://localhost/register *is* already protected by RFC1918, as stated in the issue description. In other words, a report to reporting origin X can only be sent if there was already an RFC1918-valid request to X in the past that caused the report to be stored by the browser in the first place. Given that, are any other protections necessary here? — Reply to this email directly, view it on GitHub <#221 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFAGH4PEDXKMKIIOZORWIJ3XBF4QRANCNFSM5EAO2MOA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[MattMenke2]

(By the way, I'm out for an extended period of time, so don't expect followups from me).

…

On Fri, Apr 14, 2023 at 1:44 PM Matt Menke ***@***.***> wrote: That doesn't address DNS rebinding attacks, though, does it? I think the latest RFC1918 spec may have given up on protecting same origin requests in that case, but not positive. On Fri, Apr 14, 2023 at 12:38 PM Andrew Paseltiner < ***@***.***> wrote: > Attribution Reports aren't made in the context of a webpage, but the > recipient of the report is determined by a request made in a webpage to > *that* recipient. > > For example: https://example.com can embed <img attributionsrc= > http://localhost/register>. The browser will make a request to > http://localhost/register, which in its response headers can include a > trigger registration that ultimately causes the browser to store a report > associated with the "reporting origin" http://localhost. Later, when the > report's report time is reached, the browser will send the report to > http://localhost/.well-known/attribution-reporting/report-event-attribution > . > > Presumably the initial request to http://localhost/register *is* already > protected by RFC1918, as stated in the issue description. In other words, a > report to reporting origin X can only be sent if there was already an > RFC1918-valid request to X in the past that caused the report to be > stored by the browser in the first place. > > Given that, are any other protections necessary here? > > — > Reply to this email directly, view it on GitHub > <#221 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AFAGH4PEDXKMKIIOZORWIJ3XBF4QRANCNFSM5EAO2MOA> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[csharrison]

Hey @letitz I think you are an expert on RFC 1918 and the Private Network Access work. Can you help us if there is more work to be done here?

From reading the integration between our spec and https://wicg.github.io/private-network-access/#private-network-access-check, we should be fine here as the origin of our reports is same-origin with its URL.

cc @yoavweiss

[letitz]

Spec-wise, the same-origin exemption only applies to HTTPS URLs. Are these fetches always made over HTTPS?

We had discussed this a while ago in the context of Chromium (see https://crbug.com/1246381) and come to the conclusion that PNA checks were not terribly necessary, given that the attribution flow implied consent from the target origin. I can give this some more thought in a few hours, but that's what I have for now.

[csharrison]

Spec-wise, the same-origin exemption only applies to HTTPS URLs. Are these fetches always made over HTTPS?

Yep, these should always be HTTPS

We had discussed this a while ago in the context of Chromium (see https://crbug.com/1246381) and come to the conclusion that PNA checks were not terribly necessary, given that the attribution flow implied consent from the target origin. I can give this some more thought in a few hours, but that's what I have for now.

Thanks, that also matches the discussion we had in #547. It seems like this issue can be closed, but I will wait for your verification.

[letitz]

Great! Same-origin https fetches are exempted from PNA, and I'm happy with the outcome of the initiator/client discussion. You can go ahead and close this as far as I'm concerned.

[csharrison]

Thanks @letitz!

[csharrison]

Oh actually I mispoke, there are cases where we can send a report to HTTP. The requirement in the spec is:

1. The origin is HTTP/HTTPS
2. The origin is potentially trustworthy

https://wicg.github.io/attribution-reporting-api/#check-if-an-origin-is-suitable. I think this matches the PNA spec, but please re-open the bug if I'm missing something

[letitz]

I think this matches what we have in PNA indeed. We exempt same-origin fetches to/from potentially-trustworthy origins.

Side note: the algorithm you link to does not account for opaque origins, which have no scheme.

[apasel422]

Side note: the algorithm you link to does not account for opaque origins, which have no scheme.

Opaque origins are rejected by step 1 of that algorithm, as they are not potentially trustworthy.

[letitz]

Ah. indeed. Thanks for checking!